[cocci] __free() attribute inhibits matching?

[cocci] __free() attribute inhibits matching?

[Kees Cook]

Hi!

It seems that the mere presence of the "__free" attribute breaks
matching:

$ cat test.c
static void why(void)
{
        u64 *rates_64 __free(kfree) = NULL;
        rates_64 = kcalloc(count, sizeof(*rates_64), GFP_KERNEL);
}

$ cat match.cocci
@replace@
expression THING, COUNT;
expression GFP;
@@

-       kcalloc(COUNT, sizeof(*THING), GFP)
+       kzalloc_objs(*THING, COUNT, GFP)


$ spatch --very-quiet --cocci-file match.cocci test.c


Which doesn't match. If I comment out the "__free()" it works:

$ cat test.c
static void why(void)
{
        u64 *rates_64 /*__free(kfree)*/ = NULL;
        rates_64 = kcalloc(count, sizeof(*rates_64), GFP_KERNEL);
}

$ spatch --very-quiet --cocci-file match.cocci test.c
--- test.c
+++ cocci-output-1466652-b8a5c5-test.c
@@ -1,5 +1,5 @@
 static void why(void)
 {
        u64 *rates_64 /*__free(kfree)*/ = NULL;
-       rates_64 = kcalloc(count, sizeof(*rates_64), GFP_KERNEL);
+       rates_64 = kzalloc_objs(*rates_64, count, GFP_KERNEL);
 }


I have tried adding "attribute name __free;" to the rule (which didn't
seem sane, but also didn't work). I have tried adding this line to my
standard.h:
#define __free(x) MACROANNOTATION
but that didn't work either.

What is going wrong here?

Thanks!

-Kees

-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Julia Lawall]

Sent from my iPhone

> On 17 Mar 2025, at 19:44, Kees Cook <kees@kernel.org> wrote:
> 
> Hi!
> 
> It seems that the mere presence of the "__free" attribute breaks
> matching:
> 
> $ cat test.c
> static void why(void)
> {
>        u64 *rates_64 __free(kfree) = NULL;
>        rates_64 = kcalloc(count, sizeof(*rates_64), GFP_KERNEL);
> }
> 
> $ cat match.cocci
> @replace@
> expression THING, COUNT;
> expression GFP;
> @@
> 
> -       kcalloc(COUNT, sizeof(*THING), GFP)
> +       kzalloc_objs(*THING, COUNT, GFP)
> 
> 
> $ spatch --very-quiet --cocci-file match.cocci test.c
> 
> 
> Which doesn't match. If I comment out the "__free()" it works:
> 
> $ cat test.c
> static void why(void)
> {
>        u64 *rates_64 /*__free(kfree)*/ = NULL;
>        rates_64 = kcalloc(count, sizeof(*rates_64), GFP_KERNEL);
> }
> 
> $ spatch --very-quiet --cocci-file match.cocci test.c
> --- test.c
> +++ cocci-output-1466652-b8a5c5-test.c
> @@ -1,5 +1,5 @@
> static void why(void)
> {
>        u64 *rates_64 /*__free(kfree)*/ = NULL;
> -       rates_64 = kcalloc(count, sizeof(*rates_64), GFP_KERNEL);
> +       rates_64 = kzalloc_objs(*rates_64, count, GFP_KERNEL);
> }
> 
> 
> I have tried adding "attribute name __free;" to the rule (which didn't
> seem sane, but also didn't work). I have tried adding this line to my
> standard.h:
> #define __free(x) MACROANNOTATION

Try the above with an empty definition.

> but that didn't work either.
> 
> What is going wrong here?
> 
> Thanks!
> 
> -Kees
> 
> --
> Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Kees Cook]

On Mon, Mar 17, 2025 at 09:59:55PM +0100, Julia Lawall wrote:
> > On 17 Mar 2025, at 19:44, Kees Cook <kees@kernel.org> wrote:
> > seem sane, but also didn't work). I have tried adding this line to my
> > standard.h:
> > #define __free(x) MACROANNOTATION
> 
> Try the above with an empty definition.

As in just:

#define __free(x)

?

Ah! Yes, that worked! Thank you!

-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Julia Lawall]

It makes the call just disappear.
Sent from my iPhone

> On 18 Mar 2025, at 00:02, Kees Cook <kees@kernel.org> wrote:
> 
> On Mon, Mar 17, 2025 at 09:59:55PM +0100, Julia Lawall wrote:
>>>> On 17 Mar 2025, at 19:44, Kees Cook <kees@kernel.org> wrote:
>>> seem sane, but also didn't work). I have tried adding this line to my
>>> standard.h:
>>> #define __free(x) MACROANNOTATION
>> 
>> Try the above with an empty definition.
> 
> As in just:
> 
> #define __free(x)
> 
> ?
> 
> Ah! Yes, that worked! Thank you!
> 
> --
> Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Kees Cook]

On Tue, Mar 18, 2025 at 12:13:15AM +0100, Julia Lawall wrote:
> It makes the call just disappear.

Right, unfortunately this breaks replacement, because the __free
vanishes completely even in the replacement:

-       struct platform_profile_handler *pprof __free(kfree) = kzalloc(
-               sizeof(*pprof), GFP_KERNEL);
+       struct platform_profile_handler *pprof = kzalloc_obj(*pprof, GFP_KERNEL);

How do we get __free to be treated like any other variable attribute?

-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Julia Lawall]

Sent from my iPhone

> On 18 Mar 2025, at 16:39, Kees Cook <kees@kernel.org> wrote:
> 
> On Tue, Mar 18, 2025 at 12:13:15AM +0100, Julia Lawall wrote:
>> It makes the call just disappear.
> 
> Right, unfortunately this breaks replacement, because the __free
> vanishes completely even in the replacement:
> 
> -       struct platform_profile_handler *pprof __free(kfree) = kzalloc(
> -               sizeof(*pprof), GFP_KERNEL);
> +       struct platform_profile_handler *pprof = kzalloc_obj(*pprof, GFP_KERNEL);
> 
> How do we get __free to be treated like any other variable attribute?
> 

It would certainly be good to suppôt it better. But I have the impression that you are removing and recreating the whole part to the left of the equal? It could work better to remove and recreate only the kzalloc call.

> --
> Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Kees Cook]

On Tue, Mar 18, 2025 at 04:43:30PM +0100, Julia Lawall wrote:
> > On 18 Mar 2025, at 16:39, Kees Cook <kees@kernel.org> wrote:
> > 
> > On Tue, Mar 18, 2025 at 12:13:15AM +0100, Julia Lawall wrote:
> >> It makes the call just disappear.
> > 
> > Right, unfortunately this breaks replacement, because the __free
> > vanishes completely even in the replacement:
> > 
> > -       struct platform_profile_handler *pprof __free(kfree) = kzalloc(
> > -               sizeof(*pprof), GFP_KERNEL);
> > +       struct platform_profile_handler *pprof = kzalloc_obj(*pprof, GFP_KERNEL);
> > 
> > How do we get __free to be treated like any other variable attribute?
> > 
> 
> It would certainly be good to suppôt it better. But I have the impression that you are removing and recreating the whole part to the left of the equal? It could work better to remove and recreate only the kzalloc call.

Oh! Yes, thank you. That works. :)

Okay, next question. Based on your advise on constructing matches for
arbitrarily long dereferences[1], I am trying to apply the same logic,
but to also tie identifiers to types:

@direct depends on !(file in "tools") && !(file in "samples")@
type TYPE;
TYPE *P;
TYPE *MEMBER;
TYPE INST;
expression COMP;
identifier ALLOC =~ "^kv?[mz]alloc";
fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
@@

        \(\(P\|COMP.MEMBER\|COMP->MEMBER\) \& VAR\)
-       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
+       = ALLOC_OBJ(*VAR, GFP);

This won't parse:

minus: parse error: 
  File "scripts/coccinelle/api/kmalloc_objs.cocci", line 58, column 13, charpos = 1303
  around = 'MEMBER',
  whole content =       \(\(P\|COMP.MEMBER\|COMP->MEMBER\) \& VAR\)


If I change MEMBER to:

identifier MEMBER;

it parses, but then I lose the association of "MEMBER" being a "TYPE"
pointer. Is there some why to make that work?

Thanks!

-Kees

[1] https://lore.kernel.org/cocci/alpine.DEB.2.22.394.2006182155260.2367@hadrien/

-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Julia Lawall]

I think you want

Expression *m;

A->@m b

B would be an identifier

Sent from my iPhone

> On 18 Mar 2025, at 17:31, Kees Cook <kees@kernel.org> wrote:
> 
> On Tue, Mar 18, 2025 at 04:43:30PM +0100, Julia Lawall wrote:
>>>> On 18 Mar 2025, at 16:39, Kees Cook <kees@kernel.org> wrote:
>>> 
>>> On Tue, Mar 18, 2025 at 12:13:15AM +0100, Julia Lawall wrote:
>>>> It makes the call just disappear.
>>> 
>>> Right, unfortunately this breaks replacement, because the __free
>>> vanishes completely even in the replacement:
>>> 
>>> -       struct platform_profile_handler *pprof __free(kfree) = kzalloc(
>>> -               sizeof(*pprof), GFP_KERNEL);
>>> +       struct platform_profile_handler *pprof = kzalloc_obj(*pprof, GFP_KERNEL);
>>> 
>>> How do we get __free to be treated like any other variable attribute?
>>> 
>> 
>> It would certainly be good to suppôt it better. But I have the impression that you are removing and recreating the whole part to the left of the equal? It could work better to remove and recreate only the kzalloc call.
> 
> Oh! Yes, thank you. That works. :)
> 
> Okay, next question. Based on your advise on constructing matches for
> arbitrarily long dereferences[1], I am trying to apply the same logic,
> but to also tie identifiers to types:
> 
> @direct depends on !(file in "tools") && !(file in "samples")@
> type TYPE;
> TYPE *P;
> TYPE *MEMBER;
> TYPE INST;
> expression COMP;
> identifier ALLOC =~ "^kv?[mz]alloc";
> fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
> @@
> 
>        \(\(P\|COMP.MEMBER\|COMP->MEMBER\) \& VAR\)
> -       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
> +       = ALLOC_OBJ(*VAR, GFP);
> 
> This won't parse:
> 
> minus: parse error:
>  File "scripts/coccinelle/api/kmalloc_objs.cocci", line 58, column 13, charpos = 1303
>  around = 'MEMBER',
>  whole content =       \(\(P\|COMP.MEMBER\|COMP->MEMBER\) \& VAR\)
> 
> 
> If I change MEMBER to:
> 
> identifier MEMBER;
> 
> it parses, but then I lose the association of "MEMBER" being a "TYPE"
> pointer. Is there some why to make that work?
> 
> Thanks!
> 
> -Kees
> 
> [1] https://lore.kernel.org/cocci/alpine.DEB.2.22.394.2006182155260.2367@hadrien/
> 
> --
> Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Kees Cook]

On Tue, Mar 18, 2025 at 06:56:40PM +0100, Julia Lawall wrote:
> I think you want
> 
> Expression *m;
> 
> A->@m b
> 
> B would be an identifier

But how does "B" get correctly type restricted? (Or in my example,
"NAME"?)

I tried:

@direct depends on !(file in "tools") && !(file in "samples")@
type TYPE;
TYPE *P;
TYPE *MEMBER;
TYPE INST;
identifier NAME;
expression COMP;
identifier ALLOC =~ "^kv?[mz]alloc";
fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
@@

       \(\(P\|COMP.@MEMBER NAME\|COMP->@MEMBER NAME\) \& VAR\)
-       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
+       = ALLOC_OBJ(*VAR, GFP);

This parses, but don't match (from crypto/asymmetric_keys/x509_cert_parser.c):

	cert->pub = kzalloc(sizeof(struct public_key), GFP_KERNEL);

But does match (via "P"):

	cert = kzalloc(sizeof(struct x509_certificate), GFP_KERNEL);

/me continues to scratch head


-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Julia Lawall]

If it doesn’t match then it doesn’t find the type information?
Sent from my iPhone

> On 19 Mar 2025, at 04:31, Kees Cook <kees@kernel.org> wrote:
> 
> On Tue, Mar 18, 2025 at 06:56:40PM +0100, Julia Lawall wrote:
>> I think you want
>> 
>> Expression *m;
>> 
>> A->@m b
>> 
>> B would be an identifier
> 
> But how does "B" get correctly type restricted? (Or in my example,
> "NAME"?)
> 
> I tried:
> 
> @direct depends on !(file in "tools") && !(file in "samples")@
> type TYPE;
> TYPE *P;
> TYPE *MEMBER;
> TYPE INST;
> identifier NAME;
> expression COMP;
> identifier ALLOC =~ "^kv?[mz]alloc";
> fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
> @@
> 
>       \(\(P\|COMP.@MEMBER NAME\|COMP->@MEMBER NAME\) \& VAR\)
> -       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
> +       = ALLOC_OBJ(*VAR, GFP);
> 
> This parses, but don't match (from crypto/asymmetric_keys/x509_cert_parser.c):
> 
>    cert->pub = kzalloc(sizeof(struct public_key), GFP_KERNEL);
> 
> But does match (via "P"):
> 
>    cert = kzalloc(sizeof(struct x509_certificate), GFP_KERNEL);
> 
> /me continues to scratch head
> 
> 
> --
> Kees Cook

Re: [cocci] Checking the determination of type information?

[Markus Elfring]

> If it doesn’t match then it doesn’t find the type information?
Can desirable software behaviour be clarified in more constructive ways
(even after reported open issues according to parsing of C source code)?

Regards,
Markus

Re: [cocci] __free() attribute inhibits matching?

[Julia Lawall]

On Tue, 18 Mar 2025, Kees Cook wrote:

> On Tue, Mar 18, 2025 at 06:56:40PM +0100, Julia Lawall wrote:
> > I think you want
> >
> > Expression *m;
> >
> > A->@m b
> >
> > B would be an identifier
>
> But how does "B" get correctly type restricted? (Or in my example,
> "NAME"?)
>
> I tried:
>
> @direct depends on !(file in "tools") && !(file in "samples")@
> type TYPE;
> TYPE *P;
> TYPE *MEMBER;
> TYPE INST;
> identifier NAME;
> expression COMP;
> identifier ALLOC =~ "^kv?[mz]alloc";
> fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
> @@
>
>        \(\(P\|COMP.@MEMBER NAME\|COMP->@MEMBER NAME\) \& VAR\)
> -       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
> +       = ALLOC_OBJ(*VAR, GFP);
>
> This parses, but don't match (from crypto/asymmetric_keys/x509_cert_parser.c):
>
> 	cert->pub = kzalloc(sizeof(struct public_key), GFP_KERNEL);
>
> But does match (via "P"):
>
> 	cert = kzalloc(sizeof(struct x509_certificate), GFP_KERNEL);

What is the command line, eg --all-includes?  You can try
--verbose-includes to see what is happening with #include "x509_parser.h"

julia

>
> /me continues to scratch head
>
>
> --
> Kees Cook
>

Re: [cocci] __free() attribute inhibits matching?

[Kees Cook]

On Wed, Mar 19, 2025 at 08:44:38AM +0100, Julia Lawall wrote:
> What is the command line, eg --all-includes?  You can try
> --verbose-includes to see what is happening with #include "x509_parser.h"

Argh, there was a --no-includes hiding in my wrapper script! Okay, this
is much better now. I will continue working through missed matches.

Thank you thank you! :)

-Kees

-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Kees Cook]

On Wed, Mar 19, 2025 at 08:44:38AM +0100, Julia Lawall wrote:
> On Tue, 18 Mar 2025, Kees Cook wrote:
> > On Tue, Mar 18, 2025 at 06:56:40PM +0100, Julia Lawall wrote:
> > > I think you want
> > >
> > > Expression *m;
> > >
> > > A->@m b
> > >
> > > B would be an identifier
> >
> > But how does "B" get correctly type restricted? (Or in my example,
> > "NAME"?)
> >
> > I tried:
> >
> > @direct depends on !(file in "tools") && !(file in "samples")@
> > type TYPE;
> > TYPE *P;
> > TYPE *MEMBER;
> > TYPE INST;
> > identifier NAME;
> > expression COMP;
> > identifier ALLOC =~ "^kv?[mz]alloc";
> > fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
> > @@
> >
> >        \(\(P\|COMP.@MEMBER NAME\|COMP->@MEMBER NAME\) \& VAR\)
> > -       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
> > +       = ALLOC_OBJ(*VAR, GFP);
> >
> > This parses, but don't match (from crypto/asymmetric_keys/x509_cert_parser.c):
> >
> > 	cert->pub = kzalloc(sizeof(struct public_key), GFP_KERNEL);
> >
> > But does match (via "P"):
> >
> > 	cert = kzalloc(sizeof(struct x509_certificate), GFP_KERNEL);
> 
> What is the command line, eg --all-includes?  You can try
> --verbose-includes to see what is happening with #include "x509_parser.h"

Okay, my hiccups continue.

I do not seem to be able to mix a "type" metavariable with anything else.
For example, instead of these rules repeated:

@direct depends on patch@
type TYPE;
TYPE INST;
identifier PTR;
expression GFP;
expression TYPED;
identifier ALLOC =~ "^kv?[mz]alloc$";
fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
@@

(
        TYPE *PTR
-       = ALLOC((sizeof(*PTR)), GFP);
+       = ALLOC_OBJ(*PTR, GFP);
|
        TYPE *PTR
-       = ALLOC((sizeof(INST)), GFP);
+       = ALLOC_OBJ(INST, GFP);
|
        TYPE *PTR
-       = ALLOC((sizeof(TYPE)), GFP);
+       = ALLOC_OBJ(TYPE, GFP);
)

I wanted to write it as:

        TYPE *PTR
-       = ALLOC((sizeof(\(\(*PTR\|INST\|TYPE\) \& TYPED\))), GFP);
+       = ALLOC_OBJ(TYPED, GFP);

But this doesn't let me even put "TYPE" in the \( \) at all, much less
put it into the TYPED expression:

minus: parse error: 
  File "scripts/coccinelle/api/kmalloc_objs.cocci", line 55, column 34, charpos = 1235
  around = 'TYPE',
  whole content = -     = ALLOC((sizeof(\(\(*PTR\|INST\|TYPE\) \& TYPED\))), GFP);

How do I collapse these three into 1 rule?

-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Julia Lawall]

On Wed, 19 Mar 2025, Kees Cook wrote:

> On Wed, Mar 19, 2025 at 08:44:38AM +0100, Julia Lawall wrote:
> > On Tue, 18 Mar 2025, Kees Cook wrote:
> > > On Tue, Mar 18, 2025 at 06:56:40PM +0100, Julia Lawall wrote:
> > > > I think you want
> > > >
> > > > Expression *m;
> > > >
> > > > A->@m b
> > > >
> > > > B would be an identifier
> > >
> > > But how does "B" get correctly type restricted? (Or in my example,
> > > "NAME"?)
> > >
> > > I tried:
> > >
> > > @direct depends on !(file in "tools") && !(file in "samples")@
> > > type TYPE;
> > > TYPE *P;
> > > TYPE *MEMBER;
> > > TYPE INST;
> > > identifier NAME;
> > > expression COMP;
> > > identifier ALLOC =~ "^kv?[mz]alloc";
> > > fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
> > > @@
> > >
> > >        \(\(P\|COMP.@MEMBER NAME\|COMP->@MEMBER NAME\) \& VAR\)
> > > -       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
> > > +       = ALLOC_OBJ(*VAR, GFP);
> > >
> > > This parses, but don't match (from crypto/asymmetric_keys/x509_cert_parser.c):
> > >
> > > 	cert->pub = kzalloc(sizeof(struct public_key), GFP_KERNEL);
> > >
> > > But does match (via "P"):
> > >
> > > 	cert = kzalloc(sizeof(struct x509_certificate), GFP_KERNEL);
> >
> > What is the command line, eg --all-includes?  You can try
> > --verbose-includes to see what is happening with #include "x509_parser.h"
>
> Okay, my hiccups continue.
>
> I do not seem to be able to mix a "type" metavariable with anything else.
> For example, instead of these rules repeated:
>
> @direct depends on patch@
> type TYPE;
> TYPE INST;
> identifier PTR;
> expression GFP;
> expression TYPED;
> identifier ALLOC =~ "^kv?[mz]alloc$";
> fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
> @@
>
> (
>         TYPE *PTR
> -       = ALLOC((sizeof(*PTR)), GFP);
> +       = ALLOC_OBJ(*PTR, GFP);
> |
>         TYPE *PTR
> -       = ALLOC((sizeof(INST)), GFP);
> +       = ALLOC_OBJ(INST, GFP);
> |
>         TYPE *PTR
> -       = ALLOC((sizeof(TYPE)), GFP);
> +       = ALLOC_OBJ(TYPE, GFP);
> )
>
> I wanted to write it as:
>
>         TYPE *PTR
> -       = ALLOC((sizeof(\(\(*PTR\|INST\|TYPE\) \& TYPED\))), GFP);
> +       = ALLOC_OBJ(TYPED, GFP);
>
> But this doesn't let me even put "TYPE" in the \( \) at all, much less
> put it into the TYPED expression:
>
> minus: parse error:
>   File "scripts/coccinelle/api/kmalloc_objs.cocci", line 55, column 34, charpos = 1235
>   around = 'TYPE',
>   whole content = -     = ALLOC((sizeof(\(\(*PTR\|INST\|TYPE\) \& TYPED\))), GFP);
>
> How do I collapse these three into 1 rule?

A disjunction has to have the same kind of thing in every branch.  INST is
an expression but TYPE is a type, so that doesn't work.  sizeof is
misleading.  There are actually two different sizeof's, one where the
argument is an expression and one where the argument is a type.  One
requires () around the argument while the other does not.

You can just make a () with three copies of sizeof, or even two copies of
sizeof, on for TYPE and one for a disjunction of the other possibilities.

julia

Re: [cocci] __free() attribute inhibits matching?

[Markus Elfring]

> minus: parse error:
>   File "scripts/coccinelle/api/kmalloc_objs.cocci", line 55, column 34, charpos = 1235
>   around = 'TYPE',
>   whole content = -     = ALLOC((sizeof(\(\(*PTR\|INST\|TYPE\) \& TYPED\))), GFP);
>
> How do I collapse these three into 1 rule?

It seems that some software development constraints hinder to apply SmPL code
in more succinct ways so far.

Regards,
Markus

Re: [cocci] __free() attribute inhibits matching?

[Markus Elfring]

> I tried:
>
> @direct depends on !(file in "tools") && !(file in "samples")@
> type TYPE;
> TYPE *P;
> TYPE *MEMBER;
> TYPE INST;
> identifier NAME;
> expression COMP;
> identifier ALLOC =~ "^kv?[mz]alloc";
> fresh identifier ALLOC_OBJ = ALLOC ## "_obj";
> @@
>
>        \(\(P\|COMP.@MEMBER NAME\|COMP->@MEMBER NAME\) \& VAR\)
> -       = ALLOC((\(sizeof(*VAR)\|sizeof(TYPE)\|sizeof(INST)\)), GFP);
> +       = ALLOC_OBJ(*VAR, GFP);

Which metavariable variant may be relevant for “VAR”?


> This parses, but don't match (from crypto/asymmetric_keys/x509_cert_parser.c):
>
> 	cert->pub = kzalloc(sizeof(struct public_key), GFP_KERNEL);
>
> But does match (via "P"):
>
> 	cert = kzalloc(sizeof(struct x509_certificate), GFP_KERNEL);
>
> /me continues to scratch head
I am curious how the clarification will be continued also for source code analyses
with the implementation of the function “x509_cert_parse”.
https://elixir.bootlin.com/linux/v6.14-rc6/source/crypto/asymmetric_keys/x509_cert_parser.c#L59-L77

Regards,
Markus

Re: [cocci] __free() attribute inhibits matching?

[Markus Elfring]

> This parses, but don't match (from crypto/asymmetric_keys/x509_cert_parser.c):

Will further information (like the following) trigger any software adjustments?

Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> time spatch --parse-c crypto/asymmetric_keys/x509_cert_parser.c
…
(ONCE) CPP-MACRO: found string-macro fmt
including crypto/asymmetric_keys/x509_parser.h
(ONCE) CPP-MACRO: found toplevel macro noptvirg: DEFINE_FREE
(ONCE) CPP-MACRO: found higher order macro : DEFINE_FREE
TYPEDEF:_handle_typedef=false. Not normal if don't come from exn
(ONCE) CPP-TYPEDEF: promoting:(4) x509_free_certificate on line 63
(ONCE) CPP-TYPEDEF: promoting:(4) kfree on line 64
TYPEDEF CONFLICT:kfree
TODO:typedef now used as an identifier
TYPEDEF CONFLICT:x509_free_certificate
transforming some ident into a typedef
crypto/asymmetric_keys/x509_cert_parser.c:63: passed:cert
crypto/asymmetric_keys/x509_cert_parser.c:64: passed:ctx
-----------------------------------------------------------------------
NB total files = 1; perfect = 1; pbs = 0; timeout = 0; =========> 100%
nb good = 809,  nb passed = 2 =========> 0.25% passed
nb good = 809,  nb bad = 0 =========> 100.00% good or passed

real    0m0,071s
user    0m0,054s
sys     0m0,014s


Regards,
Markus

Re: [cocci] __free() attribute inhibits matching?

[Markus Elfring]

> It seems that the mere presence of the "__free" attribute breaks matching:
>
> $ cat test.c
> static void why(void)
> {
>         u64 *rates_64 __free(kfree) = NULL;
>         rates_64 = kcalloc(count, sizeof(*rates_64), GFP_KERNEL);
> }


Questionable test result (with the software combination “Coccinelle 1.3-00083-g4093aad2d”):
Markus_Elfring@Sonne:…/Projekte/Coccinelle/Probe> spatch --parse-c example_by_Kees_Cook-20250317.c
…
BAD:!!!!!         u64 *rates_64 __free(kfree) = NULL;
…
maybe 10 most problematic tokens
…
NB total files = 1; perfect = 0; pbs = 1; timeout = 0; =========> 0%
nb good = 0,  nb passed = 1 =========> 12.50% passed
nb good = 0,  nb bad = 7 =========> 12.50% good or passed



> $ cat match.cocci
> @replace@
> expression THING, COUNT;
> expression GFP;
> @@
>
> -       kcalloc(COUNT, sizeof(*THING), GFP)
> +       kzalloc_objs(*THING, COUNT, GFP)

Would another SmPL code variant be occasionally helpful?

@replacement@
expression THING, COUNT, GFP;
@@
-kcalloc
+kzalloc_objs
 (
-COUNT,
-sizeof(
        *THING
-      )
+, COUNT
 , GFP
 )


Regards,
Markus

Re: [cocci] __free() attribute inhibits matching?

[Kees Cook]

On Tue, Mar 18, 2025 at 06:43:33PM +0100, Markus Elfring wrote:
> Would another SmPL code variant be occasionally helpful?
> 
> @replacement@
> expression THING, COUNT, GFP;
> @@
> -kcalloc
> +kzalloc_objs
>  (
> -COUNT,
> -sizeof(
>         *THING
> -      )
> +, COUNT
>  , GFP
>  )

I was showing a simplified example. I am using this, which I find more
readable:

-	old(\(COUNT, sizeof(*THING)\|sizeof(*THING), COUNT\), GFP)
+	new(*THING, COUNT, GFP)

-- 
Kees Cook

Re: [cocci] __free() attribute inhibits matching?

[Markus Elfring]

> I was showing a simplified example. I am using this, which I find more readable:
>
> -	old(\(COUNT, sizeof(*THING)\|sizeof(*THING), COUNT\), GFP)
> +	new(*THING, COUNT, GFP)

Such SmPL code variants can trigger different data processing results so far,
can't they?
It would be nice if really desired effects could become clearer somehow.

Regards,
Markus