linux-kernel - Re: Coccinelle: Add a SmPL script for the reconsideration of redundant dev

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:   Thu, 20 Jun 2019 21:34:52 +0200
From:   Markus Elfring <Markus.Elfring@....de>
To:     Julia Lawall <julia.lawall@...6.fr>,
        kernel-janitors@...r.kernel.org
Cc:     Gilles Muller <Gilles.Muller@...6.fr>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Coccinelle <cocci@...teme.lip6.fr>,
        LKML <linux-kernel@...r.kernel.org>,
        Ding Xiang <dingxiang@...s.chinamobile.com>
Subject: Re: Coccinelle: Add a SmPL script for the reconsideration of
 redundant dev_err() calls

>> Would you prefer to clarify a more advanced approach?
>
> I think that something like
>
> if (IS_ERR(e))
> {
> <+...
> *dev_err(...)
> ...+>
> }
>
> would be more appropriate.

This SmPL construct can be more powerful.


> Whether there is a return or not doesn't really matter.

Such an adjustment can be helpful for a few operation modes.

But the number of statements in the if branch will influence the possibility
for the deletion of curly braces together with redundant dev_err() calls
by the SmPL patch mode.


>> Would you like to get the relevant function name dynamically determined?
>
> I have no idea what you consider "the relevant function name" to be.
> If it is always devm_ioremap_resource then it would seem that it does not
> need to be dynamically determined.

Do other functions share the same error reporting strategy so that any more
collateral software evolution can happen?

Regards,
Markus