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]

Date:   Sat, 18 Jul 2020 11:16:04 +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

>>>> * 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.
>
> You proposed essentially  \( A \| B \) \( | C \| \)

I suggested also another adjustment.

Can additional minus characters be avoided if such a source code search pattern
would be specified in a single line?


> This is not valid syntax in the semantic patch language.

I hope that a solution can be found by our discussion.


> The branches of a \( \| \) have to be a valid expression, statement, type, etc,

Such information can become more interesting for safe application of
SmPL disjunctions.


> not some random string of tokens.

I got further imaginations in this software area.

Will the handling of optional transformation parameters be clarified better?


>> Patch reviews contain usual risks that suggestions are presented
>> which can be still questionable.
>
> These are not "usual risks".  You can easily test out your suggestion by
> yourself to see if it produces valid code.

Such an expectation can be reasonable in some cases.


> If it doesn't, then don't make the suggestion.

Would software limitations hinder any more improvements then?


>>> 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.
>
> No, I don't consider the effect to be desirable.

I propose to take another look at variations around source code verbosity.


>> Your change acceptance is varying to your development mood
>> (and other factors), isn't it?
>
> Not really.  My "change acceptance" increases when the person reporting
> them raises real problems that is blocking them in some work.

I presented open issues accordingly.


> And it decreases rapidly when the changes are almost all related to presumed
> "efficiencies" that have no impact in practice.

Change possibilities can get varying attention and corresponding development priorities.

Regards,
Markus