>> you do indeed need to put - in front of the second and third lines as well.
>
> Thanks, Markus, Julia. I will send v3.
How do you think about to discuss any remaining open issues already
on the current software development version for your transformation approach?
Regards,
Markus
On Sat, 18 Jul 2020, Denis Efremov wrote:
> Hi,
>
> On 7/18/20 9:45 AM, Julia Lawall wrote:
> > This on is indeed a problem. I think it was not detected in testing,
> > because in the current kernel the rule never applies. But Denis, in
> >
> > - to = \(kmalloc\|kzalloc\)
> >
Hi,
On 7/18/20 9:45 AM, Julia Lawall wrote:
> This on is indeed a problem. I think it was not detected in testing,
> because in the current kernel the rule never applies. But Denis, in
>
> - to = \(kmalloc\|kzalloc\)
> (size,\(GFP_KERNEL\|GFP_USER\|
> \(GF
> You proposed essentially \( A \| B \) \( | C \| \)
Will the software development attention grow for a topic
like “Extend support for handling of optional source code parts”?
https://github.com/coccinelle/coccinelle/issues/53
How do you think about another tiny example script for the semantic p
*
https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb...@web.de/
https://lkml.org/lkml/2020/6/9/568
>>>
>>> This one it complete nonsense.
>>
>> I hope that different views can be clarified for such a software situation
>> in more constructive ways.
>
> You proposed es
On Sat, 18 Jul 2020, Markus Elfring wrote:
> >>> Applied.
> >>
> >> Do you care for patch review concerns according to this SmPL script
> >> adjustment?
> >>
> >> *
> >> https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb...@web.de/
> >> https://lkml.org/lkml/2020/6/9/568
> >
> >
>>> Applied.
>>
>> Do you care for patch review concerns according to this SmPL script
>> adjustment?
>>
>> * https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb...@web.de/
>> https://lkml.org/lkml/2020/6/9/568
>
> This one it complete nonsense.
I hope that different views can be cl
On Sat, 18 Jul 2020, Markus Elfring wrote:
> > Applied.
>
> Do you care for patch review concerns according to this SmPL script
> adjustment?
>
> * https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb...@web.de/
> https://lkml.org/lkml/2020/6/9/568
This one it complete nonsense.
> Applied.
Do you care for patch review concerns according to this SmPL script adjustment?
* https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb...@web.de/
https://lkml.org/lkml/2020/6/9/568
* https://lore.kernel.org/cocci/c3464cad-e567-9ef5-b4e3-a01e3b111...@web.de/
https://lkml
On Mon, 8 Jun 2020, Denis Efremov wrote:
> Match GFP_USER and optional __GFP_NOWARN allocations with
> memdup_user.cocci rule.
> Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched
> memdup_user() from GFP_KERNEL to GFP_USER. In almost all cases it
> is still a good idea to recom
…
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -20,7 +20,9 @@ expression from,to,size;
…
> +- to = \(kmalloc\|kzalloc\)
> + (size,\(GFP_KERNEL\|GFP_USER\|
> + \(GFP_KERNEL\|GFP_USER\)|__GFP_NOWARN\));
I got the impression that this SmPL code needs another co
> Match GFP_USER and optional __GFP_NOWARN allocations with
> memdup_user.cocci rule.
You suggest another interesting software extension.
…
> +++ b/scripts/coccinelle/api/memdup_user.cocci
> @@ -20,7 +20,9 @@ expression from,to,size;
> identifier l1,l2;
> @@
>
> -- to = \(kmalloc\|kzalloc\)(si
Match GFP_USER and optional __GFP_NOWARN allocations with
memdup_user.cocci rule.
Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched
memdup_user() from GFP_KERNEL to GFP_USER. In almost all cases it
is still a good idea to recommend memdup_user() for GFP_KERNEL
allocations. The moti
13 matches
Mail list logo
