Security part 2

IOW, he's glad that a crushing majority of users of the Linux kernel keep running insecure flavors which will blissfully dereference ops structures in userspace, then proceed to execute code in userspace. Most Linux kernel exploit PoCs I've seen mentioned on LWN over time do both.
He's glad that a crushing majority of users of the Linux kernel aren't enjoying effective defenses created many years ago, which:
* do not require any special hardware support available only on a tiny minority of recent x86_64 processors (SMAP-capable processors are very recent, SMEP is a bit older) or semi-recent ARM processors (domains, PXN, etc.);
* support more (no fewer, at least) ISAs;
* provide a _strict superset_ of the capabilities of SMAP (see posts by spender and PaXTeam at https://lwn.net/Articles/517749/ , https://lwn.net/Articles/617945/ , etc.), and IIRC, SMEP as well.
Yes, I'm aware that UDEREF, especially, has a measurable performance cost.

Oh well. We already knew that despite Kees Cook's efforts, mainline kernels will remain lacking in anti-exploitation abilities and therefore knowingly insecure for the years to come, due to lack of features which have been known for a decade, and are _far_ better battle-tested than much of the code which constantly gets thrown into the kernel :)
In the meantime, the PaX Team, spender and Emese Revfy keep working part-time adding innovative features for anti-exploitation, disabling or strongly hardening insecure features which reach mainline on a frequent basis, and leaving mainline Linux even deeper in the kindergarten, from a security standpoint.

BTW, a reminder: PaX/grsecurity contain _hundreds_ of cleanups and minor improvements which have no, or low (but positive), security impact, and have usually been there for years, because the mainline submission process is too costly (in terms of developer time) and because too few core kernel developers actually look at PaX/grsecurity, sadly.
One can easily find hunks aiming at, for instance:
* removing "static" from a dozen of variable declarations where said "static" is superfluous for the purposes of the function (the first thing the function does is reinitializing the variable, so no need to persist the value across calls), e.g. drivers/mfd/max8925-i2c.c and drivers/mfd/tps65910.c, last time I checked;
* using more C99 designated initializers in many structs (too many to list) - probably originally a consequence of RANDSTRUCT, but a readability improvement;
* adding __force_user and __force_kernel annotations for the checkers (too many to list);
* constifying some function arguments, so as to make it harder to inadvertently modify them (e.g. mm/slob.c).
These hunks are more useful to the Linux project than whitespace patches that maintainers are complaining about, and are good candidates for newcomers with a bit of programming experience. Besides the minor improvement to Linux, mainlining those patches t would unclutter the monster PaX/grsecurity patch.