* Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis [not found] <20250723140129.276874-1-rakagunarto@gmail.com> @ 2025-07-25 10:34 ` Raka Gunarto 2025-07-25 12:06 ` Greg KH 2025-07-25 12:18 ` Mulyadi Santosa 0 siblings, 2 replies; 8+ messages in thread From: Raka Gunarto @ 2025-07-25 10:34 UTC (permalink / raw) To: Kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis 2025-07-25 10:34 ` Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis Raka Gunarto @ 2025-07-25 12:06 ` Greg KH 2025-07-25 12:18 ` Mulyadi Santosa 1 sibling, 0 replies; 8+ messages in thread From: Greg KH @ 2025-07-25 12:06 UTC (permalink / raw) To: Raka Gunarto; +Cc: Kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis 2025-07-25 10:34 ` Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis Raka Gunarto 2025-07-25 12:06 ` Greg KH @ 2025-07-25 12:18 ` Mulyadi Santosa 2025-07-25 12:42 ` Raka Gunarto 1 sibling, 1 reply; 8+ messages in thread From: Mulyadi Santosa @ 2025-07-25 12:18 UTC (permalink / raw) To: kernelnewbies [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis 2025-07-25 12:18 ` Mulyadi Santosa @ 2025-07-25 12:42 ` Raka Gunarto 2025-07-25 13:28 ` Siddh Raman Pant 2025-07-25 13:56 ` Greg KH 0 siblings, 2 replies; 8+ messages in thread From: Raka Gunarto @ 2025-07-25 12:42 UTC (permalink / raw) To: Mulyadi Santosa; +Cc: 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis 2025-07-25 12:42 ` Raka Gunarto @ 2025-07-25 13:28 ` Siddh Raman Pant 2025-07-25 13:56 ` Greg KH 1 sibling, 0 replies; 8+ messages in thread From: Siddh Raman Pant @ 2025-07-25 13:28 UTC (permalink / raw) To: rakagunarto; +Cc: mulyadi.santosa, Kernelnewbies [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis 2025-07-25 12:42 ` Raka Gunarto 2025-07-25 13:28 ` Siddh Raman Pant @ 2025-07-25 13:56 ` Greg KH 2025-07-25 15:07 ` Raka Gunarto 1 sibling, 1 reply; 8+ messages in thread From: Greg KH @ 2025-07-25 13:56 UTC (permalink / raw) To: Raka Gunarto; +Cc: Mulyadi Santosa, kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis 2025-07-25 13:56 ` Greg KH @ 2025-07-25 15:07 ` Raka Gunarto 2025-07-25 17:04 ` Tom Mitchell 0 siblings, 1 reply; 8+ messages in thread From: Raka Gunarto @ 2025-07-25 15:07 UTC (permalink / raw) To: Greg KH, Siddh Raman Pant; +Cc: Mulyadi Santosa, kernelnewbies 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis 2025-07-25 15:07 ` Raka Gunarto @ 2025-07-25 17:04 ` Tom Mitchell 0 siblings, 0 replies; 8+ messages in thread From: Tom Mitchell @ 2025-07-25 17:04 UTC (permalink / raw) To: Raka Gunarto; +Cc: Greg KH, kernelnewbies, Mulyadi Santosa [-- 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-07-25 17:19 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20250723140129.276874-1-rakagunarto@gmail.com>
2025-07-25 10:34 ` Fwd: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis Raka Gunarto
2025-07-25 12:06 ` Greg KH
2025-07-25 12:18 ` Mulyadi Santosa
2025-07-25 12:42 ` Raka Gunarto
2025-07-25 13:28 ` Siddh Raman Pant
2025-07-25 13:56 ` Greg KH
2025-07-25 15:07 ` Raka Gunarto
2025-07-25 17:04 ` Tom Mitchell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox