public inbox for cocci@systeme.lip6.fr
 help / color / mirror / Atom feed
* [cocci] Searching for missing cleanup function calls (with SmPL)?
@ 2025-09-04 12:36 Markus Elfring
  2025-09-04 12:43 ` Julia Lawall
  2025-09-06  8:00 ` [cocci] Searching for selected variable assignments " Markus Elfring
  0 siblings, 2 replies; 25+ messages in thread
From: Markus Elfring @ 2025-09-04 12:36 UTC (permalink / raw)
  To: cocci

Hello,

I tried the following script out for the semantic patch language.


@display@
expression e;
statement s;
struct device_node * dn;
@@
*dn = e(...);
 if (!dn)
    s
 ... when != dn


It can be determined then that the software “Linux next-20250904” contains
80 variable assignments where the object address might not be used any more
after a null pointer check.

* Would you be looking for corresponding improvements of such a source code
  search approach?

* How do you think about to take further data structures into account
  for which objects should usually be released by a cleanup function?
  Can the search pattern become more generic and safer?


Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for missing cleanup function calls (with SmPL)?
  2025-09-04 12:36 [cocci] Searching for missing cleanup function calls (with SmPL)? Markus Elfring
@ 2025-09-04 12:43 ` Julia Lawall
  2025-09-04 12:58   ` Markus Elfring
                     ` (2 more replies)
  2025-09-06  8:00 ` [cocci] Searching for selected variable assignments " Markus Elfring
  1 sibling, 3 replies; 25+ messages in thread
From: Julia Lawall @ 2025-09-04 12:43 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]



On Thu, 4 Sep 2025, Markus Elfring wrote:

> Hello,
>
> I tried the following script out for the semantic patch language.
>
>
> @display@
> expression e;
> statement s;
> struct device_node * dn;
> @@
> *dn = e(...);
>  if (!dn)
>     s
>  ... when != dn
>
>
> It can be determined then that the software “Linux next-20250904” contains
> 80 variable assignments where the object address might not be used any more
> after a null pointer check.
>
> * Would you be looking for corresponding improvements of such a source code
>   search approach?
>
> * How do you think about to take further data structures into account
>   for which objects should usually be released by a cleanup function?
>   Can the search pattern become more generic and safer?

You could add idexpression to the front of the line declaring the dn
metavariable.  If dn is a->b then perhaps the value is used elsewhere.

But if there are cases where dn really should be freed, that could be
something to write a patch for.

julia

>
>
> Regards,
> Markus
>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for missing cleanup function calls (with SmPL)?
  2025-09-04 12:43 ` Julia Lawall
@ 2025-09-04 12:58   ` Markus Elfring
  2025-09-12  9:29   ` Markus Elfring
  2025-09-12 15:43   ` Markus Elfring
  2 siblings, 0 replies; 25+ messages in thread
From: Markus Elfring @ 2025-09-04 12:58 UTC (permalink / raw)
  To: Julia Lawall, cocci

…>> @display@
>> expression e;
>> statement s;
>> struct device_node * dn;
>> @@
>> *dn = e(...);
>>  if (!dn)
>>     s
>>  ... when != dn
…>> * How do you think about to take further data structures into account
>>   for which objects should usually be released by a cleanup function?
>>   Can the search pattern become more generic and safer?
…> But if there are cases where dn really should be freed, that could be
> something to write a patch for.

Would it be possible to handle a list of known data structure identifiers
in a dynamic way anyhow here?

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-04 12:36 [cocci] Searching for missing cleanup function calls (with SmPL)? Markus Elfring
  2025-09-04 12:43 ` Julia Lawall
@ 2025-09-06  8:00 ` Markus Elfring
  2025-09-06  8:07   ` Julia Lawall
  1 sibling, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06  8:00 UTC (permalink / raw)
  To: cocci

> @display@
> expression e;
> statement s;
> struct device_node * dn;
> @@
> *dn = e(...);
>  if (!dn)
>     s
>  ... when != dn
> 
> 
> It can be determined then that the software “Linux next-20250904” contains
> 80 variable assignments where the object address might not be used any more
> after a null pointer check.
> 
> * Would you be looking for corresponding improvements of such a source code
>   search approach?

Such an SmPL script can become another bit more generic.
How can be achieved that the search for variable assignments will be repeated
after such a statement was found?

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  8:00 ` [cocci] Searching for selected variable assignments " Markus Elfring
@ 2025-09-06  8:07   ` Julia Lawall
  2025-09-06  8:10     ` Markus Elfring
  2025-09-06 13:20     ` Markus Elfring
  0 siblings, 2 replies; 25+ messages in thread
From: Julia Lawall @ 2025-09-06  8:07 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]



On Sat, 6 Sep 2025, Markus Elfring wrote:

> > @display@
> > expression e;
> > statement s;
> > struct device_node * dn;
> > @@
> > *dn = e(...);
> >  if (!dn)
> >     s
> >  ... when != dn
> >
> >
> > It can be determined then that the software “Linux next-20250904” contains
> > 80 variable assignments where the object address might not be used any more
> > after a null pointer check.
> >
> > * Would you be looking for corresponding improvements of such a source code
> >   search approach?
>
> Such an SmPL script can become another bit more generic.
> How can be achieved that the search for variable assignments will be repeated
> after such a statement was found?

There is no after.  Such variable assignments are matched throughout the
entire function.

julia

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  8:07   ` Julia Lawall
@ 2025-09-06  8:10     ` Markus Elfring
  2025-09-06  8:22       ` Julia Lawall
  2025-09-06 13:20     ` Markus Elfring
  1 sibling, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06  8:10 UTC (permalink / raw)
  To: Julia Lawall, cocci

>> Such an SmPL script can become another bit more generic.
>> How can be achieved that the search for variable assignments will be repeated
>> after such a statement was found?
> There is no after.  Such variable assignments are matched throughout the
> entire function.

Do I indicate a desirable extension for the Coccinelle software?

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  8:10     ` Markus Elfring
@ 2025-09-06  8:22       ` Julia Lawall
  2025-09-06  9:11         ` Markus Elfring
  0 siblings, 1 reply; 25+ messages in thread
From: Julia Lawall @ 2025-09-06  8:22 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci



On Sat, 6 Sep 2025, Markus Elfring wrote:

> >> Such an SmPL script can become another bit more generic.
> >> How can be achieved that the search for variable assignments will be repeated
> >> after such a statement was found?
> > There is no after.  Such variable assignments are matched throughout the
> > entire function.
>
> Do I indicate a desirable extension for the Coccinelle software?

No you asked for a feature, I said that that is already what happens.  So
I don't know what you would see as an extension.

julia


>
> Regards,
> Markus
>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  8:22       ` Julia Lawall
@ 2025-09-06  9:11         ` Markus Elfring
  2025-09-06  9:14           ` Julia Lawall
  0 siblings, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06  9:11 UTC (permalink / raw)
  To: Julia Lawall, cocci

>> Do I indicate a desirable extension for the Coccinelle software?
> 
> No you asked for a feature, I said that that is already what happens.
> So I don't know what you would see as an extension.

Would you get further development ideas from an SmPL script variant
like the following?


@find1@
expression e;
position place;
type t;
t * pointer;
@@
 pointer = e(...);@place

@display1@
position find1.place;
statement s;
type find1.t;
t * find1.pointer;
@@
*;@place
 if (!pointer)
    s
 ... when != pointer

@find2@
expression e;
position find1.place, place2;
type t;
t * pointer;
@@
 ;@place
 ... when != pointer
 pointer = e(...);@place2

@display2@
position find2.place2;
statement s;
type find2.t;
t * find2.pointer;
@@
*;@place2
 if (!pointer)
    s
 ... when != pointer


Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  9:11         ` Markus Elfring
@ 2025-09-06  9:14           ` Julia Lawall
  2025-09-06  9:28             ` Markus Elfring
  0 siblings, 1 reply; 25+ messages in thread
From: Julia Lawall @ 2025-09-06  9:14 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci



On Sat, 6 Sep 2025, Markus Elfring wrote:

> >> Do I indicate a desirable extension for the Coccinelle software?
> >
> > No you asked for a feature, I said that that is already what happens.
> > So I don't know what you would see as an extension.
>
> Would you get further development ideas from an SmPL script variant
> like the following?
>
>
> @find1@
> expression e;
> position place;
> type t;
> t * pointer;
> @@
>  pointer = e(...);@place
>
> @display1@
> position find1.place;
> statement s;
> type find1.t;
> t * find1.pointer;
> @@
> *;@place
>  if (!pointer)
>     s
>  ... when != pointer
>
> @find2@
> expression e;
> position find1.place, place2;
> type t;
> t * pointer;
> @@
>  ;@place
>  ... when != pointer
>  pointer = e(...);@place2
>
> @display2@
> position find2.place2;
> statement s;
> type find2.t;
> t * find2.pointer;
> @@
> *;@place2
>  if (!pointer)
>     s
>  ... when != pointer

I don't get the point.  display2 should match a subset of the places
matched by display 1.

julia

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  9:14           ` Julia Lawall
@ 2025-09-06  9:28             ` Markus Elfring
  2025-09-06 10:25               ` Markus Elfring
  0 siblings, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06  9:28 UTC (permalink / raw)
  To: Julia Lawall, cocci

>> Would you get further development ideas from an SmPL script variant
>> like the following?
…> I don't get the point.

Multiple SmPL rules can be evaluated.
I am unsure if evaluation loops can be achieved for the shown use case.


>                         display2 should match a subset of the places
> matched by display 1.

I hope so.

We might not be able to continue a search directly after a known source code position.
But I assume that it would be possible to direct a search repetition to the place
which was determined before (according to a semicolon for example).

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  9:28             ` Markus Elfring
@ 2025-09-06 10:25               ` Markus Elfring
  2025-09-06 11:12                 ` Julia Lawall
  0 siblings, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06 10:25 UTC (permalink / raw)
  To: Julia Lawall, cocci

> We might not be able to continue a search directly after a known source code position.
> But I assume that it would be possible to direct a search repetition to the place
> which was determined before (according to a semicolon for example).

The initially mentioned SmPL script pointed the implementation of the function “arm_dt_init_cpu_maps”
(besides others) for further development considerations.
https://elixir.bootlin.com/linux/v6.17-rc4/source/arch/arm/kernel/devtree.c#L59-L165

I tried also the following SmPL script variant out.


@find@
expression e;
position place;
type t;
t * pointer;
@@
 pointer = e(...);@place

@display@
position find.place;
statement s;
type find.t;
t * find.pointer;
@@
*;@place
 if (!pointer)
    s
 ... when != pointer


Unfortunately, it does not present the known implementation details.

Questionable test result:
Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_unused_addresses_from_variable_assignments.cocci arch/arm/kernel/devtree.c
…
[no diff output]


I would appreciate corresponding software improvements.

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 10:25               ` Markus Elfring
@ 2025-09-06 11:12                 ` Julia Lawall
  2025-09-06 12:07                   ` Markus Elfring
  0 siblings, 1 reply; 25+ messages in thread
From: Julia Lawall @ 2025-09-06 11:12 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]



On Sat, 6 Sep 2025, Markus Elfring wrote:

> > We might not be able to continue a search directly after a known source code position.
> > But I assume that it would be possible to direct a search repetition to the place
> > which was determined before (according to a semicolon for example).
>
> The initially mentioned SmPL script pointed the implementation of the function “arm_dt_init_cpu_maps”
> (besides others) for further development considerations.
> https://elixir.bootlin.com/linux/v6.17-rc4/source/arch/arm/kernel/devtree.c#L59-L165
>
> I tried also the following SmPL script variant out.
>
>
> @find@
> expression e;
> position place;
> type t;
> t * pointer;
> @@
>  pointer = e(...);@place
>
> @display@
> position find.place;
> statement s;
> type find.t;
> t * find.pointer;
> @@
> *;@place
>  if (!pointer)
>     s
>  ... when != pointer

how about:

pointer = e(...);
if (!pointer) s
... when != pointer
? pointer = ...;

julia



>
>
> Unfortunately, it does not present the known implementation details.
>
> Questionable test result:
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_unused_addresses_from_variable_assignments.cocci arch/arm/kernel/devtree.c
> …
> [no diff output]
>
>
> I would appreciate corresponding software improvements.
>
> Regards,
> Markus
>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 11:12                 ` Julia Lawall
@ 2025-09-06 12:07                   ` Markus Elfring
  2025-09-06 12:13                     ` Julia Lawall
  0 siblings, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06 12:07 UTC (permalink / raw)
  To: Julia Lawall, cocci

>> @find@
>> expression e;
>> position place;
>> type t;
>> t * pointer;
>> @@
>>  pointer = e(...);@place
>>
>> @display@
>> position find.place;
>> statement s;
>> type find.t;
>> t * find.pointer;
>> @@
>> *;@place
>>  if (!pointer)
>>     s
>>  ... when != pointer
> 
> how about:
> 
> pointer = e(...);
> if (!pointer) s
> ... when != pointer
> ? pointer = ...;

Do you support to split the search approach into multiple SmPL rules
also with the application of additional position variables?

The following SmPL script variant seems to work as expected.

@display@
expression e;
statement s;
type t;
t * pointer;
@@
*pointer = e(...);
 if (!pointer)
    s
 ... when != pointer


Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_unused_addresses_from_variable_assignments2.cocci arch/arm/kernel/devtree.c
…
@@ -77,7 +77,6 @@ void __init arm_dt_init_cpu_maps(void)
 
        u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
        bool bootcpu_valid = false;
-       cpus = of_find_node_by_path("/cpus");
 
        if (!cpus)
                return;


Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 12:07                   ` Markus Elfring
@ 2025-09-06 12:13                     ` Julia Lawall
  2025-09-06 12:30                       ` Markus Elfring
  0 siblings, 1 reply; 25+ messages in thread
From: Julia Lawall @ 2025-09-06 12:13 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Julia Lawall, cocci

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]



On Sat, 6 Sep 2025, Markus Elfring wrote:

> >> @find@
> >> expression e;
> >> position place;
> >> type t;
> >> t * pointer;
> >> @@
> >>  pointer = e(...);@place
> >>
> >> @display@
> >> position find.place;
> >> statement s;
> >> type find.t;
> >> t * find.pointer;
> >> @@
> >> *;@place

This line certainly doesn't work.  It is searching for an empty statement
at a place where there is an assignment statement.

julia

> >>  if (!pointer)
> >>     s
> >>  ... when != pointer
> >
> > how about:
> >
> > pointer = e(...);
> > if (!pointer) s
> > ... when != pointer
> > ? pointer = ...;
>
> Do you support to split the search approach into multiple SmPL rules
> also with the application of additional position variables?
>
> The following SmPL script variant seems to work as expected.
>
> @display@
> expression e;
> statement s;
> type t;
> t * pointer;
> @@
> *pointer = e(...);
>  if (!pointer)
>     s
>  ... when != pointer
>
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> /usr/bin/spatch --no-loops …/Projekte/Coccinelle/janitor/show_unused_addresses_from_variable_assignments2.cocci arch/arm/kernel/devtree.c
> …
> @@ -77,7 +77,6 @@ void __init arm_dt_init_cpu_maps(void)
>
>         u32 tmp_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
>         bool bootcpu_valid = false;
> -       cpus = of_find_node_by_path("/cpus");
>
>         if (!cpus)
>                 return;
>
>
> Regards,
> Markus
>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 12:13                     ` Julia Lawall
@ 2025-09-06 12:30                       ` Markus Elfring
  2025-09-06 12:36                         ` Julia Lawall
  0 siblings, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06 12:30 UTC (permalink / raw)
  To: Julia Lawall, cocci

>>>> @find@
>>>> expression e;
>>>> position place;
>>>> type t;
>>>> t * pointer;
>>>> @@
>>>>  pointer = e(...);@place
>>>>
>>>> @display@
>>>> position find.place;
>>>> statement s;
>>>> type find.t;
>>>> t * find.pointer;
>>>> @@
>>>> *;@place
> 
> This line certainly doesn't work.  It is searching for an empty statement

I would like to interpret it in the way that there is an end of a known statement.


> at a place where there is an assignment statement.

The first SmPL rule determined that this can not be empty.
Is it possible to avoid duplicated SmPL code here?

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 12:30                       ` Markus Elfring
@ 2025-09-06 12:36                         ` Julia Lawall
  2025-09-06 12:47                           ` Markus Elfring
  0 siblings, 1 reply; 25+ messages in thread
From: Julia Lawall @ 2025-09-06 12:36 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci



On Sat, 6 Sep 2025, Markus Elfring wrote:

> >>>> @find@
> >>>> expression e;
> >>>> position place;
> >>>> type t;
> >>>> t * pointer;
> >>>> @@
> >>>>  pointer = e(...);@place
> >>>>
> >>>> @display@
> >>>> position find.place;
> >>>> statement s;
> >>>> type find.t;
> >>>> t * find.pointer;
> >>>> @@
> >>>> *;@place
> >
> > This line certainly doesn't work.  It is searching for an empty statement
>
> I would like to interpret it in the way that there is an end of a known statement.
>
>
> > at a place where there is an assignment statement.
>
> The first SmPL rule determined that this can not be empty.
> Is it possible to avoid duplicated SmPL code here?

You can put an expression metavariable e.  But you can't put nothing.

julia

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 12:36                         ` Julia Lawall
@ 2025-09-06 12:47                           ` Markus Elfring
  2025-09-06 12:51                             ` Julia Lawall
  0 siblings, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06 12:47 UTC (permalink / raw)
  To: Julia Lawall, cocci

>>>>>> *;@place
>>>
>>> This line certainly doesn't work.  It is searching for an empty statement
>>
>> I would like to interpret it in the way that there is an end of a known statement.
>>
>>
>>> at a place where there is an assignment statement.
>>
>> The first SmPL rule determined that this can not be empty.
>> Is it possible to avoid duplicated SmPL code here?
> 
> You can put an expression metavariable e.  But you can't put nothing.

Thanks for this information.

Can such a data processing constraint be reconsidered?

@find@
expression e;
position place;
type t;
t * pointer;
@@
 pointer = e(...);@place

@display@
expression x;
position find.place;
statement s;
type find.t;
t * find.pointer;
@@
*x;@place
 if (!pointer)
    s
 ... when != pointer


Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 12:47                           ` Markus Elfring
@ 2025-09-06 12:51                             ` Julia Lawall
  0 siblings, 0 replies; 25+ messages in thread
From: Julia Lawall @ 2025-09-06 12:51 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci



On Sat, 6 Sep 2025, Markus Elfring wrote:

> >>>>>> *;@place
> >>>
> >>> This line certainly doesn't work.  It is searching for an empty statement
> >>
> >> I would like to interpret it in the way that there is an end of a known statement.
> >>
> >>
> >>> at a place where there is an assignment statement.
> >>
> >> The first SmPL rule determined that this can not be empty.
> >> Is it possible to avoid duplicated SmPL code here?
> >
> > You can put an expression metavariable e.  But you can't put nothing.
>
> Thanks for this information.
>
> Can such a data processing constraint be reconsidered?

No.  Here as elsewhere Coccinelle works on complete things - complete
statement, complete expression, complete loop header.  It doesn't work on
random fragments of code that you may find convenient.  So a ; on a line
by itself is interpreted as a complete statement, hence and empty
statement.

julia

>
> @find@
> expression e;
> position place;
> type t;
> t * pointer;
> @@
>  pointer = e(...);@place
>
> @display@
> expression x;
> position find.place;
> statement s;
> type find.t;
> t * find.pointer;
> @@
> *x;@place
>  if (!pointer)
>     s
>  ... when != pointer
>
>
> Regards,
> Markus
>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06  8:07   ` Julia Lawall
  2025-09-06  8:10     ` Markus Elfring
@ 2025-09-06 13:20     ` Markus Elfring
  2025-09-08  6:15       ` Markus Elfring
  1 sibling, 1 reply; 25+ messages in thread
From: Markus Elfring @ 2025-09-06 13:20 UTC (permalink / raw)
  To: Julia Lawall, cocci

>> How can be achieved that the search for variable assignments will be repeated
>> after such a statement was found?
> There is no after.  Such variable assignments are matched throughout the
> entire function.

The awareness grew for another implementation detail somehow.
Thus I hope that the following SmPL script variant can help also to achieve
a better common understanding.

@find1@
expression e;
position place;
type t;
t * pointer;
@@
 pointer = e(...);@place

@display1@
expression x;
position find1.place;
statement s;
type find1.t;
t * find1.pointer;
@@
*x;@place
 if (!pointer)
    s
 ... when != pointer

@find2@
expression e, x;
position find1.place, place2;
type t;
t * pointer;
@@
 x;@place
 ... when != pointer
 pointer = e(...);@place2

@display2@
expression x;
position find2.place2;
statement s;
type find2.t;
t * find2.pointer;
@@
*x;@place2
 if (!pointer)
    s
 ... when != pointer


Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for selected variable assignments (with SmPL)?
  2025-09-06 13:20     ` Markus Elfring
@ 2025-09-08  6:15       ` Markus Elfring
  0 siblings, 0 replies; 25+ messages in thread
From: Markus Elfring @ 2025-09-08  6:15 UTC (permalink / raw)
  To: Julia Lawall, cocci

> Thus I hope that the following SmPL script variant can help also to achieve
> a better common understanding.
…

Would you like to support such source code search approaches by the means of
coccicheck scripts?

How many SmPL rules will become applicable?

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for missing cleanup function calls (with SmPL)?
  2025-09-04 12:43 ` Julia Lawall
  2025-09-04 12:58   ` Markus Elfring
@ 2025-09-12  9:29   ` Markus Elfring
  2025-09-12 11:07     ` Julia Lawall
  2025-09-12 13:43     ` Markus Elfring
  2025-09-12 15:43   ` Markus Elfring
  2 siblings, 2 replies; 25+ messages in thread
From: Markus Elfring @ 2025-09-12  9:29 UTC (permalink / raw)
  To: Julia Lawall, cocci

> But if there are cases where dn really should be freed, that could be
> something to write a patch for.

I would like to clarify possible software development consequences
also according to a diff output like the following.

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch …/Projekte/Coccinelle/janitor/show_missing_of_node_put.cocci arch/powerpc/sysdev/fsl_rio.c
…
@@ -511,7 +511,6 @@ static int fsl_rio_setup(struct platform
        }
 
        /*set up doobell node*/
-       np = of_find_compatible_node(NULL, NULL, "fsl,srio-dbell-unit");
        if (!np) {
                dev_err(&dev->dev, "No fsl,srio-dbell-unit node\n");
                rc = -ENODEV;
@@ -537,7 +536,6 @@ static int fsl_rio_setup(struct platform
                                (u32)range_start);
 
        /*set up port write node*/
-       np = of_find_compatible_node(NULL, NULL, "fsl,srio-port-write-unit");
        if (!np) {
                dev_err(&dev->dev, "No fsl,srio-port-write-unit node\n");
                rc = -ENODEV;

real    0m0,968s
user    0m0,547s
sys     0m0,059s


I would expect that the previously mentioned SmPL code “... when != dn”
should exclude some C source code.
How does the shown test result fit to this expectation on the behaviour
of the Coccinelle software (when there are obviously places where the found variable
is used again after a null pointer check)?


But it seems that the code is still improvable.
https://elixir.bootlin.com/linux/v6.17-rc5/source/arch/powerpc/sysdev/fsl_rio.c#L439-L731

I guess that of_node_put() should be called before the affected variable
is reassigned here.
https://elixir.bootlin.com/linux/v6.17-rc5/source/drivers/of/base.c#L1011-L1022

I would appreciate your advice.

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for missing cleanup function calls (with SmPL)?
  2025-09-12  9:29   ` Markus Elfring
@ 2025-09-12 11:07     ` Julia Lawall
  2025-09-12 12:30       ` Markus Elfring
  2025-09-12 13:43     ` Markus Elfring
  1 sibling, 1 reply; 25+ messages in thread
From: Julia Lawall @ 2025-09-12 11:07 UTC (permalink / raw)
  To: Markus Elfring; +Cc: cocci

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]



On Fri, 12 Sep 2025, Markus Elfring wrote:

> > But if there are cases where dn really should be freed, that could be
> > something to write a patch for.
>
> I would like to clarify possible software development consequences
> also according to a diff output like the following.
>
> Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch …/Projekte/Coccinelle/janitor/show_missing_of_node_put.cocci arch/powerpc/sysdev/fsl_rio.c
> …
> @@ -511,7 +511,6 @@ static int fsl_rio_setup(struct platform
>         }
>
>         /*set up doobell node*/
> -       np = of_find_compatible_node(NULL, NULL, "fsl,srio-dbell-unit");
>         if (!np) {
>                 dev_err(&dev->dev, "No fsl,srio-dbell-unit node\n");
>                 rc = -ENODEV;
> @@ -537,7 +536,6 @@ static int fsl_rio_setup(struct platform
>                                 (u32)range_start);
>
>         /*set up port write node*/
> -       np = of_find_compatible_node(NULL, NULL, "fsl,srio-port-write-unit");
>         if (!np) {
>                 dev_err(&dev->dev, "No fsl,srio-port-write-unit node\n");
>                 rc = -ENODEV;
>
> real    0m0,968s
> user    0m0,547s
> sys     0m0,059s
>
>
> I would expect that the previously mentioned SmPL code “... when != dn”
> should exclude some C source code.
> How does the shown test result fit to this expectation on the behaviour
> of the Coccinelle software (when there are obviously places where the found variable
> is used again after a null pointer check)?


Your semantic patch isn't included and it is not cenvenient for me to hunt
it down.  idn't you have ?dn = e; or something like at at the end?

julia

>
>
> But it seems that the code is still improvable.
> https://elixir.bootlin.com/linux/v6.17-rc5/source/arch/powerpc/sysdev/fsl_rio.c#L439-L731
>
> I guess that of_node_put() should be called before the affected variable
> is reassigned here.
> https://elixir.bootlin.com/linux/v6.17-rc5/source/drivers/of/base.c#L1011-L1022
>
> I would appreciate your advice.
>
> Regards,
> Markus
>

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for missing cleanup function calls (with SmPL)?
  2025-09-12 11:07     ` Julia Lawall
@ 2025-09-12 12:30       ` Markus Elfring
  0 siblings, 0 replies; 25+ messages in thread
From: Markus Elfring @ 2025-09-12 12:30 UTC (permalink / raw)
  To: Julia Lawall, cocci

>> How does the shown test result fit to this expectation on the behaviour
>> of the Coccinelle software (when there are obviously places where the found variable
>> is used again after a null pointer check)?
> 
> Your semantic patch isn't included and it is not cenvenient for me to hunt
> it down.

I hope that you can take another look at the applied SmPL script
also according to known information systems.
https://lore.kernel.org/cocci/6c2e0db1-033f-4f66-9cf7-dc0eae4bcde7@web.de/
https://sympa.inria.fr/sympa/arc/cocci/2025-09/msg00000.html


>           idn't you have ?dn = e; or something like at at the end?

To which data processing constraint do you try to refer here?

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for missing cleanup function calls (with SmPL)?
  2025-09-12  9:29   ` Markus Elfring
  2025-09-12 11:07     ` Julia Lawall
@ 2025-09-12 13:43     ` Markus Elfring
  1 sibling, 0 replies; 25+ messages in thread
From: Markus Elfring @ 2025-09-12 13:43 UTC (permalink / raw)
  To: Julia Lawall, cocci

> But it seems that the code is still improvable.
I recognised another improvement possibility.
Thus I hope that it can be achieved also with the help of
a corresponding SmPL script.

// See also:
// fsl_rio_setup()
// https://elixir.bootlin.com/linux/v6.17-rc5/source/arch/powerpc/sysdev/fsl_rio.c#L439-L731
@addition@
@@
 if (rio_register_mport(port))
 {
+release_iores:
    release_resource(&port->iores);
+free_priv:
    kfree(priv);
+free_port:
    kfree(port);
    continue;
 }

@adjustment@
@@
(
 release_iores:
    release_resource(...);
|
-release_resource(&port->iores);
-kfree(priv);
-kfree(port);
-continue
+goto release_iores
 ;
|
-kfree(priv);
-kfree(port);
-continue
+goto free_priv
 ;
|
-{
-kfree(port);
-continue
+goto free_port
 ;
-}
|
-kfree(port);
-continue
+goto free_port
 ;
)


Unfortunately, the following error information is presented.

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> /usr/bin/spatch …/Projekte/Coccinelle/janitor/avoid_duplicate_code_in_fsl_rio_setup.cocci arch/powerpc/sysdev/fsl_rio.c
…
SPECIAL NAMES: adding for_each_child_of_node as a iterator
     
previous modification:
MINUS
  >>> gotofree_port


According to environment 0:


current modification:
MINUS
  >>> gotofree_priv


According to environment 0:


exn while in timeout_function
adjustment: already tagged token:
C code context
File "/tmp/cocci_small_output-8646-5461f6-fsl_rio.c", line 213, column 4, charpos = 5621
  around = 'continue',
  whole content =                               continue;


I would appreciate your advice.

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [cocci] Searching for missing cleanup function calls (with SmPL)?
  2025-09-04 12:43 ` Julia Lawall
  2025-09-04 12:58   ` Markus Elfring
  2025-09-12  9:29   ` Markus Elfring
@ 2025-09-12 15:43   ` Markus Elfring
  2 siblings, 0 replies; 25+ messages in thread
From: Markus Elfring @ 2025-09-12 15:43 UTC (permalink / raw)
  To: Julia Lawall, cocci

> But if there are cases where dn really should be freed, that could be
> something to write a patch for.

SmPL script repetition for your convenience:
@display@
expression e;
statement s;
struct device_node * dn;
@@
*dn = e(...);
 if (!dn)
    s
 ... when != dn


I would like to clarify further software development consequences also according to
a diff output (like the following) for a smaller function implementation.

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time /usr/bin/spatch …/Projekte/Coccinelle/janitor/show_missing_of_node_put.cocci drivers/gpio/gpiolib-of.c
…
@@ -1252,7 +1252,6 @@ int of_gpiochip_add(struct gpio_chip *ch
        struct device_node *np;
        int ret;
 
-       np = dev_of_node(&chip->gpiodev->dev);
        if (!np)
                return 0;
 

real    0m0,491s
user    0m0,455s
sys     0m0,037s


I wonder once more why this source code place is presented
despite of the expectation that the shown SMPL code exclusion specification
should result into a corresponding effect because of the used statement “of_node_get(np);”.
https://elixir.bootlin.com/linux/v6.17-rc5/source/drivers/gpio/gpiolib-of.c#L1250-L1284

Will development ideas evolve according to another questionable test result?

Regards,
Markus

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2025-09-12 15:43 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-04 12:36 [cocci] Searching for missing cleanup function calls (with SmPL)? Markus Elfring
2025-09-04 12:43 ` Julia Lawall
2025-09-04 12:58   ` Markus Elfring
2025-09-12  9:29   ` Markus Elfring
2025-09-12 11:07     ` Julia Lawall
2025-09-12 12:30       ` Markus Elfring
2025-09-12 13:43     ` Markus Elfring
2025-09-12 15:43   ` Markus Elfring
2025-09-06  8:00 ` [cocci] Searching for selected variable assignments " Markus Elfring
2025-09-06  8:07   ` Julia Lawall
2025-09-06  8:10     ` Markus Elfring
2025-09-06  8:22       ` Julia Lawall
2025-09-06  9:11         ` Markus Elfring
2025-09-06  9:14           ` Julia Lawall
2025-09-06  9:28             ` Markus Elfring
2025-09-06 10:25               ` Markus Elfring
2025-09-06 11:12                 ` Julia Lawall
2025-09-06 12:07                   ` Markus Elfring
2025-09-06 12:13                     ` Julia Lawall
2025-09-06 12:30                       ` Markus Elfring
2025-09-06 12:36                         ` Julia Lawall
2025-09-06 12:47                           ` Markus Elfring
2025-09-06 12:51                             ` Julia Lawall
2025-09-06 13:20     ` Markus Elfring
2025-09-08  6:15       ` Markus Elfring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox