Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-11 Thread Markus Elfring
>> @display@
>> expression x;
>> identifier f;
>
> You can put f != {likely,unlikely} here.

Now I have got a related impression. It seems that such a search pattern 
extension
affects also our unfinished clarification for the desired handling of
when constraints by SmPL ellipses.
How will this open issue evolve further?

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-11 Thread Markus Elfring
>> @display@
>> expression x;
>> identifier f;
>
> You can put f != {likely,unlikely} here.

I would appreciate to achieve a better understanding how these likeliness
annotations can influence the shown source code search approach.


> Maybe there will be some false positives when x->f is in a condition
> that previously checked that x is not NULL.

Such information can become more interesting.


> Does this happen a lot?

My view is incomplete.


> If the answer to either question is no, does the problem really matter?
> If it does really matter,

I hope that the probability for false positives (because of evolving
source code searches) can be considerably reduced.


> then it is possible to solve it, by adding a previous rule that
> marks such safe dereferences with a position variable.  But I don't know
> whether it is worth it.

I am curious how corresponding software development efforts will evolve.

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-11 Thread Markus Elfring
>> The possibility remains that also your search pattern suggestion will point
>> update candidates out at other places than the implementation of the 
>> mentioned
>> function “imx_pd_bind”.
>
> So many words.  So little information.

This can also occasionally happen if the search approach is simpler
than it would be required for specific source code places.

The discussion context should be resolvable together with previous messages.

Repetition:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/imx/parallel-display.c?id=43b815c6a8e7dbccb5b8bd9c4b099c24bc22d135#n197
https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/gpu/drm/imx/parallel-display.c#L197


> What is the name of the file and the line number at which you get a result
> that you find inacceptable with my rule?

Another example:
Now I wonder about a patch hunk like the following which is generated
from the discussed search pattern suggestion.

@display@
expression x;
identifier f;
@@
* x = kmemdup(...);
  ... when != x
(
  x->f
|
  f(...,<+...x...+>,...)
)


elfring@Sonne:~/Projekte/Linux/next-patched> spatch 
~/Projekte/Coccinelle/janitor/show_unchecked_kmemdup3.cocci 
net/sunrpc/auth_gss/auth_gss.c
…
@@ -146,7 +146,6 @@ simple_get_netobj(const void *p, const v
q = (const void *)((const char *)p + len);
if (unlikely(q > end || q < p))
return ERR_PTR(-EFAULT);
-   dest->data = kmemdup(p, len, GFP_NOFS);
if (unlikely(dest->data == NULL))
return ERR_PTR(-ENOMEM);
dest->len = len;


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/sunrpc/auth_gss/auth_gss.c?id=9e208aa06c2109b45eec6be049a8e47034748c20#n149
https://elixir.bootlin.com/linux/v5.4-rc2/source/net/sunrpc/auth_gss/auth_gss.c#L149


Will the corresponding clarification help software developers (besides me)?

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-11 Thread Julia Lawall


On Fri, 11 Oct 2019, Markus Elfring wrote:

> > And what is the questionable source code place?
>
> I find implementation details occasionally questionable where checks for 
> variables
> which provide a stored function return value are missing.
> The possibility remains that also your search pattern suggestion will point
> update candidates out at other places than the implementation of the mentioned
> function “imx_pd_bind”.

Blah, blah, blah.  So many words.  So little information.

What is the name of the file and the line number at which you get a result
that you find inacceptable with my rule?

If you can't answer that simple question, I'm not going to discuss this
further.

julia

>
> How do you think about the following SmPL script variant?
>
> @display@
> expression x, y;
> identifier f, md;
> @@
> *(x)->md = kmemdup(...);
>  ... when != (x)->md
> (((x)->md)->f
> |f(..., <+... x ...+>, ...)
> |(y = x)
> )
>
>
> Regards,
> Markus
>___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-10 Thread Markus Elfring
> And what is the questionable source code place?

I find implementation details occasionally questionable where checks for 
variables
which provide a stored function return value are missing.
The possibility remains that also your search pattern suggestion will point
update candidates out at other places than the implementation of the mentioned
function “imx_pd_bind”.

How do you think about the following SmPL script variant?

@display@
expression x, y;
identifier f, md;
@@
*(x)->md = kmemdup(...);
 ... when != (x)->md
(((x)->md)->f
|f(..., <+... x ...+>, ...)
|(y = x)
)


Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-10 Thread Markus Elfring
>> I would like to detect that a corresponding null pointer check would be 
>> missing
>> (before the data can be used for further data processing).
>
> * x = kmemdup(...);
>   ... when != x
> (
>   x->f
> |
>   f(...,<+...x...+>,...)
> )

This analysis approach looks promising in principle. I needed another moment
to become aware that it indicates pointer usage requirements
which can occasionally not be met (like in the mentioned function 
“imx_pd_bind”).
If the expression “x” would be split into accesses to data structure members,
the data processing can probably result in another desirable information 
display.

The pointer usages vary in affected function implementations (as usual).

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-10 Thread Markus Elfring
 I would like to detect that a corresponding null pointer check would be 
 missing
 (before the data can be used for further data processing).
>>>
>>> * x = kmemdup(...);
>>>   ... when != x
>>> (
>>>   x->f
>>> |
>>>   f(...,<+...x...+>,...)
>>> )
>>
>> This SmPL search approach does not work as expected for
>> the mentioned source file “drivers/gpu/drm/imx/parallel-display.c”.
>
> I have better things to do than to run your tests.  If you have a problem,
> say what the problem is an show the code that shows a problem.

A questionable source code place is just not pointed out
by this analysis approach.
No error message is displayed on my test system.

So I would appreciate to find a better solution together.

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-10 Thread Markus Elfring
>> I would like to detect that a corresponding null pointer check would be 
>> missing
>> (before the data can be used for further data processing).
>
> * x = kmemdup(...);
>   ... when != x
> (
>   x->f
> |
>   f(...,<+...x...+>,...)
> )

This SmPL search approach does not work as expected for
the mentioned source file “drivers/gpu/drm/imx/parallel-display.c”.

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-10 Thread Julia Lawall



On Thu, 10 Oct 2019, Markus Elfring wrote:

> > Why not just
> >
> > x = kmemdup(...);
> > ... when != x
>
> I find this SmPL code exclusion specification too generic for the use case.
> I would like to detect that a corresponding null pointer check would be 
> missing
> (before the data can be used for further data processing).

* x = kmemdup(...);
  ... when != x
(
  x->f
|
  f(...,<+...x...+>,...)
)

If this gives a parse error, put ... when any at the very end.

julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-10 Thread Markus Elfring
> Why not just
>
> x = kmemdup(...);
> ... when != x

I find this SmPL code exclusion specification too generic for the use case.
I would like to detect that a corresponding null pointer check would be missing
(before the data can be used for further data processing).

Regards,
Markus
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci


Re: [Cocci] Software analysis with SmPL around unchecked function calls

2019-10-10 Thread Julia Lawall


On Thu, 10 Oct 2019, Markus Elfring wrote:

> Hello,
>
> I would like to try another source code analysis approach out with
> the software combination “Coccinelle 1.0.8-4-g842075f7”.
>
> @display@
> expression x;
> statement is, es;
> @@
> (
> *x = kmemdup(...);
> |if (...)
> *x = kmemdup(...);
> )
> (if (!x) is
> |if (...) is else es
> |
>  ... when any
>  when != x
> )


It's not clear what you want to match.  The above rule matches all kmemdup
calls that are followed by the the indicated code.  Do you want the
following?

Why not just

x = kmemdup(...);
... when != x

julia

>
>
> This SmPL small script can point an update candidate out like
> the function “imx_pd_bind” as expected.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/imx/parallel-display.c?id=43b815c6a8e7dbccb5b8bd9c4b099c24bc22d135#n197
> https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/gpu/drm/imx/parallel-display.c#L197
>
> Unfortunately, I find also some false positives then at other places.
>
> Example:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpufreq/sfi-cpufreq.c?id=8a8c600de5dc1d9a7f4b83269fddc80ebd3dd045#n23
> https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/cpufreq/sfi-cpufreq.c#L23
>
> …
> @@ -37,7 +37,6 @@ static int sfi_parse_freq(struct sfi_tab
>   pentry = (struct sfi_freq_table_entry *)sb->pentry;
>   totallen = num_freq_table_entries * sizeof(*pentry);
>
> - sfi_cpufreq_array = kmemdup(pentry, totallen, GFP_KERNEL);
>   if (!sfi_cpufreq_array)
>   return -ENOMEM;
> …
>
>
> Would you like to clarify this situation for the semantic patch language?
>
> Regards,
> Markus
> ___
> Cocci mailing list
> Cocci@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci