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