Re: [PATCH] driver core: faux: fix Undefined Behavior in faux_device_destroy()

[Marc Herbert <marc.herbert@linux.intel.com>]

On 2025-06-18 17:23, 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.

None of these ideas crossed my mind:
- dropping -fno-delete-null-pointer-checks
- anything "large" like a "flag day audit" or any large cleanup/refactoring/etc.

Sorry for the confusion.

During the discussion, some seemed to perceive
-fno-delete-null-pointer-checks as a "performance-neutral" choice. So I
just tried to correct that impression "in passing", but please do _not_
read too much into it.


What I was really interested in:

1. Is it acceptable to swap two lines to _locally_ get rid of C Fear,
   Uncertainty and Doubt and time-consuming consultations with language
   lawyers. On a _case-by-case_ basis.

2. Are C99 declarations acceptable.

3. Do tooling and "convergence" with other C projects matter.

Note "acceptable" != mandatory; _allowing_ C99 declarations does NOT
imply scanning existing code and systematically reducing variable scope
everywhere possible. Same as every other "new" C feature.

I think these were valid "policy" questions, that this "poster child"
was an efficient way to ask all of them with a ridiculously small amount
of code and I think I got loud and clear answers. Case closed, moving on!


> 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.

Nice one!


On 2025-06-18 19:35, Dan Carpenter wrote:

> 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.

pointer math is what we _want_ the code to do. But if that relies on
some undefined behavior(s) then the bets are off again. Check
https://stackoverflow.com/questions/26906621/does-struct-name-null-b-cause-undefined-behaviour-in-c11
where offsetof() is a suggested alternative.
Spoiler alert: more language lawyers. Do not click ;-)