Toward a better list iterator for the kernel [LWN.net]

Toward a better list iterator for the kernel

Posted Mar 10, 2022 22:50 UTC (Thu) by roc (subscriber, #30627)
Parent article: Toward a better list iterator for the kernel

> the "use of uninitialized variable" warning is disabled in the kernel due to excessive false positives.

Wow, this is terrible. I had no idea.

Given there are hardening patches to force zeroing of local variables, why not just initialize them in the source as necessary to eliminate the existing warnings and turn that warning on?

to post comments

Toward a better list iterator for the kernel

Posted Mar 10, 2022 23:53 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (4 responses)

If the compiler wrongly thinks that a variable is used before initialization, then it will probably fail to optimize away the dead store resulting from eager initialization. Whether that dead store is worth worrying about is another matter, of course, and probably depends on how hot a given codepath is.

Initialization

Posted Mar 11, 2022 0:29 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

There was a CPP Con talk some years back about exactly this work by Microsoft. Basically let us teach the compiler to zero initialize everything, then run tests to see how awful the results are, teach the compiler to optimize away these dead stores and/or perform zero initialization that it more easily recognises as dead stores, iterate. IIRC The first few loops are very, very bad, nothing you could possibly ship, but as they learn what they're doing by the end they can more or less do this over the bulk of the system and get the same performance as before but with more confidence there aren't scary initialisation bugs. Obviously they were in C++ and their own C++ compiler, where Linux would want C and GCC, but it's not so different otherwise. If people can't find it themselves I can search Youtube maybe.

Initialization

Posted Mar 11, 2022 1:25 UTC (Fri) by bartoc (guest, #124262) [Link] (1 responses)

MSVC's behavior is a bit of a problem because there's no great opt-out, and it doesn't really do the optimizations in debug mode, meaning if you ever use stack arrays it's really easy to have awful debug mode performance. It's one of the bigger "MSVC debug perf sucks" things around (along with like, not having a way to write inline functions that are always inlined, even in debug).

If there was an opt-out, and if MSVC had a saner "debug mode" (really these optimizations should be turned on in debug mode imo) then it would be a great behavior.

Initialization

Posted Mar 11, 2022 1:29 UTC (Fri) by bartoc (guest, #124262) [Link]

Note, I'm talking more about /RTCs rather than "InitAll", which might work better.

Toward a better list iterator for the kernel

Posted Mar 11, 2022 1:24 UTC (Fri) by roc (subscriber, #30627) [Link]

My point is that a lot of those "dead stores" are already being performed by kernel hardening. https://github.com/torvalds/linux/blob/186d32bbf034417b40...

So on one hand we've got developers saying "adding dead stores hurts performance, don't do it and keep that essential warning disabled", and on the other hand developers are adding dead stores all over the place for the sake of security.

Toward a better list iterator for the kernel

Posted Mar 11, 2022 11:20 UTC (Fri) by geert (subscriber, #98403) [Link]

Mindlessly adding preinitializations to uninitialized variables instead of fixing the real problems prevents the compiler from flagging newly introduced uninitialized users of the same variable later.

BTW, I used to fix all newly introduced non-false positives reported by gcc-4.1.2, which was rather strict (compared to later gcc versions), and caused lots of false positives. But every kernel release, I did catch a handful of real bugs. Later, gcc improved, Arnd started to build the kernel with bleeding edge gcc versions catching more bugs before I found them, and support for gcc-4.1.2 was dropped. But I believe there still are areas for improvements...