linux-kernel - Re: [v2 1/4] coccinelle: api: extend memdup_user transformation with GFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fa0ec546-9aee-5c95-428c-a225a3521f6f@web.de>
Date:   Sat, 18 Jul 2020 09:09:10 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Julia Lawall <julia.lawall@...ia.fr>,
        Denis Efremov <efremov@...ux.com>,
        Coccinelle <cocci@...teme.lip6.fr>
Cc:     Gilles Muller <Gilles.Muller@...6.fr>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [v2 1/4] coccinelle: api: extend memdup_user transformation with
 GFP_USER

>>> Applied.
>>
>> Do you care for patch review concerns according to this SmPL script adjustment?
>>
>> * https://lore.kernel.org/cocci/5c0dae88-e172-3ba6-f86c-d1a6238bb4c4@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.


>> * https://lore.kernel.org/cocci/c3464cad-e567-9ef5-b4e3-a01e3b11120b@web.de/
>>   https://lkml.org/lkml/2020/6/8/637
>
> This on is indeed a problem.

I find this feedback interesting.

* How does it fit to your response “Applied”?

* Will it trigger any more consequences?


> Markus, if you would limit your comments to suggesting SmPL code
> that is actually correct, ie that you have tested,

Patch reviews contain usual risks that suggestions are presented
which can be still questionable.


> and 2) stop suggesting stupid things over and over

We come along different development views.


> like that putting all of the virtual declarations on
> the same line would save space (it does, but who cares),

It seems that you admit a possibly desirable effect.
Will any more developers care also for SmPL coding style aspects?


> then I would take your suggestions more seriously.

Your change acceptance is varying to your development mood
(and other factors), isn't it?

Regards,
Markus