On Fri, Jul 25, 2025, 17:47 Raka Gunarto <rakaguna...@gmail.com> wrote:
> Hi everyone, I'm a really new contributor and I sent off this > RFC to LKML < > https://lore.kernel.org/lkml/20250723140129.276874-1-rakaguna...@gmail.com/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 <rakaguna...@gmail.com> > Date: Wed, Jul 23, 2025 at 3:01 PM > Subject: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL > macro for static analysis > To: <linux-ker...@vger.kernel.org> > Cc: Raka Gunarto <rakaguna...@gmail.com> > > > This proposed patch introduces a new macro ASSUME_NONNULL to suppress false > 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 > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
