even so, I don't think that the kernel developers would object to patches that cleaned things up and made the read-only status of things explicit.
Doing this may not help security much without the change you mention below, but it would reduce the size of the GRsec patchset, which would then mean that those people would not have to maintain this sort of thing as a external patch.
Then with the read-only status clearly defined for things, the kernel developers may be open to a configurable option that would change how read-only memory works, if the performance impact could be clearly documented (and under some conditions, making things read-only may result in performance increases, if it means that the system can allow multiple copies of the data to exist in CPU caches without having to worry about keeping them in sync because they are known to never change)
the key thing is to not pitch this as 'this is a critical security fix, take it immediatly', but instead pitch it as 'This is a cleanup to make otherwise undocumented assumptions about how variables are used explicit, improving long-term maintainability It has the potential to have a minor performance improvement and security gain, but only if the read-only status gets enforced.'
this changes the reason for accepting the patches into something that they can see a direct benifit for.