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

--===============2829682626267487930==
Content-Type: multipart/alternative; boundary="000000000000e6751f063ac3f1ff"

--000000000000e6751f063ac3f1ff
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Raka Gunarto <[email protected]> =
wrote:

> On Fri, Jul 25, 2025 at 2:56=E2=80=AFPM Greg KH <[email protected]> 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 ever=
y
> > 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 no=
t
> 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=E2=80=AFPM 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
> [email protected]
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

--000000000000e6751f063ac3f1ff
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Interesting...</div><div dir=3D"auto">Missing in thi=
s is the static analysis tool, name and version.</div><div dir=3D"auto">The=
re are many.</div><div dir=3D"auto"><br></div><div dir=3D"auto">At the sour=
ce level one might start with an assert().=C2=A0 =C2=A0Assuming nonnull imp=
lies null is legal and would=C2=A0 be handled correctly if not optimal.=C2=
=A0 =C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Interesting</=
div><div dir=3D"auto">..</div><div><br></div><div data-smartmail=3D"gmail_s=
ignature">Sent-mobile<br>T o m=C2=A0=C2=A0 M i t c h e l l</div></div><br><=
div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g=
mail_attr">On Fri, Jul 25, 2025, 8:24=E2=80=AFAM Raka Gunarto &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jul 25, 2025=
 at 2:56=E2=80=AFPM Greg KH &lt;<a href=3D"mailto:[email protected]" target=3D=
"_blank" rel=3D"noreferrer">[email protected]</a>&gt; wrote:<br>
&gt; We already assume this in loads of places today, there&#39;s no need t=
o<br>
&gt; explicitly mark it as such everywhere, as that would litter almost eve=
ry<br>
&gt; 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<b=
r>
on why a pointer couldn&#39;t be null.<br>
<br>
I&#39;ll respond to the other points but I&#39;ll have a rethink on whether=
 or not<br>
this is an actually useful addition, or whether or not we could deal with<b=
r>
static analyser false positives in a better way.<br>
<br>
&gt; Fix the tool, not the kernel code, when the tool is broken.=C2=A0 It&#=
39;s not<br>
&gt; Linux&#39;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=E2=80=AFPM Siddh Raman Pant &lt;<a href=3D"mai=
lto:[email protected]" target=3D"_blank" rel=3D"noreferrer">sanganaka@sidd=
h.me</a>&gt; wrote:<br>
&gt; Assumption isn&#39;t a guarantee.<br>
&gt; 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&#39;t optimise a redundant check<br>
away either.<br>
<br>
&gt; That can pretty easily change in future.<br>
<br>
Isn&#39;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>
&gt; 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=3D"mailto:[email protected]" target=3D"_blank" rel=3D=
"noreferrer">[email protected]</a><br>
<a href=3D"https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.kernelnewbies=
.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div>

--000000000000e6751f063ac3f1ff--


--===============2829682626267487930==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Kernelnewbies mailing list
[email protected]
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

--===============2829682626267487930==--