<div dir="auto"><div>Interesting...</div><div dir="auto">Missing in this is the static analysis tool, name and version.</div><div dir="auto">There are many.</div><div dir="auto"><br></div><div dir="auto">At the source level one might start with an assert().   Assuming nonnull implies null is legal and would  be handled correctly if not optimal.   </div><div dir="auto"><br></div><div dir="auto">Interesting</div><div dir="auto">..</div><div><br></div><div data-smartmail="gmail_signature">Sent-mobile<br>T o m   M i t c h e l l</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jul 25, 2025, 8:24 AM Raka Gunarto <<a href="mailto:rakagunarto@gmail.com">rakagunarto@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jul 25, 2025 at 2:56 PM Greg KH <<a href="mailto:greg@kroah.com" target="_blank" rel="noreferrer">greg@kroah.com</a>> wrote:<br>
> We already assume this in loads of places today, there's no need to<br>
> explicitly mark it as such everywhere, as that would litter almost every<br>
> single function in the kernel :(<br>
<br>
I suppose based on this alone I should rethink the usefulness of this patch,<br>
especially if the next step would be to blast apply it everywhere.<br>
<br>
Although I was more thinking of future use, and clarity to future readers<br>
on why a pointer couldn't be null.<br>
<br>
I'll respond to the other points but I'll have a rethink on whether or not<br>
this is an actually useful addition, or whether or not we could deal with<br>
static analyser false positives in a better way.<br>
<br>
> Fix the tool, not the kernel code, when the tool is broken.  It's not<br>
> Linux's job to paste over broken external things.<br>
<br>
Understood, however I recognise static analysis is complex and there<br>
are many non obvious cases of why something is a false positive.<br>
My rationale was that adding this macro and a comment to document<br>
for example, a non obvious non-null pointer, could be useful to<br>
readers.<br>
<br>
On Fri, Jul 25, 2025 at 2:29 PM Siddh Raman Pant <<a href="mailto:sanganaka@siddh.me" target="_blank" rel="noreferrer">sanganaka@siddh.me</a>> wrote:<br>
> Assumption isn't a guarantee.<br>
> Compiler optimises it away usually.<br>
<br>
Yes, but my point was it is guaranteed in some cases, just not<br>
obvious to the static analyzer and since the compiler /<br>
static analyzer use similar techniques to detect certain<br>
conditions, the compiler won't optimise a redundant check<br>
away either.<br>
<br>
> That can pretty easily change in future.<br>
<br>
Isn't it more dangerous to have a non obvious assumption<br>
be in the blast radius of a change that makes that<br>
assumption invalid, rather than making it obvious in some<br>
way?<br>
<br>
> Is your case really a false positive?<br>
<br>
>From my very limited understanding of the slab allocator,<br>
I think it is a false positive because it is only called<br>
on valid slabs (initial slab must be non-null and<br>
it just traverses the list).<br>
<br>
Thank you all for the feedback, it was very insightful<br>
for me as an aspiring contributor!<br>
<br>
Raka<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank" rel="noreferrer">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div>