An important set of stable kernel updates

Well, is there any point in talking to Linus, and his like-minded friends, until they fix their counter-productive views of security ? The arguments told years ago by PaXTeam, spender and others from their side still stand.

Let's examine the mainlining of the five most powerful defenses from PaX/grsecurity against kernel exploitation, which stop most PoCs discussed time and again on LWN and elsewhere, at every step of their execution:
* KERNEXEC (over a decade old, preventing the kernel from blissfully executing payloads in user-space): principle refused by Linus and friends because "the hardware does it". Right, but only for a minority of very recent hardware from the 2010s featuring x86/x86_64 SMEP or ARM/AArch64 PXN, as opposed to protecting most CPUs from this millenium (and not just on x86/x86_64 or ARM/AArch64) ! Plus the GCC plugin infrastructure it uses was only integrated in 4.8, several months ago.
* MEMORY_UDEREF (over a decade old, preventing the kernel from blissfully dereferencing pointers to payloads in user-space): ditto, with "the hardware does it" being even more of a lie, as x86/x86_64 SMAP and ARM PAN are even scarcer in the real world than SMEP / PXN. And there have already been easy SMAP bypasses in mainline;
* RAP (powerful anti-ROP measure): no way, because per-CPU PGDs, another PaX change on which RAP is based, is refused, too;
* CONSTIFY (making const all those needlessly writable "ops" structs, often overwritten by PoCs as a first step to kernel exec): not refused, it's just that nobody seriously does it in mainline (years ago, I contributed several patches extracted from PaX for manually constifying structs, before they switched to a GCC plugin; the situation hasn't changed much);
* RANDSTRUCT (foiling binary exploits by randomizing struct layout): possible now that the GCC plugin infrastructure is in. But the real-world protection brought by this feature is limited, given that pretty much everybody is using publicly downloadable distro kernels, nullifying the effect of RANDSTRUCT.

The three most powerful defenses against kernel exploits are flat out refused. Until this counter-productive stance is reversed, the KSPP efforts will remain of very limited usefulness - and trickling in at a slow pace, what's more: look at how little got in mainline over the past year.
In the meantime, I'm keeping grsec kernels (which are being packaged by a growing number of distros, for very good reason !) on my own computers, using them on a growing number of computers at work, and slowly educating my workmates on how powerful grsecurity is / how lackluster mainline Linux security is / how it is hardly improving.

> Go do a service to the community (as this site does) by explaining how the bug works. Publish things. By all means, talk about it. Set up a service which tries to assess each bug fix to the Linux kernel.

Because the lead developer of the most comprehensive security-related Kernel patchset with an amazing track record doesn't add anything to the community? Wtf? His arguments are well known but fail on deaf ears. And one person only can do so much, Spender clearly is on the upper end of that scale or beyond...