Re: [cocci] [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor

"Theodore Tso" <[email protected]> Tue, 10 Mar 2026 10:23:48 -0400
Newsgroups fr.inria.cocci,dev.linux.lists.dm-devel,dev.linux.lists.gfs2,dev.linux.lists.iommu,dev.linux.lists.ntfs3,dev.linux.lists.sched-ext,dev.linux.lists.v9fs,org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-mtd,org.infradead.lists.linux-phy,org.infradead.lists.linux-rockchip,org.kernel.vger.bpf,org.kernel.vger.ceph-devel,org.kernel.vger.kvm,org.kernel.vger.linux-block,org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-clk,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-gpio,org.kernel.vger.linux-hyperv,org.kernel.vger.linux-input,org.kernel.vger.linux-kernel,org.kernel.vger.linux-leds,org.kernel.vger.linux-media,org.kernel.vger.linux-mips,org.kernel.vger.linux-modules,org.kernel.vger.linux-nfs,org.kernel.vger.linux-omap,org.kernel.vger.linux-pm,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.linux-sctp,org.kernel.vger.linux-security-module,org.kernel.vger.linux-sh,org.kernel.vger.linux-sound,org.kernel.vger.linux-trace-kernel,org.kernel.vger.linux-usb,org.kernel.vger.linux-wireless,org.kernel.vger.netdev,org.kernel.vger.target-devel,org.kvack.linux-mm,org.osuosl.intel-wired-lan,org.ozlabs.lists.linux-erofs
Message-ID <[email protected]> 
On Tue, Mar 10, 2026 at 12:48:26PM +0100, Philipp Hahn wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
> 
> I've written a Coccinelle patch to find and patch those instances.
> The patches follow grouped by subsystem.

I'm going to gently suggest that you *not* try to do this as a
tree-wide change, since we don't need to change some interface
requiring a global, flag day change.  This is instead a cleanup, which
maybe makes the code slightly better, but which also has a the
downside of breaking lots of inflight development patches by
potentially causing merge or patch conflicts.

So why don't you send it to each subsystem as a separate patch or
small patch series, instead of spamming a dozen-plus mailing lists,
are probably hundreds of developers, most of whom aren't going to
care about changs in some far flung part of the kernel?

Regards,

						- Ted