False positives could be introduced due to allocations using the new
_obj functions.  Add these to the "safe" rule accordingly.

False positives could also be introduced when the same variable
name has two possible types.  Incorporate type informationt to avoid
reporting this case  This does lead to false negatives when no type
information is available.

Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reported-by: Ricardo Ribalda <ribalda@chromium.org>

---
 scripts/coccinelle/free/devm_free.cocci |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/scripts/coccinelle/free/devm_free.cocci b/scripts/coccinelle/free/devm_free.cocci
index 0880729ba..947d7e685 100644
--- a/scripts/coccinelle/free/devm_free.cocci
+++ b/scripts/coccinelle/free/devm_free.cocci
@@ -26,7 +26,8 @@ virtual report
 virtual context
 
 @r depends on context || org || report@
-expression x;
+type T;
+T x;
 @@
 
 (
@@ -56,18 +57,26 @@ expression x;
 )
 
 @safe depends on context || org || report exists@
-expression x;
+r.T x;
 position p;
 @@
 
 (
  x = kmalloc(...)
+|
+ x = kmalloc_obj(...)
+|
+ x = kmalloc_objs(...)
 |
  x = kvasprintf(...)
 |
  x = kasprintf(...)
 |
  x = kzalloc(...)
+|
+ x = kzalloc_obj(...)
+|
+ x = kzalloc_objs(...)
 |
  x = kmalloc_array(...)
 |
@@ -105,7 +114,7 @@ position p;
 )
 
 @pb@
-expression r.x;
+r.T r.x;
 position p != safe.p;
 @@

> False positives could be introduced due to allocations using the new
> _obj functions.  Add these to the "safe" rule accordingly.

Can the SmPL disjunction specification be refined another bit?


…
> name has two possible types.  Incorporate type informationt to avoid
…
                                                 information?

Regards,
Markus

On Mon, 10 Aug 2026, Markus Elfring wrote:

> > False positives could be introduced due to allocations using the new
> > _obj functions.  Add these to the "safe" rule accordingly.
>
> Can the SmPL disjunction specification be refined another bit?

As usual, a random comment with no context that makes the reader have to
go look up some other information to have any idea what you are talking
about.

Anyway, since I did take several minutes to go find the file and look at
it, I guess you want the disjunctions to be ordered by frequency in the
code base.  But I'm not going to do that.

> …
> > name has two possible types.  Incorporate type informationt to avoid
> …
>                                                  information?

Thanks.  Fixed.

julia

>
> Regards,
> Markus
>

> Anyway, since I did take several minutes to go find the file and look at
> it,

https://elixir.bootlin.com/linux/v7.2-rc6/source/scripts/coccinelle/free/devm_free.cocci#L58-L105

Patch review might take another while.


>     I guess you want the disjunctions to be ordered by frequency in the
> code base.  But I'm not going to do that.

Which factors do hinder the clarification of further desirable improvements
also for related software areas so far?

Regards,
Markus

>>> False positives could be introduced due to allocations using the new
>>> _obj functions.  Add these to the "safe" rule accordingly.
>>
>> Can the SmPL disjunction specification be refined another bit?
> 
> As usual, a random comment with no context that makes the reader have to
> go look up some other information to have any idea what you are talking
> about.

How hard is it to determine technical details for a running patch review?


> Anyway, since I did take several minutes to go find the file and look at
> it,

You propose to adjust some SmPL code.


>     I guess you want the disjunctions to be ordered by frequency in the
> code base.

I imagine that such a design possibility can become helpful.


>             But I'm not going to do that.

I assume that further contributors would occasionally like to benefit
more from nicer run time characteristics also for Coccinelle software.
https://en.wikipedia.org/wiki/Short-circuit_evaluation

Can SmPL code become a bit more succinct accordingly?

Regards,
Markus