linux-kernel - Re: [cocci] Revert "scripts/coccinelle: Find PTR

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: <aee265c7-eced-45e8-b016-0dffa5d415a9@web.de>
Date: Wed, 29 Oct 2025 18:00:12 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Johan Hovold <johan@...nel.org>, Gal Pressman <gal@...dia.com>,
 cocci@...ia.fr, Jakub Kicinski <kuba@...nel.org>,
 Julia Lawall <Julia.Lawall@...ia.fr>
Cc: LKML <linux-kernel@...r.kernel.org>, Alexei Lazar <alazar@...dia.com>,
 Nicolas Palix <nicolas.palix@...g.fr>, Simon Horman <horms@...nel.org>
Subject: Re: [cocci] Revert "scripts/coccinelle: Find PTR_ERR() to %pe
 candidates"

>> The test by no means mandates authors to use %pe, as the output says:
>> WARNING: Consider using %pe to print PTR_ERR()
>>
>> "Consider" :).
> 
> Right, but it's preceded by a big "WARNING".

Would you find an other message prefix nicer?


>> I would consider it best practice to use it, and a few drivers were
>> converted thanks to this test.

Would there be more convincing arguments needed according to better practice?


> Unlike the rest of the misc cocci scripts I skimmed, this one does not
> guard against any bugs. Instead it's pushing for a subjective style
> preference, which is just going to result in churn when the clean up
> crew starts sending mindless conversions of individual printks.
> 
> By all means, use %pe for your drivers, but it should not be forced
> upon the rest of us this way.

Is there a need to mark any more SmPL scripts as “controversial”?


>> If the issue is with automatic build bots, then maybe this test should
>> be excluded from them, rather than deleted?
> 
> It's both; it's the noise the new warnings generate but also the coming
> flood up patches to "fix" them. There are already some 40 commits or so
> in linux-next referencing this script.

How will the change tolerance evolve further?

Regards,
Markus