Re: Clarifying confusion of our variable placement rules caused by cleanup.h
Linus Torvalds <[email protected]>
| Newsgroups | dev.linux.lists.ksummit,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAHk-=wjD1r5dr_b7gpuPdTXGdXAtaM6wHBSJyzi-Zfw3-cqR6w@mail.gmail.com> |
On Tue, 18 Nov 2025 at 12:21, James Bottomley <[email protected]> wrote: > > On Tue, 2025-11-18 at 14:17 -0500, Steven Rostedt wrote: > > I think the code could also be better optimized? I haven't run an > > objcopy to confirm but now early exits do not require calling the > > __free() function on NULL pointers. > > Yes, I can confirm that (at least from reading the docs not actually > from disassembling the code). Actually, I _have_ been disassembling some of that code, and most of the time the compiler is actually good at eliding those things and not calling kfree() with a NULL pointer. Now, the reason for that is actually that we spent some effort on this in <linux/cleanup.h> (and by "we" I mean mostly PeterZ & co with me being involved in the discussions). So you'll see those destructor functions being inline functions with things like that DEFINE_FREE(kfree, void *, if (_T) kfree(_T)) where that "if (_T)" being integral to having the compiler able to see inline that "oh, it's statically NULL at this stage, I don't need to call any external function". But yes, sometimes having the declaration later can simplify this all for the compiler too. But the *primary* thing should be about making the code itself legible and maintainable to humans. Linus