On Mon, 3 Aug 2020, Denis Efremov wrote:
>
>
> On 8/2/20 11:24 PM, Julia Lawall wrote:
> >> +@initialize:python@
> >> +@@
> >> +# low-level memory api
> >> +filter = frozenset(['__vmalloc_area_node'])
> >> +
> >> +def relevant(p):
> >> +return not (filter & {el.current_element for el in
On Mon, 3 Aug 2020, Denis Efremov wrote:
> Is there a difference from cocci point of view between:
>
> ... when != !is_vmalloc_addr(E)
This will only reject cases where the ! is present. Coccinelle doesn't
apply isomorphisms to the C source code, so it doesn't detect that eg
if (A)
B
else
Is there a difference from cocci point of view between:
... when != !is_vmalloc_addr(E)
and
... when != is_vmalloc_addr(E)
Should the latter one be used in most cases?
Thanks,
Denis
On 8/2/20 11:24 PM, Julia Lawall wrote:
>> +@initialize:python@
>> +@@
>> +# low-level memory api
>> +filter = frozenset(['__vmalloc_area_node'])
>> +
>> +def relevant(p):
>> +return not (filter & {el.current_element for el in p})
>
> Is this used?
I'll remove it in v8. Or do you want me
> +@initialize:python@
> +@@
> +# low-level memory api
> +filter = frozenset(['__vmalloc_area_node'])
> +
> +def relevant(p):
> +return not (filter & {el.current_element for el in p})
Is this used?
Otherwise, I think it would be good to not warn about a use of kvfree
if that use is reachable
On Sun, 2 Aug 2020, Markus Elfring wrote:
> …
> > +++ b/scripts/coccinelle/api/kvfree.cocci
> …
> > +@choice@
> > +expression E, E1;
> > +position kok, vok;
> > +@@
> > +
> > +(
> …
> > +|
> > + E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\|kmalloc_node\|kzalloc_node\|
> > +
Check that alloc and free types of functions match each other.
Signed-off-by: Denis Efremov
---
Changes in v2:
- Lines are limited to 80 characters where possible
- Confidence changed from High to Medium because of
fs/btrfs/send.c:1119 false-positive
- __vmalloc_area_node() explicitly
On Fri, 31 Jul 2020, Markus Elfring wrote:
> > +msg = "WARNING: kmalloc is used to allocate this memory at line %s" %
> > (k[0].line)
> > +coccilib.org.print_todo(p[0], msg)
>
> * I find the diagnostic text insufficient.
> >>>
> >>> I also find the message not very
Check that alloc and free types of functions match each other.
Signed-off-by: Denis Efremov
---
Changes in v2:
- Lines are limited to 80 characters where possible
- Confidence changed from High to Medium because of
fs/btrfs/send.c:1119 false-positive
- __vmalloc_area_node() explicitly
> >
> > Do the checks for the opportunities for kvmalloc really belong in this
> > rule? That issue is not mentioned in the commit log or the description of
> > the semantic patch.
>
> I added this at the last moment. It was easy enough to add it based on
> existing
> patterns. I will add
On Fri, 31 Jul 2020, Markus Elfring wrote:
> >>> +msg = "WARNING: kmalloc is used to allocate this memory at line %s" %
> >>> (k[0].line)
> >>> +coccilib.org.print_todo(p[0], msg)
> >>
> >> * I find the diagnostic text insufficient.
> >
> > I also find the message not very informative.
>
> Is
> With the current patch mode, I got some changes in a recent linux-next.
> Have you sent patches for these issues?
For mellanox, I've sent these patches:
https://lkml.org/lkml/2020/6/5/901
https://lkml.org/lkml/2020/6/1/713
They were accepted.
I see two new places in mellanox driver in
On Thu, 30 Jul 2020, Denis Efremov wrote:
> Check that alloc and free types of functions match each other.
Do the checks for the opportunities for kvmalloc really belong in this
rule? That issue is not mentioned in the commit log or the description of
the semantic patch.
With the current
Actually, the message looks fine. Sorry for the noise about that.
However there is a problem in the kfree case:
> +@kfree depends on !patch@
> +expression E;
> +position v != choice.vok;
> +position p;
> +@@
> +
> +* E =
>
> > +msg = "WARNING: kmalloc is used to allocate this memory at line %s" %
> > (k[0].line)
> > +coccilib.org.print_todo(p[0], msg)
>
> * I find the diagnostic text insufficient.
I also find the message not very informative.
All of the other comments are not useful, and some are simply
Check that alloc and free types of functions match each other.
Signed-off-by: Denis Efremov
---
Changes in v2:
- Lines are limited to 80 characters where possible
- Confidence changed from High to Medium because of
fs/btrfs/send.c:1119 false-positive
- __vmalloc_area_node() explicitly
> +
> +@script: python depends on org@
> +v << kfree.v;
> +p << kfree.p;
> +@@
> +
> +msg = "WARNING: vmalloc is used to allocate this memory at line %s" %
> (v[0].line)
> +coccilib.org.print_todo(p[0],
Just noticed this error. I will resend the patch in 5mins.
Regards,
Denis
Check that alloc and free types of functions match each other.
Signed-off-by: Denis Efremov
---
Changes in v2:
- Lines are limited to 80 characters where possible
- Confidence changed from High to Medium because of
fs/btrfs/send.c:1119 false-positive
- __vmalloc_area_node() explicitly
Ping?
Check that alloc and free types of functions match each other.
Signed-off-by: Denis Efremov
---
Changes in v2:
- Lines are limited to 80 characters where possible
- Confidence changed from High to Medium because of
fs/btrfs/send.c:1119 false-positive
- __vmalloc_area_node() explicitly
> … Looks like it's impossible to break "when" lines.
Thus I became also curious on clarification for further software
development possibilities around the safer application of code exclusion
specifications by the means of the semantic patch language.
Regards,
Markus
On 6/14/20 12:17 PM, Julia Lawall wrote:
>
>
> On Sun, 14 Jun 2020, Denis Efremov wrote:
>
>>
>>
>> On 6/5/20 11:51 PM, Julia Lawall wrote:
>>> Also, there is no need to exceed 80 characters here. You can put a
>>> newline in the middle of a \( ... \)
>>
>> It's required. Looks like it's
On Sun, 14 Jun 2020, Denis Efremov wrote:
>
>
> On 6/5/20 11:51 PM, Julia Lawall wrote:
> > Also, there is no need to exceed 80 characters here. You can put a
> > newline in the middle of a \( ... \)
>
> It's required. Looks like it's impossible to break "when" lines.
That's true. Sorry for
On 6/5/20 11:51 PM, Julia Lawall wrote:
> Also, there is no need to exceed 80 characters here. You can put a
> newline in the middle of a \( ... \)
It's required. Looks like it's impossible to break "when" lines.
... when != if (...) { ... E =
>> * A limited search approach was expressed. Will additional source code
>> variations
>> become relevant?
>> + switch statement
>> + if branches with single statements
>> + conditional operator
>
> The point is that there is a kmalloc in one branch and a vmalloc in
> another branch, so
On Sat, 6 Jun 2020, Markus Elfring wrote:
> > +@choice@
> > +expression E, E1;
> > +position kok, vok;
> > +@@
> > +
> > +(
> > + if (...) {
> > +...
> > +E = \(kmalloc@kok\|…\)(...)
>
> Further implementation details from this SmPL script caught my software
> development attention.
>
> +@choice@
> +expression E, E1;
> +position kok, vok;
> +@@
> +
> +(
> + if (...) {
> +...
> +E = \(kmalloc@kok\|…\)(...)
Further implementation details from this SmPL script caught my software
development attention.
* Is there a need to add the specification “when any” to the SmPL
> So there are a lot of reasons why constraints are useful.
Thanks for such a view.
Thus I dare to point the possibility out to consider their application
for mentioned function name lists (besides using SmPL disjunctions).
Can coding style concerns be resolved in a more constructive way then?
On Sat, 6 Jun 2020, Markus Elfring wrote:
> >>> +E =
> >>> \(kmalloc@kok\|kzalloc@kok\|krealloc@kok\|kcalloc@kok\|kmalloc_node@kok\|kzalloc_node@kok\|kmalloc_array@kok\|kmalloc_array_node@kok\|kcalloc_node@kok\)(...)
> >>
> >> I would prefer an other coding style here.
> >>
> >> * Items
>>> +E =
>>> \(kmalloc@kok\|kzalloc@kok\|krealloc@kok\|kcalloc@kok\|kmalloc_node@kok\|kzalloc_node@kok\|kmalloc_array@kok\|kmalloc_array_node@kok\|kcalloc_node@kok\)(...)
>>
>> I would prefer an other coding style here.
>>
>> * Items for such SmPL disjunctions can be specified also on
>>> +E =
>>> \(kmalloc@kok\|kzalloc@kok\|krealloc@kok\|kcalloc@kok\|kmalloc_node@kok\|kzalloc_node@kok\|kmalloc_array@kok\|kmalloc_array_node@kok\|kcalloc_node@kok\)(...)
>>
>> I would prefer an other coding style here.
>>
>> * Items for such SmPL disjunctions can be specified also on
> > +E =
> > \(kmalloc@kok\|kzalloc@kok\|krealloc@kok\|kcalloc@kok\|kmalloc_node@kok\|kzalloc_node@kok\|kmalloc_array@kok\|kmalloc_array_node@kok\|kcalloc_node@kok\)(...)
>
> I would prefer an other coding style here.
>
> * Items for such SmPL disjunctions can be specified also on multiple
> Check that alloc and free types of functions match each other.
Further software development challenges are interesting also for such an use
case.
> +/// Check that kvmalloc'ed memory is freed by kfree functions,
> +/// vmalloc'ed by vfree functions and kvmalloc'ed by kvfree
> +/// functions.
On Sat, 6 Jun 2020, Denis Efremov wrote:
> On 6/5/20 11:51 PM, Julia Lawall wrote:
> > Is there a strong reason for putting the choice rule first? It may make
> > things somewhat slower than necessary, if it matches in many places,
> > because the opportunity rule will have to detect that it
On 6/5/20 11:51 PM, Julia Lawall wrote:
> Is there a strong reason for putting the choice rule first? It may make
> things somewhat slower than necessary, if it matches in many places,
> because the opportunity rule will have to detect that it doesn't care
> about all of those places.
No, I
On Fri, 5 Jun 2020, Denis Efremov wrote:
> Check that alloc and free types of functions match each other.
Is there a strong reason for putting the choice rule first? It may make
things somewhat slower than necessary, if it matches in many places,
because the opportunity rule will have to
Check that alloc and free types of functions match each other.
Signed-off-by: Denis Efremov
---
List of patches to stable:
- https://lkml.org/lkml/2020/6/1/713
- https://lkml.org/lkml/2020/6/5/200
- https://lkml.org/lkml/2020/6/5/838
- https://lkml.org/lkml/2020/6/5/887
Other patches:
-
37 matches
Mail list logo
