Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis
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...>, 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
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...>, 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
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...
, 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
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
---- 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
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.co... thanks, greg k-h
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
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
participants (5)
-
Greg KH -
Mulyadi Santosa -
Raka Gunarto -
Siddh Raman Pant -
Tom Mitchell