Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 4 Apr 2018 12:42:06 -0700 | Subject | Re: [GIT PULL] x86/build changes for v4.17 |
| |
On Wed, Apr 4, 2018 at 12:26 PM, James Y Knight <jyknight@google.com> wrote: > > (OTOH, I _do_ expect clang to eventually gain support for a flag to treat > NULL-pointer deref as a legal operation instead of UB. I'm not really sure > it makes sense for the linux kernel, but it's a useful feature for the > compiler to provide in any case, so why not...)
I would actually argue that this is more closely related to "-fno-strict-overflow" than to "-fno-delete-null-pointer-checks'.
It just happens to be about pointer arithmetic, rather than about signed integers. We *will* do arithmetic with NULL pointers that can wrap.
Yes, the kernel does odd things with pointers in general. I won't apologize for it, because we have really good reasons for doing so.
The whole "we take offsets of pointers even *backwards*" is because we extensively rely on embedding structures inside each other. If clang actually did proper optimization, it would have noticed that the "offset backwards" was followed by an "offset forwards" and then a NULL pointer check, and that there actually was no actual real wrapping or non-contiguous behavior in reality.
But clang didn't do that, and instead blindly said "you're going forwards and the result can't be NULL", without ever looking at "oh, they went backwards first".
So honestly, part of the problem we had with clang was that it was too *stupid* to see that what we did wasn't actually invalid even by clang's own standards!
I'm not saying that the kernel use is really standards compliant, because there definitely are those temporary pointer values (that are never used!) that point outside an object.
But honestly, the clang "optimization" is really quite debatable, and we'd want to turn it off - or just have clang be smarter enough that it sees that "oh, it all stays within the object after all".
We do other things to pointers that the standard may not cover. Deal with it. Any malloc() library will similarly just depend on pointer arithmetic really working. We may admittedly take it to some ridiculous degrees, with the whole "ok, we assign negative values to pointers as error cases" in addition to the "we use container_of() to look uip pointers *backwards*" thing.
So we'd definitely want that "-fno-strict-overflow" to affect pointer arithmetic too (or have a separate flag for the pointer equivalent of "we play games that may temporarily wrap pointer values around"..
Linus
| |