Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis
Mulyadi Santosa <[email protected]> Fri, 25 Jul 2025 19:18:29 +0700
| Newsgroups | org.kernelnewbies.kernelnewbies |
|---|---|
| Message-ID | <CAGdaadakDXd_m1NfG6KVHc8BntNX=O0gFLmz-DiTYctcBWQmvQ@mail.gmail.com> |
--===============8294373514154441007== Content-Type: multipart/alternative; boundary="000000000000585360063abff17e" --000000000000585360063abff17e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 25, 2025, 17:47 Raka Gunarto <[email protected]> wrote: > Hi everyone, I'm a really new contributor and I sent off this > RFC to LKML < > https://lore.kernel.org/lkml/[email protected]= m/T/#m1372eb992552491ac37f46f27e5ad09d9efa35ad > >, > when I probably should have floated the idea > here first. In any case, I've pasted my RFC patch below > and I would really like any feedback / suggestions on the > idea. > > Thanks, > Raka > Hello Raka Interesting idea. Other than silencing clang analyzer warning, what is exactly the advantage of using such macro? > ---------- Forwarded message --------- > From: Raka Gunarto <[email protected]> > Date: Wed, Jul 23, 2025 at 3:01=E2=80=AFPM > Subject: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL > macro for static analysis > To: <[email protected]> > Cc: Raka Gunarto <[email protected]> > > > This proposed patch introduces a new macro ASSUME_NONNULL to suppress fal= se > positives of null pointer dereference warnings during static analysis. > > The patch only includes the macro definition for Clang so far, as I could > not silence GCC's static analyzer false positives without ensuring that > it wouldn't affect the emitted code. > > I tested this patch and use of the macro successfully eliminates false > positives when used properly and does not affect final code generation. > > I am new to contributing to the kernel, so I apologise in advance for > any mistakes. I welcome all feedback or suggestions for improvement. > > Rationale: > - Use of this optional macro can silence false positives which may reduce > patches that fix false positives (such as AI generated patches). > - Clear documentation of a non null assumption for other developers > - Signal to reviewers to subject patches that use this macro to > additional scrutiny, and require justification on why > there isn't a null check in the code instead. > > Motivation: > While running Clang's static analyzer on the Linux kernel, I encountered > hundreds of false positives related to null pointer dereferences. > One such example is in mm/slub.c, where the static analyzer > incorrectly reports a potential null pointer dereference on line 3169. > > n is non-null at that point, but it is non obvious to the static analyzer > (and to humans) that get_node() will always return a non-null pointer. > Since it is in a performance crtical context, adding a null check > would be undesirable (I think). A macro like this can be used to > signal the pointer is invariably non-null, without adding a runtime > check. > > Raka Gunarto (1): > compiler_types.h: introduce ASSUME_NONNULL macro for static analysis > > include/linux/compiler-clang.h | 10 ++++++++++ > include/linux/compiler_types.h | 5 +++++ > 2 files changed, 15 insertions(+) > > -- > 2.43.0 > > _______________________________________________ > Kernelnewbies mailing list > [email protected] > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > --000000000000585360063abff17e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai= ner"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 25, 2025, 17:47 Raka= Gunarto <<a href=3D"mailto:[email protected]">[email protected]= </a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= Hi everyone, I'm a really new contributor and I sent off this<br> RFC to LKML <<a href=3D"https://lore.kernel.org/lkml/20250723140129.2768= [email protected]/T/#m1372eb992552491ac37f46f27e5ad09d9efa35ad" re= l=3D"noreferrer noreferrer" target=3D"_blank">https://lore.kernel.org/lkml/= [email protected]/T/#m1372eb992552491ac37f46f27= e5ad09d9efa35ad</a>>,<br> when I probably should have floated the idea<br> here first. In any case, I've pasted my RFC patch below<br> and I would really like any feedback / suggestions on the<br> idea.<br> <br> Thanks,<br> Raka<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au= to">Hello Raka</div><div dir=3D"auto"><br></div><div dir=3D"auto">Interesti= ng idea. Other than silencing clang analyzer warning, what is exactly the a= dvantage of using such macro?</div><div dir=3D"auto"><br></div><div dir=3D"= auto"><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex"> <br> ---------- Forwarded message ---------<br> From: Raka Gunarto <<a href=3D"mailto:[email protected]" target=3D"_= blank" rel=3D"noreferrer">[email protected]</a>><br> Date: Wed, Jul 23, 2025 at 3:01=E2=80=AFPM<br> Subject: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL<br> macro for static analysis<br> To: <<a href=3D"mailto:[email protected]" target=3D"_blank" r= el=3D"noreferrer">[email protected]</a>><br> Cc: Raka Gunarto <<a href=3D"mailto:[email protected]" target=3D"_bl= ank" rel=3D"noreferrer">[email protected]</a>><br> <br> <br> This proposed patch introduces a new macro ASSUME_NONNULL to suppress false= <br> positives of null pointer dereference warnings during static analysis.<br> <br> The patch only includes the macro definition for Clang so far, as I could<b= r> not silence GCC's static analyzer false positives without ensuring that= <br> it wouldn't affect the emitted code.<br> <br> I tested this patch and use of the macro successfully eliminates false<br> positives when used properly and does not affect final code generation.<br> <br> I am new to contributing to the kernel, so I apologise in advance for<br> any mistakes. I welcome all feedback or suggestions for improvement.<br> <br> Rationale:<br> - Use of this optional macro can silence false positives which may reduce<b= r> =C2=A0 patches that fix false positives (such as AI generated patches).<br> - Clear documentation of a non null assumption for other developers<br> - Signal to reviewers to subject patches that use this macro to<br> =C2=A0 additional scrutiny, and require justification on why<br> =C2=A0 there isn't a null check in the code instead.<br> <br> Motivation:<br> While running Clang's static analyzer on the Linux kernel, I encountere= d<br> hundreds of false positives related to null pointer dereferences.<br> One such example is in mm/slub.c, where the static analyzer<br> incorrectly reports a potential null pointer dereference on line 3169.<br> <br> n is non-null at that point, but it is non obvious to the static analyzer<b= r> (and to humans) that get_node() will always return a non-null pointer.<br> Since it is in a performance crtical context, adding a null check<br> would be undesirable (I think). A macro like this can be used to<br> signal the pointer is invariably non-null, without adding a runtime<br> check.<br> <br> Raka Gunarto (1):<br> =C2=A0 compiler_types.h: introduce ASSUME_NONNULL macro for static analysis= <br> <br> =C2=A0include/linux/compiler-clang.h | 10 ++++++++++<br> =C2=A0include/linux/compiler_types.h |=C2=A0 5 +++++<br> =C2=A02 files changed, 15 insertions(+)<br> <br> --<br> 2.43.0<br> <br> _______________________________________________<br> Kernelnewbies mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D= "noreferrer">[email protected]</a><br> <a href=3D"https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" = rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.kernelnewbies= .org/mailman/listinfo/kernelnewbies</a><br> </blockquote></div></div></div> --000000000000585360063abff17e-- --===============8294373514154441007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============8294373514154441007==--