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

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

[Raka Gunarto]

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

---------- Forwarded message ---------
From: Raka Gunarto <rakagunarto@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@vger.kernel.org>
Cc: Raka Gunarto <rakagunarto@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

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

[Greg KH]

On Fri, Jul 25, 2025 at 11:34:05AM +0100, Raka Gunarto 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.

We don't take patches for code that is not actually used.  You added a
macro here that is never called, so why is it even needed?  That's a
good reason why it was ignored.

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

[Mulyadi Santosa]

[-- Attachment #1.1: Type: text/plain, Size: 3115 bytes --]

On Fri, Jul 25, 2025, 17:47 Raka Gunarto <rakagunarto@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@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@vger.kernel.org>
> Cc: Raka Gunarto <rakagunarto@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
>

[-- Attachment #1.2: Type: text/html, Size: 4565 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

[Raka Gunarto]

On Fri, Jul 25, 2025 at 1:19 PM Mulyadi Santosa
<mulyadi.santosa@gmail.com> wrote:
> Interesting idea. Other than silencing clang analyzer warning, what is exactly the advantage of using such macro?

Well there are three main advantages that I saw:
- Clarity to readers that the pointer is guaranteed to be non-null,
and that a check is redundant (because performance critical context,
etc.)
- Future patches that decide to use this macro can be a signal to
reviewers to actually check correctness that a pointer is indeed
invariably non-null
- Make static analysis more useful by documenting when a certain false
positive is actually false

I also wondered if it could reduce the possibility and volume of AI
generated patches from just running analyzers on the kernel to reduce
noise.

I was also planning to create a heuristic tool to check a patch if a
code change could affect a path using this macro and break the
assertion.

Raka

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

[Siddh Raman Pant]

[-- Attachment #1.1: Type: text/plain, Size: 924 bytes --]

---- Fri, 25 Jul 2025 18:12:14 +0530 को rakagunarto@gmail.com ने लिखा ----

> - Clarity to readers that the pointer is guaranteed to be non-null,


Assumption isn't a guarantee.


> and that a check is redundant (because performance critical context,
> etc.)


Compiler optimises it away usually.

> - Future patches that decide to use this macro can be a signal to
> reviewers to actually check correctness that a pointer is indeed
> invariably non-null


That can pretty easily change in future.


> - Make static analysis more useful by documenting when a certain false
> positive is actually false


Is your case really a false positive?


There is an explicit check for NULL in some other using the
get_node function, most visibly in the macro below.


If we know NULL won't be there, we should add an
assert in code instead of a silent assumption.


Thanks,
Siddh

[-- Attachment #1.2: Type: text/html, Size: 3261 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

[Greg KH]

On Fri, Jul 25, 2025 at 01:42:14PM +0100, Raka Gunarto wrote:
> On Fri, Jul 25, 2025 at 1:19 PM Mulyadi Santosa
> <mulyadi.santosa@gmail.com> wrote:
> > Interesting idea. Other than silencing clang analyzer warning, what is exactly the advantage of using such macro?
> 
> Well there are three main advantages that I saw:
> - Clarity to readers that the pointer is guaranteed to be non-null,
> and that a check is redundant (because performance critical context,
> etc.)

We already assume this in loads of places today, there's no need to
explicitly mark it as such everywhere, as that would litter almost every
single function in the kernel :(

> - Future patches that decide to use this macro can be a signal to
> reviewers to actually check correctness that a pointer is indeed
> invariably non-null

That's up to the caller, not a reviewer, to keep straight.

> - Make static analysis more useful by documenting when a certain false
> positive is actually false

Fix the tool, not the kernel code, when the tool is broken.  It's not
Linux's job to paste over broken external things.

> I also wondered if it could reduce the possibility and volume of AI
> generated patches from just running analyzers on the kernel to reduce
> noise.

Have you seen any such reports yet?  The ones I've seen are not due to
this type of thing at all, they are much more "real looking" yet fall
apart when a person actually reads the code.

Here's one such "fake report" example if you enjoy reading this type of
thing:
	https://lore.kernel.org/r/tencent_21B82DB792FE0049B6EF5ECD81285669C908@qq.com

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

[Raka Gunarto]

On Fri, Jul 25, 2025 at 2:56 PM Greg KH <greg@kroah.com> wrote:
> We already assume this in loads of places today, there's no need to
> explicitly mark it as such everywhere, as that would litter almost every
> single function in the kernel :(

I suppose based on this alone I should rethink the usefulness of this patch,
especially if the next step would be to blast apply it everywhere.

Although I was more thinking of future use, and clarity to future readers
on why a pointer couldn't be null.

I'll respond to the other points but I'll have a rethink on whether or not
this is an actually useful addition, or whether or not we could deal with
static analyser false positives in a better way.

> Fix the tool, not the kernel code, when the tool is broken.  It's not
> Linux's job to paste over broken external things.

Understood, however I recognise static analysis is complex and there
are many non obvious cases of why something is a false positive.
My rationale was that adding this macro and a comment to document
for example, a non obvious non-null pointer, could be useful to
readers.

On Fri, Jul 25, 2025 at 2:29 PM Siddh Raman Pant <sanganaka@siddh.me> wrote:
> Assumption isn't a guarantee.
> Compiler optimises it away usually.

Yes, but my point was it is guaranteed in some cases, just not
obvious to the static analyzer and since the compiler /
static analyzer use similar techniques to detect certain
conditions, the compiler won't optimise a redundant check
away either.

> That can pretty easily change in future.

Isn't it more dangerous to have a non obvious assumption
be in the blast radius of a change that makes that
assumption invalid, rather than making it obvious in some
way?

> Is your case really a false positive?

From my very limited understanding of the slab allocator,
I think it is a false positive because it is only called
on valid slabs (initial slab must be non-null and
it just traverses the list).

Thank you all for the feedback, it was very insightful
for me as an aspiring contributor!

Raka

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

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

[Tom Mitchell]

[-- Attachment #1.1: Type: text/plain, Size: 2767 bytes --]

Interesting...
Missing in this is the static analysis tool, name and version.
There are many.

At the source level one might start with an assert().   Assuming nonnull
implies null is legal and would  be handled correctly if not optimal.

Interesting
..

Sent-mobile
T o m   M i t c h e l l

On Fri, Jul 25, 2025, 8:24 AM Raka Gunarto <rakagunarto@gmail.com> wrote:

> On Fri, Jul 25, 2025 at 2:56 PM Greg KH <greg@kroah.com> wrote:
> > We already assume this in loads of places today, there's no need to
> > explicitly mark it as such everywhere, as that would litter almost every
> > single function in the kernel :(
>
> I suppose based on this alone I should rethink the usefulness of this
> patch,
> especially if the next step would be to blast apply it everywhere.
>
> Although I was more thinking of future use, and clarity to future readers
> on why a pointer couldn't be null.
>
> I'll respond to the other points but I'll have a rethink on whether or not
> this is an actually useful addition, or whether or not we could deal with
> static analyser false positives in a better way.
>
> > Fix the tool, not the kernel code, when the tool is broken.  It's not
> > Linux's job to paste over broken external things.
>
> Understood, however I recognise static analysis is complex and there
> are many non obvious cases of why something is a false positive.
> My rationale was that adding this macro and a comment to document
> for example, a non obvious non-null pointer, could be useful to
> readers.
>
> On Fri, Jul 25, 2025 at 2:29 PM Siddh Raman Pant <sanganaka@siddh.me>
> wrote:
> > Assumption isn't a guarantee.
> > Compiler optimises it away usually.
>
> Yes, but my point was it is guaranteed in some cases, just not
> obvious to the static analyzer and since the compiler /
> static analyzer use similar techniques to detect certain
> conditions, the compiler won't optimise a redundant check
> away either.
>
> > That can pretty easily change in future.
>
> Isn't it more dangerous to have a non obvious assumption
> be in the blast radius of a change that makes that
> assumption invalid, rather than making it obvious in some
> way?
>
> > Is your case really a false positive?
>
> From my very limited understanding of the slab allocator,
> I think it is a false positive because it is only called
> on valid slabs (initial slab must be non-null and
> it just traverses the list).
>
> Thank you all for the feedback, it was very insightful
> for me as an aspiring contributor!
>
> Raka
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

[-- Attachment #1.2: Type: text/html, Size: 3836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies