On Wed, Jun 18, 2025 at 05:23:10PM -0700, Dan Williams wrote: > Marc Herbert wrote: > [..] > > In other words, by turning this off unconditionally at the global level, > > the kernel could actually lose (surprise!) some performance. > > I expect the answer is that any compiler that does fail to convert this > to defined behavior is not suitable for compiling the kernel. > > The issue is not "oh hey, this fixup in this case is tiny", it is > "changing this precedent implicates a large flag day audit". I am > certain this is one of many optimizations that the kernel is willing to > sacrifice. > > Otherwise, the massive effort to remove undefined behavior from the > kernel and allow for complier optimzations around that removal is called > the "Rust for Linux" project. We turned it off because of the tun.c bug. CVE-2009-1897. It was a fun story: https://lwn.net/Articles/342330/ https://lwn.net/Articles/342420/ I would say that if having the compiler automatically delete nonsensical NULL checks leads to a performance improvement in your code then you're doing something wrong. Potentially there could be nonsense NULL checks embedded inside macros, I guess. But, again, this is a totally different thing from what the patch does. The faux_device_destroy() code is not doing a dereference, it's doing pointer math. regards, dan carpenter
