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

From: Raka Gunarto <rakagunarto@gmail.com>
To: Greg KH <greg@kroah.com>, Siddh Raman Pant <sanganaka@siddh.me>
Cc: Mulyadi Santosa <mulyadi.santosa@gmail.com>,
	kernelnewbies <Kernelnewbies@kernelnewbies.org>
Subject: Re: [RFC PATCH 0/1] compiler_types.h: introduce ASSUME_NONNULL macro for static analysis
Date: Fri, 25 Jul 2025 16:07:36 +0100	[thread overview]
Message-ID: <CACUOwmJxNbf6yFJMj4A8qG_+7W=pRMcqbgTzg0qGbM26TdFqOg@mail.gmail.com> (raw)
In-Reply-To: <2025072517-prenatal-vendetta-a9aa@gregkh>

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