>> So I add a new floppy maintainer Denis Efremov to CC.
>
> Looks like it got lost indeed, I will just apply this one directly for
> 5.4.
>
Thank you!
Denis
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
On 24.08.2019 14:23, Julia Lawall wrote:
>
>
> On Sat, 24 Aug 2019, Denis Efremov wrote:
>
>> Hi,
>>
>> I'm trying to write a rule for turning !unlikely to likely and vice versa.
>> However, it's hard for me to understand what is wrong with the rule
This patch adds coccinelle script for detecting !likely and !unlikely
usage. It's better to use unlikely instead of !likely and vice versa.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/misc/unlikely.cocci | 70 ++
1 file changed, 70 insertions(+)
create mode
On 30.08.2019 03:42, Julia Lawall wrote:
>
>
> On Thu, 29 Aug 2019, Denis Efremov wrote:
>
>> On 8/29/19 8:10 PM, Denis Efremov wrote:
>>> This patch adds coccinelle script for detecting !likely and
>>> !unlikely usage. These notations are confusing.
On 01.09.2019 20:24, Pavel Machek wrote:
> Hi!
>
>>> This patch adds coccinelle script for detecting !likely and !unlikely
>>> usage. It's better to use unlikely instead of !likely and vice versa.
>>
>> Please explain _why_ is it better in the changelog.
>>
>> btw: there are relatively few
>
> As a human I am confused. Is !likely(x) equivalent to x or !x?
>
> Julia
>
As far as I could understand it:
# define likely(x) __builtin_expect(!!(x), 1)
!likely(x)
!__builtin_expect(!!(x), 1)
!((!!(x)) == 1)
(!!(x)) != 1, since !! could result in 0 or 1
(!!(x)) == 0
!(!!(x))
On 8/28/19 2:33 PM, Rasmus Villemoes wrote:
> On 25/08/2019 21.19, Julia Lawall wrote:
>>
>>
>>> On 26 Aug 2019, at 02:59, Denis Efremov wrote:
>>>
>>>
>>>
>>>> On 25.08.2019 19:37, Joe Perches wrote:
>>>>> On Sun, 20
On 8/28/19 3:41 PM, Denis Efremov wrote:
>
>>
>> As a human I am confused. Is !likely(x) equivalent to x or !x?
>>
>> Julia
>>
>
> As far as I could understand it:
>
> # define likely(x)__builtin_expect(!!(x), 1)
> !likely(x)
> !__builti
!__builtin_expect(!!(x), 1) iff
__builtin_expect(!!!(x), 0) iff
unlikely(!x)
For !unlikely(x) to likely(!x):
!unlikely(x) iff
!__builtin_expect(!!(x), 0) iff
__builtin_expect(!!!(x), 1) iff
likely(!x)
Signed-off-by: Denis Efremov
Cc: Julia Lawall
Cc: Gilles Muller
Cc: Nicolas Palix
On 8/29/19 8:10 PM, Denis Efremov wrote:
> This patch adds coccinelle script for detecting !likely and
> !unlikely usage. These notations are confusing. It's better
> to replace !likely(x) with unlikely(!x) and !unlikely(x) with
> likely(!x) for readability.
I'm not sure that this r
On 25.08.2019 19:37, Joe Perches wrote:
> On Sun, 2019-08-25 at 16:05 +0300, Denis Efremov wrote:
>> This patch adds coccinelle script for detecting !likely and !unlikely
>> usage. It's better to use unlikely instead of !likely and vice versa.
>
> Please expla
> I think it's incorrect to say so in general. For example, on x86/64:
>
> $ make mrproper
> $ make allyesconfig
> $ make && mv vmlinux vmlinux-000
> $ make coccicheck MODE=patch COCCI=scripts/coccinelle/misc/unlikely.cocci |
> patch -p1
> $ make
> $ ./scripts/bloat-o-meter ./vmlinux-000
On 25.08.2019 18:30, Markus Elfring wrote:
>> +(
>> +* !likely(E)
>> +|
>> +* !unlikely(E)
>> +)
>
> Can the following code variant be nicer?
>
> +*! \( likely \| unlikely \) (E)
>
>
>> +(
>> +-!likely(E)
>> ++unlikely(E)
>> +|
>> +-!unlikely(E)
>> ++likely(E)
>> +)
>
> I would find the
Hi,
I'm trying to write a rule for turning !unlikely to likely and vice versa.
However, it's hard for me to understand what is wrong with the rule and how to
make it work. Any suggestions? Do I need to introduce 'expression E;' instead
'(...)'? BTW, spatch hangs with -Dorg.
The rule:
virtual
/bsearch.c)
or to apply defensive programming for midpoint calculation.
[1] https://en.wikipedia.org/wiki/Binary_search_algorithm#Implementation_issues
[2] https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
Signed-off-by: Denis Efremov
---
scripts/coccinelle/misc
Hi,
On 06.09.2019 23:19, Julia Lawall wrote:
>
>
> On Thu, 29 Aug 2019, Denis Efremov wrote:
>
>> This patch adds coccinelle script for detecting !likely and
>> !unlikely usage. These notations are confusing. It's better
>> to replace !likely(x) wit
On 05.09.2019 09:20, Julia Lawall wrote:
>
>
> On Thu, 5 Sep 2019, Denis Efremov wrote:
>
>> This is an RFC. I will resend the patch after feedback. Currently
>> I'm preparing big patchset with bsearch warnings fixed. The rule will
>> be a part of this patchset
itialized_var().
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Signed-off-by: Denis Efremov
---
Changes in v2:
- Documentation cited in the script's description
- kernel.org link added to the diagnostics messages
- "T *var = " pattern removed
- "var =@p var", "var =@p *(
On 9/1/20 5:37 PM, Joe Perches wrote:
> On Tue, 2020-09-01 at 12:48 +0300, Denis Efremov wrote:
>> uninitialized_var() macro was removed from the sources [1] and
>> other warning-silencing tricks were deprecated [2]. The purpose of this
>> cocci script is to pr
Extend the list of free functions with kvfree(), kvfree_sensitive(),
vfree().
Signed-off-by: Denis Efremov
---
scripts/coccinelle/free/ifnullfree.cocci | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/scripts/coccinelle/free/ifnullfree.cocci
b/scripts/coccinelle
")
[2] commit 4b19bec97c88 ("docs: deprecated.rst: Add uninitialized_var()")
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Signed-off-by: Denis Efremov
---
Changes in v2:
- Documentation cited in the script's description
- kernel.org link added to the diagnostics messages
- "T
Exclude kobj_to_dev() definition from warnings.
Signed-off-by: Denis Efremov
---
No changes in performance. This patch can be squashed to the
original patch with kobj_to_dev.cocci script.
scripts/coccinelle/api/kobj_to_dev.cocci | 13 +++--
1 file changed, 11 insertions(+), 2 deletions
On 9/2/20 3:32 PM, Julia Lawall wrote:
> There is an isomorphism that you can disable: ptr_to_array
Thanks!
Anyway, even with ptr_to_array enabled equalizing cmd->dmap[0] and
cmd->dmap[1] looks incorrect to me.
Denis
___
Cocci mailing list
Hi,
I'm trying to write a pattern to match expression without side-effects,
i.e expression E but not i++, --i, function call.
While trying to write it I faced that this expression matches different
array indices. Actually, it's quite unexpected for me:
@@
expression E;
identifier A;
@@
* E->A
Check for "!A || A && B" condition. It's equivalent to
"!A || B" condition.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/misc/excluded_middle.cocci | 40 +++
1 file changed, 40 insertions(+)
create mode 100644 scripts/coccinelle/misc/exclu
occi
> +++ b/scripts/coccinelle/free/kfree_sensitive.cocci
> @@ -1,13 +1,13 @@
> // SPDX-License-Identifier: GPL-2.0-only
> ///
> -/// Use kzfree, kvfree_sensitive rather than memset or
> -/// memzero_explicit followed by kfree
> +/// Use k{,v}free_sensitive rather than me
Hi,
On 9/12/20 5:43 PM, Julia Lawall wrote:
>
>
> On Mon, 10 Aug 2020, Denis Efremov wrote:
>
>> Commit 68e4cd17e218 ("docs: deprecated.rst: Add zero-length and one-element
>> arrays") marks one-element and zero-length arrays as deprecated. Kernel
>>
Print memset() call position in addition to the kfree() position to
ease issues identification.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/kfree_sensitive.cocci | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/scripts/coccinelle/api
On 10/2/20 5:13 PM, Julia Lawall wrote:
>
>
> On Fri, 2 Oct 2020, Denis Efremov wrote:
>
>> Hi,
>>
>> On 10/2/20 5:01 PM, Julia Lawall wrote:
>>> Denis,
>>>
>>> In the rule proposing kzfree_sensitive, I think it would be helpful to
&
Hi,
On 10/2/20 5:01 PM, Julia Lawall wrote:
> Denis,
>
> In the rule proposing kzfree_sensitive, I think it would be helpful to
> also highlight the memset line.
What do you mean? It's "highlighted" in context mode. Do you mean adding
position argument to memset call and showing this position
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?
On 8/11/20 10:49 AM, Denis Efremov wrote:
> Commit 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()")
> renames kzfree to kfree_sensitive and uses memzero_explicit(...) instead of
> memset(..., 0, ...) internally. Update cocci script to reflect these
>
A. R. Silva
Cc: Kees Cook
Signed-off-by: Denis Efremov
---
Kees, Gustavo, may I have your acks if you find this script useful?
Currently, it emits following warnings:
./fs/select.c:994:25-26: WARNING opportunity for flex_array_size
./include/linux/avf/virtchnl.h:711:34-35: WARNING opportunity
On 8/29/20 10:48 PM, Julia Lawall wrote:
>
>
> On Sat, 29 Aug 2020, Joe Perches wrote:
>
>> On Sat, 2020-08-29 at 21:36 +0200, Julia Lawall wrote:
>>>
>>> On Wed, 12 Aug 2020, Denis Efremov wrote:
>>>
>>>> Commit 63a0895d960a (&quo
Use kobj_to_dev() instead of container_of().
Signed-off-by: Denis Efremov
---
Examples of such patches:
893c3d82b425 watchdog: Use kobj_to_dev() API
23fd63a44460 hwmon: (nct6683) Replace container_of() with kobj_to_dev()
224941c9424f power: supply: use kobj_to_dev
a9b9b2af40c7 backlight
Use kobj_to_dev() instead of container_of().
Signed-off-by: Denis Efremov
---
Changes in v2:
- "symbol kobj;" added to the rule r
scripts/coccinelle/api/kobj_to_dev.cocci | 45
1 file changed, 45 insertions(+)
create mode 100644 scripts/cocc
>
> I tried:
> @@
> identifier f_show =~ "^.*_show$";
This will miss this kind of functions:
./drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1953:static
DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
./drivers/gpu/drm/amd/amdgpu/df_v3_6.c:266:static
Hi all,
On 8/27/20 10:42 PM, Julia Lawall wrote:
>
>
> On Thu, 27 Aug 2020, Joe Perches wrote:
>
>> On Thu, 2020-08-27 at 15:48 +0100, Alex Dewar wrote:
>>> On Thu, Aug 27, 2020 at 03:41:06PM +0200, Rasmus Villemoes wrote:
On 27/08/2020 15.18, Alex Dewar wrote:
> On Thu, Aug 27, 2020
Hi,
On 8/3/20 9:34 PM, Denis Efremov wrote:
> Check that alloc and free types of functions match each other.
Julia, I've just send the patches to fix all the warnings emitted by the script.
[1] https://lore.kernel.org/patchwork/patch/1309731/
[2] https://lore.kernel.org/patchwork/patch/1309
Add zero-length and
one-element arrays")
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Signed-off-by: Denis Efremov
---
Changes in v2:
- all uapi headers are now filtered-out. Unfortunately, coccinelle
doesn't provide structure names in Location.current_element.
For structures the field is al
Check for !A || A && B condition. It's equivalent to !A || B.
Signed-off-by: Denis Efremov
---
Changes in v2:
- spelling mistake fixed
- position variable moved on the && operator
- patch pattern changed to - (A && B)
- word "condition" removed from warning
Suggest kvmalloc, kvfree instead of opencoded patterns.
Signed-off-by: Denis Efremov
---
Changes in v2:
- binary operator cmp added
- NULL comparisions simplified
- "T x" case added to !patch mode
Changes in v3:
- kvfree rules added
Changes in v4:
- pattern updated to match only
Add vmemdup_user() transformations to the memdup_user.cocci rule.
Commit 50fd2f298bef ("new primitive: vmemdup_user()") introduced
vmemdup_user(). The function uses kvmalloc with GPF_USER flag.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/memdup_user.
emdup_user() to GFP_USER is here:
https://lkml.org/lkml/2018/1/6/333
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/memdup_user.cocci | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/coccinelle/api/memdup_user.cocci
b/scripts/coccinelle/api/memdup_user.c
Add GFP_USER to the allocation flags and handle vmemdup_user().
Denis Efremov (2):
Coccinelle: extend memdup_user transformation with GFP_USER
Coccinelle: extend memdup_user rule with vmemdup_user()
scripts/coccinelle/api/memdup_user.cocci | 53 ++--
1 file changed, 49
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
Suggest kvmalloc instead of opencoded kmalloc && vmalloc condition.
Signed-off-by: Denis Efremov
---
If coccinelle fails with "Segmentation fault" during analysis, then
one needs to increase stack limit, e.g. ulimit -s 32767.
Current, I've sent only one patch for this
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
___
Cocci mailing list
Cocci@systeme.lip6.fr
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
Suggest kvmalloc instead of opencoded kmalloc && vmalloc condition.
Signed-off-by: Denis Efremov
---
Changes in v2:
- binary operator cmp added
- NULL comparisions simplified
- "T x" case added to !patch mode
scripts/coccinelle/api/kvmalloc.cocci | 142
Suggest kvmalloc, kvfree instead of opencoded patterns.
Signed-off-by: Denis Efremov
---
Changes in v2:
- binary operator cmp added
- NULL comparisions simplified
- "T x" case added to !patch mode
Changes in v3:
- kvfree rules added
scripts/coccinelle/api/kvmalloc.c
.
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Signed-off-by: Denis Efremov
---
Currently, it's just a draft. I've placed a number of questions in the
script and marked them as TODO. Kees, Gustavo, if you could help me with
my questions I think that this rule will be enough to close:
https://github.com/
itialized_var().
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Signed-off-by: Denis Efremov
---
List of warnings:
./lib/glob.c:48:31-39: WARNING: this kind of initialization is deprecated
./tools/testing/selftests/vm/userfaultfd.c:349:15-22: WARNING: this kind of
initialization is deprecated
./drivers/b
.
Cc: Kees Cook
Cc: Gustavo A. R. Silva
Signed-off-by: Denis Efremov
---
Changes in v2:
- all uapi headers are now filtered-out. Unfortunately, coccinelle
doesn't provide structure names in Location.current_element.
For structures the field is always "something_else". Thus, the
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
Hi,
This pattern:
- E = kzalloc(size, flags | __GFP_NOWARN);
- if (\(!E\|E == null\))@p
- E = vzalloc(size);
+ E = kvzalloc(size, flags);
matches this code:
void *p;
p = kzalloc(size, gfp | __GFP_NOWARN);
if (!p)
p = vzalloc(size);
But not this:
void *p = kzalloc(size, gfp |
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
It's safe to use sprintf() for simple cases in device_attr_show
type of functions. Add support for sprintf() in patch mode to
the device_attr_show.cocci script to print numbers and pointers.
Signed-off-by: Denis Efremov
---
Interesting enough that with this patch coccinelle starts to skip
patch
On 8/11/20 2:45 AM, Eric Biggers wrote:
> On Fri, Jul 17, 2020 at 10:39:20PM +0200, Julia Lawall wrote:
>>
>>
>> On Fri, 17 Jul 2020, Denis Efremov wrote:
>>
>>> Check for memset()/memzero_explicit() followed by kfree()/vfree()/kvfree().
>>>
&g
Commit 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()")
renames kzfree to kfree_sensitive and uses memzero_explicit(...) instead of
memset(..., 0, ...) internally. Update cocci script to reflect these
changes.
Signed-off-by: Denis Efremov
---
Julia, I think you
On 6/15/20 9:23 PM, Kees Cook wrote:
> On Mon, Jun 15, 2020 at 01:20:45PM +0300, Denis Efremov wrote:
>> Detect an opencoded expression that is used before or after
>> array_size()/array3_size()/struct_size() to compute the same size.
>>
>> Cc: Kees Cook
>
>
>
> Awesome! I'll take a look into this. :)
>
It would be helpful to get a feedback from you after.
What kind of warnings are helpful and what are not?
"duplicate calls" and "opencoded expression after array_size()" look doubtful
to me.
I think that maintainers will not like these patches.
to check for overflow
/// relatively small allocations.
///
// Confidence: Low
// Copyright: (C) 2020 Denis Efremov ISPRAS
// Options: --no-includes --include-headers
virtual patch
virtual context
virtual org
virtual report
@depends on patch@
expression E1, E2, E3, E4, size;
@@
(
- size = E1 * E
Hi,
On 6/18/20 2:34 PM, Markus Elfring wrote:
> Why did you repeat a typo from the previous patch subject?
Where is the typo? I can't handle your suggestions because your mails constantly
break the threads. I just can't find them after due to missed/wrong In-Reply-To
headers. Again, this mail
Detect an opencoded expression that is used before or after
array_size()/array3_size()/struct_size() to compute the same size.
Cc: Gustavo A. R. Silva
Cc: Kees Cook
Signed-off-by: Denis Efremov
---
Changes in v2:
- python rules moved next to SmPL patterns
- assignment operator used
On 6/17/20 11:30 PM, Julia Lawall wrote:
>
>
> On Mon, 15 Jun 2020, Denis Efremov wrote:
>
>> Detect an opencoded expression that is used before or after
>> array_size()/array3_size()/struct_size() to compute the same size.
>
> This would benefit from the ass
>> +@rp_memset depends on patch@
>> +expression E, size;
>> +position p : script:python() { relevant(p) };
>> +type T;
>> +@@
>> +
>> +- memset((T)E, size)@p;
>
> This is missing a 0 argument.
>
Thanks, I will send v4.
>
>
>> + ... when != E
>> + when strict
>> +(
>> +- kfree(E);
>>
On 6/17/20 11:27 PM, Julia Lawall wrote:
>
>
> On Mon, 15 Jun 2020, Denis Efremov wrote:
>
>> According to the documentation[1] show() methods of device attributes
>> should return the number of bytes printed into the buffer. This is
>> the return value of sc
Detect an opencoded expression that is used before or after
array_size()/array3_size()/struct_size() to compute the same size.
Signed-off-by: Denis Efremov
---
Changes in v2:
- python rules moved next to SmPL patterns
- assignment operator used
- struct_size patterns fixed to check only E3
There is a typo in rule r2. Position p1 should be attached to kzalloc()
call.
Fixes: 29a36d4dec6c ("scripts/coccinelle: improve the coverage of some semantic
patches")
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/kstrdup.cocci | 2 +-
1 file changed, 1 insertion(+),
Detect an opencoded expression that is used before or after
array_size()/array3_size()/struct_size() to compute the same size.
Cc: Gustavo A. R. Silva
Cc: Kees Cook
Signed-off-by: Denis Efremov
---
Changes in v2:
- python rules moved next to SmPL patterns
- assignment operator used
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
Detect an opencoded expression that is used before or after
array_size()/array3_size()/struct_size() to compute the same size.
Cc: Kees Cook
Signed-off-by: Denis Efremov
---
scripts/coccinelle/misc/array_size_dup.cocci | 347 +++
1 file changed, 347 insertions(+)
create mode
rintf() confusion" https://lwn.net/Articles/69419/
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/device_attr_show.cocci | 55 +++
1 file changed, 55 insertions(+)
create mode 100644 scripts/coccinelle/api/device_attr_show.cocci
diff --git a/scripts/cocc
On 6/15/20 3:03 PM, Dan Carpenter wrote:
> On Sun, Jun 14, 2020 at 10:42:54PM +0300, Denis Efremov wrote:
>> On 6/4/20 7:27 PM, Joe Perches wrote:
>>> On Thu, 2020-06-04 at 17:08 +0300, Denis Efremov wrote:
>>>> Check for memset() with 0 followed by kfree().
>
On 6/21/20 11:56 PM, Julia Lawall wrote:
> Is it a python 2 vs python 3 thing?
Yes, python2 is no longer supported and I
thought it would be safe to use this syntax.
Ok, I will make it portable in v4.
Denis
___
Cocci mailing list
What do you think about removing duplicates warning from the rule?
I mean this kind of warnings: "WARNING: same array_size (line {p1[0].line})"
As for now, I think it's better to not disturb developers with this kind
of things.
Thanks,
Denis
>> +@as_dup@
>> +expression subE1 <= as.E1;
>>
>> @r depends on !patch@
>> // It doesn't work. Is it normal?
>> //position p: script:python() { matches.extend(p); relevant(p) };
>
> "Doesn't work" means you get a parse error? The parser of the code inside
> the {} is pretty fragile. Perhaps this could be improved somewhat, but it
> is
I've got a couple of questions about python interface.
Let us suppose that I want to suppress a couple of matches because they are
false-positives.
However, I still want to check they exists in finalize block and print a
warning otherwise.
This is some kind of self-check for a rule.
For
Check for memset() with 0 followed by kfree().
Signed-off-by: Denis Efremov
---
Patches:
1. kzfree in drivers/w1 https://lkml.org/lkml/2020/6/4/438
2. kzfree in drivers/iommu/ https://lkml.org/lkml/2020/6/4/421
3. kzfree in drivers/scsi/ https://lkml.org/lkml/2020/6/4/442
scripts/coccinelle
> Could you send an example of some C code on which the result is not
> suitable?
I've updated the pattern to handle false positives:
@ifok@
position p;
expression *E;
@@
(
if (...) {
...
memset(E, 0, ...)@p;
...
}
|
if (...) {
...
} else {
...
memset(E, 0,
On 6/4/20 5:15 PM, Julia Lawall wrote:
> Did you try ... here but find that some subexpressions of E could be
> modified in between?
Yes, I tried to use "... when != E = E1 when != " and results were bad.
Now, I've tried forall and when strict. Here are examples:
// forall added
// Works
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
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:
- https
On 6/6/20 11:24 AM, Julia Lawall wrote:
>
>
> On Sat, 30 May 2020, Denis Efremov wrote:
>
>> Match GFP_USER allocations with memdup_user.cocci rule.
>> Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched
>> memdup_user() from GFP_KERNE
On 6/6/20 11:24 AM, Julia Lawall wrote:
>
>
> On Sat, 30 May 2020, Denis Efremov wrote:
>
>> Match GFP_USER allocations with memdup_user.cocci rule.
>> Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched
>> memdup_user() from GFP_KERNE
llocations. The motivation behind altering memdup_user() to GFP_USER:
https://lkml.org/lkml/2018/1/6/333
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/memdup_user.cocci | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/coccinelle/api/memdup_user.cocci
Add vmemdup_user() transformations to the memdup_user.cocci rule.
Commit 50fd2f298bef ("new primitive: vmemdup_user()") introduced
vmemdup_user(). The function uses kvmalloc with GPF_USER flag.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/memdup_user.
Don't match original implementations.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/memdup_user.cocci | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/scripts/coccinelle/api/memdup_user.cocci
b/scripts/coccinelle/api/memdup_user.cocci
index
for in the kernel sources changed.
Denis Efremov (4):
coccinelle: api: extend memdup_user transformation with GFP_USER
coccinelle: api: extend memdup_user rule with vmemdup_user()
coccinelle: api: filter out memdup_user definitions
coccinelle: api: add selfcheck for memdup_user rule
scripts
Check that the rule matches vmemdup_user implementation.
memdup_user is out of scope because we are not matching
kmalloc_track_caller() function.
Signed-off-by: Denis Efremov
---
scripts/coccinelle/api/memdup_user.cocci | 46 ++--
1 file changed, 44 insertions(+), 2
> Is this self-check functionality planned for a patch in the Linux kernel,
> or for some oher use? Because the python script that I suggested for
> collecting the names of all of the files will imply parsing all of those
> files, which will have a major negative impact on performance.
Yes,
Hi,
I'm trying to write a rule to match consecutive function calls. For example:
@r@
expression E, E1;
@@
call_func(E);
... when != E = E1
* call_func(E);
It works well, but not in case "E == p->f" and p is updated in between calls.
So, I'm to understand how can I avoid these kind of
On 6/3/20 10:45 PM, Julia Lawall wrote:
> subE is a expressionof whatever expression was previously matched to E in
> the rule ifm. <= can only be used when the metavariable on the right side
> is inherited from another rule. Ths is probably what you want for your
> problem.
In this case I
On 6/4/20 11:57 PM, Julia Lawall wrote:
> On the other hand, do you really require E to be a pointer? If you do
> that, it will have to find the type of E. If E refers to a structure
> field, then the type might not be available in the current function, and
> you may need command line argments
Check for memset()/memset_explicit() with 0 followed by
kfree()/vfree()/kvfree().
Signed-off-by: Denis Efremov
---
Changes in v2:
- memset_explicit() added
- kvfree_sensitive() added
- forall added to r1
- ... between memset and kfree added
Unfortunately, it doesn't work as I would expect
It looks like a good idea to add type cast, like:
+// Ignore kzfree definition
+// Ignore kasan test
+@r depends on !patch && !(file in "lib/test_kasan.c") && !(file in
"mm/slab_common.c") forall@
+expression *E;
+position p;
+type T;
+@@
+
+* \(memset\|memset_explicit\)((T)E, 0, ...);
+ ...
On 6/4/20 7:27 PM, Joe Perches wrote:
> On Thu, 2020-06-04 at 17:08 +0300, Denis Efremov wrote:
>> Check for memset() with 0 followed by kfree().
>
> Perhaps those uses should be memzero_explicit or kvfree_sensitive.
Thanks, I will add memzero_explicit(). Howeve
On 6/9/20 7:22 PM, Julia Lawall wrote:
>
>
> On Mon, 8 Jun 2020, Denis Efremov wrote:
>
>> Check that the rule matches vmemdup_user implementation.
>> memdup_user is out of scope because we are not matching
>> kmalloc_track_caller() function.
>
> Is th
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 =
1 - 100 of 146 matches
Mail list logo
