Not NULL assertions

It is argued that adding assertions to your code helps you describe and optionally enforce your contract (design/programming by contract).

I agree that the default BUG_ON(..) is the wrong way to go, but removing it removes a piece of information, namely that we assume the pointer to be not null. I think that a better solution would be to introduce:

ASSERT(expr) and possibly ASSERT_NOT_NULL(ptr) or ASSERT_VALID_PTR(ptr) which also checks for error pointers. They perfectly describe what we expect from our input parameters and you with a DEBUG_ASSERTIONS configuration option you would activate these additional checks (which for production systems would not be enabled by default).

The other thing I personally encountered during some kernel programming was that it's often not clear if a pointer could be NULL at a given point. Idealistically one would always write input and output documentation for functions, but I don't think that would be realistic and it would get outdated soon (or people make the wrong assumptions because the documentation said so, but forgot to mention the out of memory error pointer).
Most tricky bits however ware the hooks one writes in the device drivers, which are called by some other parts of the kernel. There are far fewer of those and changes there are always done very carefully for there are many users of those callbacks (both calling and providing). So a changes any changes here are much more well thought through and given the care that must be taken the updating (and given the symantics change, any resulting code that has to be modified to handle the new symantics) would make the documentation update pretty minor. Idealisticly you should also be able to introduce (preferably with one simple config option) a way that a debug proxy function would be inserted or a debug hook be called before calling the actual hook function. This would probably mean that calling a hook or registering a hook should be made more explicit, which would be a good thing (especially calling a hook, registering is very frequent, but calls are much more sporadic).

This of course assumes that some people would be willing to run test-kernels which are easily 5% slower than the production versions, though they should be more secure and at least as stable as soon as the first wrinkles are ironed out.