[RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis

Mulyadi Santosa mulyadi.santosa at gmail.com
Fri Jul 25 08:18:29 EDT 2025


On Fri, Jul 25, 2025, 17:47 Raka Gunarto <rakagunarto at 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-rakagunarto@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 <rakagunarto at 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-kernel at vger.kernel.org>
> Cc: Raka Gunarto <rakagunarto at 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 at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20250725/207b1d1e/attachment.html>


More information about the Kernelnewbies mailing list