linux-kernel - Re: [PATCH] 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

[an error occurred while processing this directive]

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

Message-ID: <9c32fa45-2b8f-4005-94cd-a9755981cff5@nvidia.com>
Date: Thu, 30 Oct 2025 16:36:46 +0200
From: Gal Pressman <gal@...dia.com>
To: Johan Hovold <johan@...nel.org>
Cc: Julia Lawall <Julia.Lawall@...ia.fr>,
 Nicolas Palix <nicolas.palix@...g.fr>, Jakub Kicinski <kuba@...nel.org>,
 Alexei Lazar <alazar@...dia.com>, Simon Horman <horms@...nel.org>,
 cocci@...ia.fr, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "scripts/coccinelle: Find PTR_ERR() to %pe
 candidates"

On 30/10/2025 16:06, Johan Hovold wrote:
> Note that in most cases you have ret variable that holds the errno,
> which would not be caught by this cocci script either:
> 
> 	ret = PTR_ERR(p);
> 	dev_err(dev, "failed to ...: %d\n", ret);
> 	return ret; // or goto out;

I have a followup patch that catches these kinds of cases as well.

> It still generates noise and extra work for already overworked
> maintainers that would need to explain over and over again why they are
> rejecting patches that appears to fix "warnings". Some will just take
> the patches, which leads to inconsistencies (as only a handful of
> printks will be converted) and a push for a style which again only some
> people prefer.

There's the subsystem maintainer "rules" documentation in
Documentation/process/maintainer-*.rst which can document these kinds of
stuff.

> 
> So I still think this script should be dropped. And you still need to
> review drivers manually if you really want to use %pe consistently (e.g.
> for all the cases where there is no error pointer to begin with).

I am not sure who is to decide, obviously I prefer not to revert it, but
I understand your concerns.