Re: [Cocci] Software analysis with SmPL around unchecked function calls
>> @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
>> @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
>> 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
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
> 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
>> 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
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
>> 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
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
> 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
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
[Cocci] Software analysis with SmPL around unchecked function calls
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 ) 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
