* Re: [PATCH v6] lsm: Add LSM hook security_unix_find
From: Paul Moore @ 2026-03-11 16:08 UTC (permalink / raw)
To: Justin Suess
Cc: Günther Noack, brauner, demiobenour, fahimitahera, hi, horms,
ivanov.mikhail1, jannh, jmorris, john.johansen,
konstantin.meskhidze, linux-security-module, m, matthieu, mic,
netdev, samasth.norway.ananda, serge, viro
In-Reply-To: <abFhawSTjNoa-KaH@suesslenovo>
On Wed, Mar 11, 2026 at 8:34 AM Justin Suess <utilityemal77@gmail.com> wrote:
>
> On Tue, Mar 10, 2026 at 06:39:12PM -0400, Paul Moore wrote:
> > On Thu, Feb 19, 2026 at 3:26 PM Günther Noack <gnoack3000@gmail.com> wrote:
> > > On Thu, Feb 19, 2026 at 03:04:59PM -0500, Justin Suess wrote:
> > > > Add a LSM hook security_unix_find.
> > > >
> > > > This hook is called to check the path of a named unix socket before a
> > > > connection is initiated. The peer socket may be inspected as well.
> > > >
> > > > Why existing hooks are unsuitable:
> > > >
> > > > Existing socket hooks, security_unix_stream_connect(),
> > > > security_unix_may_send(), and security_socket_connect() don't provide
> > > > TOCTOU-free / namespace independent access to the paths of sockets.
> > > >
> > > > (1) We cannot resolve the path from the struct sockaddr in existing hooks.
> > > > This requires another path lookup. A change in the path between the
> > > > two lookups will cause a TOCTOU bug.
> > > >
> > > > (2) We cannot use the struct path from the listening socket, because it
> > > > may be bound to a path in a different namespace than the caller,
> > > > resulting in a path that cannot be referenced at policy creation time.
> > > >
> > > > Cc: Günther Noack <gnoack3000@gmail.com>
> > > > Cc: Tingmao Wang <m@maowtm.org>
> > > > Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> > > > ---
> > > > include/linux/lsm_hook_defs.h | 5 +++++
> > > > include/linux/security.h | 11 +++++++++++
> > > > net/unix/af_unix.c | 13 ++++++++++---
> > > > security/security.c | 20 ++++++++++++++++++++
> > > > 4 files changed, 46 insertions(+), 3 deletions(-)
> >
> > ...
> >
> > > Reviewed-by: Günther Noack <gnoack3000@gmail.com>
> > >
> > > Thank you, this looks good. I'll include it in the next version of the
> > > Unix connect patch set again.
> >
> > I'm looking for this patchset to review/ACK the new hook in context,
> > but I'm not seeing it in my inbox or lore. Did I simply miss the
> > patchset or is it still a work in progress? No worries if it hasn't
> > been posted yet, I just wanted to make sure I wasn't holding this up
> > any more than I already may have :)
>
> Good Morning Paul,
>
> Can't speak to the rest of the patch, but I sent this LSM hook for
> review purposes before inclusion with the rest of the V6 of this patch.
>
> Günther added his review tag, but I was asked to make some minor comment / commit
> message updates. I sent the same patch, with updated comments/commit to him
> in a follow up, off-list email to avoid spamming the list. No code changes were
> made, just comments.
>
> I don't think this particular patch will change substantially, unless we find
> something unexpected. But the way we use the hook may change (esp wrt to
> locking and the SOCK_DEAD state), which is important for your review.
>
> So you may want to hold off your review until the full V6 series gets sent so
> you can review the hook in context. There were some questions about
> locking that needed proper digging into. [1]
Great, thanks for the update, that was helpful. As you recommend,
I'll hold off on reviewing this further until we have the full context
of the other patchset; we've already talked about this hook addition a
few times anyway, and based on a quick look yesterday, nothing
particularly evil jumped out at me.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 0/3] Firmware LSM hook
From: Paul Moore @ 2026-03-11 16:06 UTC (permalink / raw)
To: Leon Romanovsky
Cc: James Morris, Serge E. Hallyn, Jason Gunthorpe, Saeed Mahameed,
Itay Avraham, Dave Jiang, Jonathan Cameron, linux-security-module,
linux-kernel, linux-rdma, Chiara Meiohas, Maher Sanalla,
Edward Srouji
In-Reply-To: <20260311081955.GS12611@unreal>
On Wed, Mar 11, 2026 at 4:20 AM Leon Romanovsky <leon@kernel.org> wrote:
> On Tue, Mar 10, 2026 at 05:40:02PM -0400, Paul Moore wrote:
> > On Tue, Mar 10, 2026 at 3:30 PM Leon Romanovsky <leon@kernel.org> wrote:
> > > On Tue, Mar 10, 2026 at 02:24:40PM -0400, Paul Moore wrote:
> > > > On Tue, Mar 10, 2026 at 5:07 AM Leon Romanovsky <leon@kernel.org> wrote:
> > > > > On Mon, Mar 09, 2026 at 07:10:25PM -0400, Paul Moore wrote:
> > > > > > On Mon, Mar 9, 2026 at 3:37 PM Leon Romanovsky <leon@kernel.org> wrote:
> > > > > > > On Mon, Mar 09, 2026 at 02:32:39PM -0400, Paul Moore wrote:
> > > > > > > > On Mon, Mar 9, 2026 at 7:15 AM Leon Romanovsky <leon@kernel.org> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > > Hi Leon,
> > > > > > > >
> > > > > > > > At the link below, you'll find guidance on submitting new LSM hooks.
> > > > > > > > Please take a look and let me know if you have any questions.
> > > > > > > >
> > > > > > > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks
> > > > > > >
> > > > > > > I assume that you are referring to this part:
> > > > > >
> > > > > > I'm referring to all of the guidance, but yes, at the very least that
> > > > > > is something that I think we need to see in a future revision of this
> > > > > > patchset.
> > > > > >
> > > > > > > * New LSM hooks must demonstrate their usefulness by providing a meaningful
> > > > > > > implementation for at least one in-kernel LSM. The goal is to demonstrate
> > > > > > > the purpose and expected semantics of the hooks. Out of tree kernel code,
> > > > > > > and pass through implementations, such as the BPF LSM, are not eligible
> > > > > > > for LSM hook reference implementations.
> > > > > > >
> > > > > > > The point is that we are not inspecting a kernel call, but the FW mailbox,
> > > > > > > which has very little meaning to the kernel. From the kernel's perspective,
> > > > > > > all relevant checks have already been performed, but the existing capability
> > > > > > > granularity does not allow us to distinguish between FW_CMD1 and FW_CMD2.
> > > > > >
> > > > > > It might help if you could phrase this differently, as I'm not
> > > > > > entirely clear on your argument. LSMs are not limited to enforcing
> > > > > > access controls on requests the kernel understands (see the SELinux
> > > > > > userspace object manager concept), and the idea of access controls
> > > > > > with greater granularity than capabilities is one of the main reasons
> > > > > > people look to LSMs for access control (SELinux, AppArmor, Smack,
> > > > > > etc.).
> > > > >
> > > > > I should note that my understanding of LSM is limited, so some parts of my
> > > > > answers may be inaccurate.
> > > > >
> > > > > What I am referring to is a different level of granularity — specifically,
> > > > > the internals of the firmware commands. In the proposed approach, BPF
> > > > > programs would make decisions based on data passed through the mailbox.
> > > > > That mailbox format varies across vendors, and may even differ between
> > > > > firmware versions from the same vendor.
> > > >
> > > > That helps, thank you.
> > > >
> > > > > > > Here we propose a generic interface that can be applied to all FWCTL
> > > > > > > devices without out-of-tree kernel code at all.
> > > > > >
> > > > > > I expected to see a patch implementing some meaningful support for
> > > > > > access controls using these hooks in one of the existing LSMs, I did
> > > > > > not see that in this patchset.
> > > > >
> > > > > In some cases, the mailbox is forwarded from user space unchanged, but
> > > > > in others the kernel modifies it before submitting it to the FW.
> > > >
> > > > Without a standard format, opcode definitions, etc. I suspect
> > > > integrating this into an LSM will present a number of challenges.
> > >
> > > The opcode is relatively easy to extract from the mailbox and pass to the LSM.
> > > All drivers implement some variant of mlx5ctl_validate_rpc()/devx_is_general_cmd()
> > > to validate the opcode. The problem is that this check alone is not sufficient.
> > >
> > > > Instead of performing an LSM access control check before submitting
> > > > the firmware command, it might be easier from an LSM perspective to
> > > > have the firmware call into the kernel/LSM for an access control
> > > > decision before performing a security-relevant action.
> > >
> > > Ultimately, the LSM must make a decision for each executed firmware
> > > command. This will need to be handled one way or another, and will
> > > likely require parsing the mailbox again.
> >
> > As it's unlikely that parsing the mailbox is something that a LSM will
> > want to handle,
>
> I believe this approach offers the cleanest and most natural way to support
> all mailbox‑based devices.
>
> > my suggestion was to leverage the existing mailbox parsing in the firmware
> > and require the firmware to call into the LSM when authorization is needed.
> >
> > > > This removes the challenge of parsing/interpreting the arbitrary firmware commands,
> > > > but it does add some additional complexity of having to generically
> > > > represent the security relevant actions the firmware might request
> > >
> > > The difference here is that the proposed LSM hook is intended to disable
> > > certain functionality provided by the firmware, effectively depending on
> > > the operator’s preferences.
> >
> > My suggestion would also allow a LSM hook to disable certain firmware
> > functionality; however, the firmware itself would need to call the LSM
> > to check if the functionality is authorized.
>
> This suggestion adds an extra call from the FW to the LSM for every command, even
> for systems which don't have LSM at all.
If latency is a concern, I imagine we could create an LSM hook to
report whether any LSMs provided firmware access controls. The
firmware could then use that hook, potentially caching the result, to
limit its calls into the LSM.
> The FW must pass the already parsed data
> back to the LSM; otherwise, the LSM has no basis to decide whether to accept or
> reject the request.
>
> For example, consider the MLX5_CMD_OP_QUERY_DCT command handled in
> mlx5ctl_validate_rpc(). DCT in RDMA refers to Dynamically Connected
> Transport, a Mellanox-specific extension that effectively introduces a new
> QP‑type family on top of the standard RC/UC/UD transports. This type does not
> exist for other vendors, each of whom provides its own vendor‑specific
> extensions. All parameters here are tightly coupled to those specific
> commands.
>
> It is unrealistic to expect different firmware implementations to supply
> their data in a common format that would allow the LSM to make a generic
> decision.
That's unfortunate as that would be the easiest path forward.
Regardless, you are welcome to work on whatever implementation you
think makes sense for any of the in-tree LSMs, with that in place we
can take another look at the firmware command hooks.
Good luck.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Markus Elfring @ 2026-03-11 15:12 UTC (permalink / raw)
To: Philipp Hahn, cocci, Julia Lawall, Nicolas Palix
Cc: amd-gfx, apparmor, bpf, ceph-devel, dm-devel, dri-devel, gfs2,
intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-leds, linux-media, linux-mips, linux-mm,
linux-modules, linux-mtd, linux-nfs, linux-omap, linux-phy,
linux-pm, linux-rockchip, linux-s390, linux-scsi, linux-sctp,
linux-security-module, linux-sh, linux-sound, linux-stm32,
linux-trace-kernel, linux-usb, linux-wireless, netdev, ntfs3,
samba-technical, sched-ext, target-devel, tipc-discussion, v9fs,
LKML
In-Reply-To: <20260310-b4-is_err_or_null-v1-1-bd63b656022d@avm.de>
…
> +// Confidence: High
Some contributors presented discerning comments for this change approach.
Thus I became also curious how much they can eventually be taken better into account
by the means of the semantic patch language (Coccinelle software).
…
+@p1 depends on patch@
+expression E;
+@@
+(
> +- E != NULL && !IS_ERR(E)
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- E == NULL || IS_ERR(E)
> ++ IS_ERR_OR_NULL(E)
> +|
> +- !IS_ERR(E) && E != NULL
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- IS_ERR(E) || E == NULL
> ++ IS_ERR_OR_NULL(E)
> +)
Several detected expressions should refer to return values from function calls.
https://en.wikipedia.org/wiki/Return_statement
* Do any development challenges hinder still the determination of corresponding
failure predicates?
* How will interests evolve to improve data processing any further for such
use cases?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 15/61] trace: Prefer IS_ERR_OR_NULL over manual NULL check
From: Geert Uytterhoeven @ 2026-03-11 14:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu (Google), Philipp Hahn, amd-gfx, apparmor, bpf,
ceph-devel, cocci, dm-devel, dri-devel, gfs2, intel-gfx,
intel-wired-lan, iommu, kvm, linux-arm-kernel, linux-block,
linux-bluetooth, linux-btrfs, linux-cifs, linux-clk, linux-erofs,
linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv, linux-input,
linux-kernel, linux-leds, linux-media, linux-mips, linux-mm,
linux-modules, linux-mtd, linux-nfs, linux-omap, linux-phy,
linux-pm, linux-rockchip, linux-s390, linux-scsi, linux-sctp,
linux-security-module, linux-sh, linux-sound, linux-stm32,
linux-trace-kernel, linux-usb, linux-wireless, netdev, ntfs3,
samba-technical, sched-ext, target-devel, tipc-discussion, v9fs,
Mathieu Desnoyers
In-Reply-To: <20260311100332.6a2ce4b1@gandalf.local.home>
Hi Steven,
On Wed, 11 Mar 2026 at 15:03, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 11 Mar 2026 14:13:32 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > Hmm, now IS_ERR_OR_NULL() is an inline function, so it is safe.
> > But if you want to use IS_ERR_OR_NULL() here, it will be better something like
> >
> > node = rhashtable_walk_next(&iter);
> > while (!IS_ERR_OR_NULL(node)) {
> > fprobe_remove_node_in_module(mod, node, &alist);
> > node = rhashtable_walk_next(&iter);
> > }
>
> But now you need to have a duplicate code in order to acquire "node"
>
> I think the patch just makes the code worse.
Obviously we need a new for_each_*() helper hiding all the gory internals?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 15/61] trace: Prefer IS_ERR_OR_NULL over manual NULL check
From: Steven Rostedt @ 2026-03-11 14:03 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs, Mathieu Desnoyers
In-Reply-To: <20260311141332.b611237d36b61b2409e66cb3@kernel.org>
On Wed, 11 Mar 2026 14:13:32 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> Hmm, now IS_ERR_OR_NULL() is an inline function, so it is safe.
> But if you want to use IS_ERR_OR_NULL() here, it will be better something like
>
> node = rhashtable_walk_next(&iter);
> while (!IS_ERR_OR_NULL(node)) {
> fprobe_remove_node_in_module(mod, node, &alist);
> node = rhashtable_walk_next(&iter);
> }
But now you need to have a duplicate code in order to acquire "node"
I think the patch just makes the code worse.
-- Steve
^ permalink raw reply
* Re: [PATCH 36/61] arch/sh: Prefer IS_ERR_OR_NULL over manual NULL check
From: Geert Uytterhoeven @ 2026-03-11 13:15 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz
In-Reply-To: <20260310-b4-is_err_or_null-v1-36-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 at 12:56, Philipp Hahn <phahn-oss@avm.de> wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Yoshinori Sato <ysato@users.sourceforge.jp>
> To: Rich Felker <dalias@libc.org>
> To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: linux-sh@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Thomas Weißschuh @ 2026-03-11 13:19 UTC (permalink / raw)
To: Eric Biggers
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Nicolas Schier,
Daniel Gomez, Aaron Tomlin, Christophe Leroy (CS GROUP),
Nicolas Schier, Nicolas Bouchinet, Xiu Jianfeng,
Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260311011218.GA212983@quark>
On 2026-03-10 18:12:18-0700, Eric Biggers wrote:
> On Tue, Jan 13, 2026 at 01:28:59PM +0100, Thomas Weißschuh wrote:
> > The current signature-based module integrity checking has some drawbacks
> > in combination with reproducible builds. Either the module signing key
> > is generated at build time, which makes the build unreproducible, or a
> > static signing key is used, which precludes rebuilds by third parties
> > and makes the whole build and packaging process much more complicated.
>
> I think this actually undersells the feature.
(...)
> So I think this is how module authentication should have been done
> originally, and I'm glad to see this is finally being fixed.
Thanks, that is nice to hear.
> > +struct module_hashes_proof {
> > + __be32 pos;
> > + u8 hash_sigs[][MODULE_HASHES_HASH_SIZE];
> > +} __packed;
>
> Is the choice of big endian for consistency with struct
> module_signature? Little endian is the usual choice in new code.
Yes, it's for consistency. But I am fine with either way. Given that
this is essentially an internal ABI, we could always change it later.
> > diff --git a/include/linux/module_signature.h b/include/linux/module_signature.h
> > index a45ce3b24403..3b510651830d 100644
> > --- a/include/linux/module_signature.h
> > +++ b/include/linux/module_signature.h
> > @@ -18,6 +18,7 @@ enum pkey_id_type {
> > PKEY_ID_PGP, /* OpenPGP generated key ID */
> > PKEY_ID_X509, /* X.509 arbitrary subjectKeyIdentifier */
> > PKEY_ID_PKCS7, /* Signature in PKCS#7 message */
> > + PKEY_ID_MERKLE, /* Merkle proof for modules */
>
> I recommend making the hash algorithm explicit:
>
> PKEY_ID_MERKLE_SHA256, /* SHA-256 merkle proof for modules */
>
> While I wouldn't encourage the addition of another hash algorithm
> (specifying one good algorithm for now is absolutely the right choice),
> if someone ever does need to add another one, we'd want them to be
> guided to simply introduce a new value of this enum rather than hack it
> in some other way.
The idea here was that this will only ever be used for module built as
part of the kernel build. So the actual implementation could change freely
without affecting anything.
But I don't have hard feelings about it.
> > +static void hash_entry(const void *left, const void *right, void *out)
>
> Byte arrays should use u8 instead of void
Ack.
> > diff --git a/scripts/modules-merkle-tree.c b/scripts/modules-merkle-tree.c
> [...]
>
> > +struct file_entry {
> > + char *name;
> > + unsigned int pos;
> > + unsigned char hash[EVP_MAX_MD_SIZE];
>
> Considering that the hash algorithm is fixed, EVP_MAX_MD_SIZE can be
> replaced with a tighter local definition:
Ack.
> #define MAX_HASH_SIZE 32
IMO it shouldn't even mention 'MAX', as there is only one hash
algorithm.
(...)
> > +{
> > + fprintf(stderr,
> > + "Usage: scripts/modules-merkle-tree <root definition>\n");
> > + exit(2);
>
> This should show both parameters, <root hash> <new suffix>
Ack.
> But they probably should be flipped to put the output second.
Ack.
> Though, is <new suffix> needed at all? It looks like it doesn't
> actually affect the output.
It will be required for compatibility with INSTALL_MOD_STRIP,
two patches later. I'll move this code into the later patch.
> > + hash_evp = EVP_get_digestbyname("sha256");
>
> EVP_sha256()
(...)
Ack to all other remarks.
Thomas
^ permalink raw reply
* Re: [PATCH v4 09/17] module: Make module loading policy usable without MODULE_SIG
From: Thomas Weißschuh @ 2026-03-11 12:59 UTC (permalink / raw)
To: Eric Biggers
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Nicolas Schier,
Daniel Gomez, Aaron Tomlin, Christophe Leroy (CS GROUP),
Nicolas Schier, Nicolas Bouchinet, Xiu Jianfeng,
Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260310220146.GE120274@quark>
On 2026-03-10 15:01:46-0700, Eric Biggers wrote:
> On Tue, Jan 13, 2026 at 01:28:53PM +0100, Thomas Weißschuh wrote:
> > The loading policy functionality will also be used by the hash-based
> > module validation. Split it out from CONFIG_MODULE_SIG so it is usable
> > by both.
> >
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > ---
> > include/linux/module.h | 8 ++++----
> > kernel/module/Kconfig | 5 ++++-
> > kernel/module/main.c | 26 +++++++++++++++++++++++++-
> > kernel/module/signing.c | 21 ---------------------
> > 4 files changed, 33 insertions(+), 27 deletions(-)
> >
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index f288ca5cd95b..f9601cba47cd 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -444,7 +444,7 @@ struct module {
> > const u32 *gpl_crcs;
> > bool using_gplonly_symbols;
> >
> > -#ifdef CONFIG_MODULE_SIG
> > +#ifdef CONFIG_MODULE_SIG_POLICY
> > /* Signature was verified. */
> > bool sig_ok;
> > #endif
> [...]
> > +config MODULE_SIG_POLICY
> > + def_bool MODULE_SIG
>
> Maybe MODULE_AUTH_POLICY? Hash-based module authentication does not use
> signatures.
>
> This issue appears elsewhere in the code too. There are lots of places
> that still refer to module signatures or "sigs", when really module
> authentication is meant.
>
> I'm not sure how far you want to go with the renaming, but it's
> something to think about. It's confusing to use the term "signature" to
> mean something that is not a signature.
Ack. "authentication" is much better, I'll use that.
Thomas
^ permalink raw reply
* Re: [PATCH v4 06/17] kbuild: add stamp file for vmlinux BTF data
From: Thomas Weißschuh @ 2026-03-11 12:58 UTC (permalink / raw)
To: Eric Biggers
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Nicolas Schier,
Daniel Gomez, Aaron Tomlin, Christophe Leroy (CS GROUP),
Nicolas Schier, Nicolas Bouchinet, Xiu Jianfeng,
Fabian Grünbichler, Arnout Engelen, Mattia Rizzolo, kpcyrd,
Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260310213606.GD120274@quark>
On 2026-03-10 14:36:06-0700, Eric Biggers wrote:
> On Tue, Jan 13, 2026 at 01:28:50PM +0100, Thomas Weißschuh wrote:
> > The upcoming module hashes functionality will build the modules in
> > between the generation of the BTF data and the final link of vmlinux.
> > Having a dependency from the modules on vmlinux would make this
> > impossible as it would mean having a cyclic dependency.
> > Break this cyclic dependency by introducing a new target.
> >
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > ---
> > scripts/Makefile.modfinal | 4 ++--
> > scripts/link-vmlinux.sh | 6 ++++++
> > 2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/Makefile.modfinal b/scripts/Makefile.modfinal
> > index 149e12ff5700..adfef1e002a9 100644
> > --- a/scripts/Makefile.modfinal
> > +++ b/scripts/Makefile.modfinal
> > @@ -56,8 +56,8 @@ if_changed_except = $(if $(call newer_prereqs_except,$(2))$(cmd-check), \
> > printf '%s\n' 'savedcmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
> >
> > # Re-generate module BTFs if either module's .ko or vmlinux changed
> > -%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/vmlinux) FORCE
> > - +$(call if_changed_except,ld_ko_o,$(objtree)/vmlinux)
> > +%.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/.tmp_vmlinux_btf.stamp) FORCE
> > + +$(call if_changed_except,ld_ko_o,$(objtree)/.tmp_vmlinux_btf.stamp)
> > ifdef CONFIG_DEBUG_INFO_BTF_MODULES
> > +$(if $(newer-prereqs),$(call cmd,btf_ko))
> > endif
> > diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> > index 4ab44c73da4d..8c98f8645a5c 100755
> > --- a/scripts/link-vmlinux.sh
> > +++ b/scripts/link-vmlinux.sh
> > @@ -111,6 +111,7 @@ vmlinux_link()
> > gen_btf()
> > {
> > local btf_data=${1}.btf.o
> > + local btf_stamp=.tmp_vmlinux_btf.stamp
> >
> > info BTF "${btf_data}"
> > LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${PAHOLE_FLAGS} ${1}
> > @@ -131,6 +132,11 @@ gen_btf()
> > fi
> > printf "${et_rel}" | dd of="${btf_data}" conv=notrunc bs=1 seek=16 status=none
> >
> > + info STAMP $btf_stamp
> > + if ! cmp --silent $btf_data $btf_stamp; then
> > + cp $btf_data $btf_stamp
> > + fi
This patch will be gone from the next revision of the series.
Making use of the recently introduced vmlinux.unstripped,
as suggested by Petr, removes any modifications to link-vmlinux.sh
and the issue that this patch tried to address.
> A "stamp file" is traditionally an empty file that is written when some
> build step has completed. The above code is instead copying the entire
> .tmp_vmlinux1.btf.o file (megabytes in size) to .tmp_vmlinux_btf.stamp.
The goal here was not to only have a reference timestamp, but
specifically the reference file contents.
Note: The duplicated vmlinux.unstripped in its current form is by far
larger than .tmp_vmlinux1.btf.o.
> So, it's not clear to me why the stamp file is needed at all, versus
> depending directly on .tmp_vmlinux1.btf.o.
>
> I guess 'make' doesn't know about the dependencies of
> .tmp_vmlinux1.btf.o. But the same is true of the stamp file, right? So
> either way, how would 'make' know to finish rebuilding the file before
> starting to execute the "Re-generate module BTFs" rule?
The problem was not the ordering, this is handled within link-vmlinux.sh.
IIRC originally without this patch even no-op rebuilds would end up
rebuilding the modules. Using .tmp_vmlinux1.btf.o may have worked too.
But in v4, the patch "kbuild: generate module BTF based on
vmlinux.unstripped" was added, which also solves this problem.
> Also, passing the long option '--silent' to 'cmp' creates a dependency
> on the GNU implementation of 'cmp', which isn't documented as a kernel
> build dependency. Probably better to use the short option '-s'.
Ack.
> Also, the stamp file isn't being deleted by 'make clean'. It looks like
> it would need to be added to cleanup() in link-vmlinux.sh.
Ack.
Thomas
^ permalink raw reply
* Re: [PATCH v6] lsm: Add LSM hook security_unix_find
From: Justin Suess @ 2026-03-11 12:34 UTC (permalink / raw)
To: Paul Moore
Cc: Günther Noack, brauner, demiobenour, fahimitahera, hi, horms,
ivanov.mikhail1, jannh, jmorris, john.johansen,
konstantin.meskhidze, linux-security-module, m, matthieu, mic,
netdev, samasth.norway.ananda, serge, viro
In-Reply-To: <CAHC9VhSu=YtE0dMiEtUQgz0pFy5K8cuHh_EWprNtFTDAxhss_w@mail.gmail.com>
On Tue, Mar 10, 2026 at 06:39:12PM -0400, Paul Moore wrote:
> On Thu, Feb 19, 2026 at 3:26 PM Günther Noack <gnoack3000@gmail.com> wrote:
> > On Thu, Feb 19, 2026 at 03:04:59PM -0500, Justin Suess wrote:
> > > Add a LSM hook security_unix_find.
> > >
> > > This hook is called to check the path of a named unix socket before a
> > > connection is initiated. The peer socket may be inspected as well.
> > >
> > > Why existing hooks are unsuitable:
> > >
> > > Existing socket hooks, security_unix_stream_connect(),
> > > security_unix_may_send(), and security_socket_connect() don't provide
> > > TOCTOU-free / namespace independent access to the paths of sockets.
> > >
> > > (1) We cannot resolve the path from the struct sockaddr in existing hooks.
> > > This requires another path lookup. A change in the path between the
> > > two lookups will cause a TOCTOU bug.
> > >
> > > (2) We cannot use the struct path from the listening socket, because it
> > > may be bound to a path in a different namespace than the caller,
> > > resulting in a path that cannot be referenced at policy creation time.
> > >
> > > Cc: Günther Noack <gnoack3000@gmail.com>
> > > Cc: Tingmao Wang <m@maowtm.org>
> > > Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> > > ---
> > > include/linux/lsm_hook_defs.h | 5 +++++
> > > include/linux/security.h | 11 +++++++++++
> > > net/unix/af_unix.c | 13 ++++++++++---
> > > security/security.c | 20 ++++++++++++++++++++
> > > 4 files changed, 46 insertions(+), 3 deletions(-)
>
> ...
>
> > Reviewed-by: Günther Noack <gnoack3000@gmail.com>
> >
> > Thank you, this looks good. I'll include it in the next version of the
> > Unix connect patch set again.
>
> I'm looking for this patchset to review/ACK the new hook in context,
> but I'm not seeing it in my inbox or lore. Did I simply miss the
> patchset or is it still a work in progress? No worries if it hasn't
> been posted yet, I just wanted to make sure I wasn't holding this up
> any more than I already may have :)
>
Good Morning Paul,
Can't speak to the rest of the patch, but I sent this LSM hook for
review purposes before inclusion with the rest of the V6 of this patch.
Günther added his review tag, but I was asked to make some minor comment / commit
message updates. I sent the same patch, with updated comments/commit to him
in a follow up, off-list email to avoid spamming the list. No code changes were
made, just comments.
I don't think this particular patch will change substantially, unless we find
something unexpected. But the way we use the hook may change (esp wrt to
locking and the SOCK_DEAD state), which is important for your review.
So you may want to hold off your review until the full V6 series gets sent so
you can review the hook in context. There were some questions about
locking that needed proper digging into. [1]
Thank you for your time.
Justin
[1]: https://lore.kernel.org/linux-security-module/20260220.82a8adda6f95@gnoack.org/
> --
> paul-moore.com
^ permalink raw reply
* Re: Subject: x86/msr + lockdown: allow access to **documented** RAPL/TCC controls under Secure Boot
From: bauen1 @ 2026-03-11 12:18 UTC (permalink / raw)
To: Rafael J. Wysocki, Artem S. Tashkinov
Cc: x86, Linux Kernel Mailing List, linux-pm, linux-efi,
linux-security-module, Srinivas Pandruvada, Zhang, Rui
In-Reply-To: <CAJZ5v0hokpC_2E77nrm2KHeOdhhH6qvYsg3wCQpTEG=PCim=ww@mail.gmail.com>
On 3/9/26 4:13 PM, Rafael J. Wysocki wrote:
> On Mon, Mar 9, 2026 at 1:24 PM Artem S. Tashkinov <aros@gmx.com> wrote:
>>
>> Hello,
>>
>> When Secure Boot is enabled and kernel lockdown is active, the x86 MSR
>> driver blocks all raw MSR access from user space via `/dev/cpu/*/msr`.
>> This effectively prevents legitimate use of documented CPU power and
>> thermal management interfaces such as RAPL power limits (PL1/PL2) and
>> the TCC/TjOffset control. These registers are part of Intel’s
>> **publicly** documented architectural interface and have been stable
>> across many generations of processors.
>
> There is a power capping RAPL driver. What's the problem with it with
> Secure Boot enabled?
Hello,
I believe that the comment about Secure Boot might come from the partially
incorrect documentation of lockdown:
https://lore.kernel.org/linux-security-module/20260203195001.20131-1-hi@alyssa.is/
> -On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled
> -if the system boots in EFI Secure Boot mode.
> This is true for Fedora, where this page was sourced from, but I don't
> believe it has ever been true for the mainline kernel, because Linus
> rejected it.
>
>> As a result, under Secure Boot Linux users lose the ability to read or
>> adjust **standard** power-management controls that remain available
>> through equivalent tooling on other operating systems.
>
> The power capping RAPL driver is there, please use it. It is documented even.
>
> There is also a driver for TCC/TjOffset control, it is called intel_tcc_cooling.
>
> And there are utilities in user space (for example, Intel thermald)
> that use those interfaces.
>
>> The current all-or-nothing restriction appears broader than necessary
>> for the stated goal of protecting kernel integrity. MSRs associated with
>> power limits and TCC offset are not privileged debugging or microcode
>> interfaces but standard hardware configuration knobs intended for
>> platform power and thermal management.
>>
>> It would be useful if the kernel either allowed access to a small
>> whitelist of such documented registers under lockdown or exposed a
>> mediated kernel interface for adjusting them. Without such a mechanism,
>> Secure Boot effectively disables legitimate and widely used
>> power/thermal tuning functionality on modern Intel laptops.
>>
>> Most (if not all) Intel laptops don't expose or allow to configure
>> PL1/PL2 limits in BIOS/EFI either.
>
> Because it is not necessary to do so.
>
--
bauen1
^ permalink raw reply
* Re: [PATCH v2 3/5] rust: kernel: add LSM abstraction layer
From: kernel test robot @ 2026-03-11 12:07 UTC (permalink / raw)
To: Jamie Lindsey, rust-for-linux, linux-security-module
Cc: oe-kbuild-all, ojeda, paul, aliceryhl, jmorris, serge, jamie
In-Reply-To: <0102019cdb4c705e-7d46b4f3-5cbb-4a6a-b315-e10f182fa987-000000@eu-west-1.amazonses.com>
Hi Jamie,
kernel test robot noticed the following build errors:
[auto build test ERROR on rust/rust-next]
[also build test ERROR on linus/master v7.0-rc3 next-20260310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Jamie-Lindsey/rust-helpers-add-C-shims-for-LSM-hook-initialisation/20260311-131258
base: https://github.com/Rust-for-Linux/linux rust-next
patch link: https://lore.kernel.org/r/0102019cdb4c705e-7d46b4f3-5cbb-4a6a-b315-e10f182fa987-000000%40eu-west-1.amazonses.com
patch subject: [PATCH v2 3/5] rust: kernel: add LSM abstraction layer
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260311/202603111327.ZxGK7MvE-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260311/202603111327.ZxGK7MvE-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603111327.ZxGK7MvE-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
>> warning: unresolved link to `define_lsm`
--> rust/kernel/lsm.rs:7:46
|
7 | //! registers itself at boot time with the [`define_lsm!`] macro.
| ^^^^^^^^^^^ no item named `define_lsm` in scope
|
= note: `macro_rules` named `define_lsm` exists in this crate, but it is not in scope at this link's location
= note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default
--
PATH=/opt/cross/clang-20/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
INFO PATH=/opt/cross/rustc-1.88.0-bindgen-0.72.1/cargo/bin:/opt/cross/clang-20/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/usr/bin/timeout -k 100 12h /usr/bin/make KCFLAGS=\ -fno-crash-diagnostics\ -Wno-error=return-type\ -Wreturn-type\ -funsigned-char\ -Wundef\ -falign-functions=64 W=1 --keep-going LLVM=1 -j32 -C source O=/kbuild/obj/consumer/x86_64-rhel-9.4-rust ARCH=x86_64 SHELL=/bin/bash rustfmtcheck
make: Entering directory '/kbuild/src/consumer'
make[1]: Entering directory '/kbuild/obj/consumer/x86_64-rhel-9.4-rust'
>> Diff in rust/kernel/lsm.rs:120:
/// `file` must be a valid, non-null pointer to a `struct file` that
/// remains valid for the duration of this call. Called only by the
/// LSM framework.
- pub unsafe extern "C" fn file_open(
- file: *mut bindings::file,
- ) -> core::ffi::c_int {
+ pub unsafe extern "C" fn file_open(file: *mut bindings::file) -> core::ffi::c_int {
// SAFETY: The LSM framework guarantees `file` is valid and non-null
// for the duration of this call.
let file_ref = unsafe { File::from_raw_file(file.cast_const()) };
Diff in rust/kernel/lsm.rs:190:
// SAFETY: `bindings::lsm_info` is a C struct. Zero-initialisation
// gives valid zero/null values for every optional field. The caller
// is responsible for providing a valid `id` and `init`.
- let mut info: bindings::lsm_info =
- unsafe { MaybeUninit::zeroed().assume_init() };
+ let mut info: bindings::lsm_info = unsafe { MaybeUninit::zeroed().assume_init() };
info.id = id;
info.init = init;
LsmInfo(info)
Diff in rust/kernel/lsm.rs:230:
// The LSM identity — must be 'static because the static-call
// table holds a back-pointer to it via security_hook_list.lsmid.
// LsmId wraps lsm_id with `unsafe impl Sync` so it can be `static`.
- static __LSM_ID: $crate::lsm::LsmId =
- $crate::lsm::LsmId($crate::bindings::lsm_id {
- name: $name.as_ptr().cast(),
- id: $id,
- });
+ static __LSM_ID: $crate::lsm::LsmId = $crate::lsm::LsmId($crate::bindings::lsm_id {
+ name: $name.as_ptr().cast(),
+ id: $id,
+ });
// The hook list array. MaybeUninit avoids needing security_hook_list
// to implement a const-initialiser; the C shims fill each slot in
Diff in rust/kernel/lsm.rs:242:
//
// SAFETY: This array must be 'static — the static-call table holds
// back-pointers (scall->hl) into it after registration.
- static mut __LSM_HOOKS: [
- ::core::mem::MaybeUninit<$crate::bindings::security_hook_list>;
- 3
- ] = [::core::mem::MaybeUninit::zeroed(); 3];
+ static mut __LSM_HOOKS: [::core::mem::MaybeUninit<
+ $crate::bindings::security_hook_list,
+ >; 3] = [::core::mem::MaybeUninit::zeroed(); 3];
// The init function stored in lsm_info.init. Called once by
// security_init() in single-threaded boot context.
Diff in rust/kernel/lsm.rs:283:
#[link_section = ".lsm_info.init"]
static __LSM_INFO: $crate::lsm::LsmInfo = {
// SAFETY: __LSM_ID and __lsm_init have 'static lifetime.
- unsafe {
- $crate::lsm::new_lsm_info(
- &raw const __LSM_ID.0,
- Some(__lsm_init),
- )
- }
+ unsafe { $crate::lsm::new_lsm_info(&raw const __LSM_ID.0, Some(__lsm_init)) }
};
}
};
>> Diff in rust/kernel/lsm.rs:120:
/// `file` must be a valid, non-null pointer to a `struct file` that
/// remains valid for the duration of this call. Called only by the
/// LSM framework.
- pub unsafe extern "C" fn file_open(
- file: *mut bindings::file,
- ) -> core::ffi::c_int {
+ pub unsafe extern "C" fn file_open(file: *mut bindings::file) -> core::ffi::c_int {
// SAFETY: The LSM framework guarantees `file` is valid and non-null
// for the duration of this call.
let file_ref = unsafe { File::from_raw_file(file.cast_const()) };
Diff in rust/kernel/lsm.rs:190:
// SAFETY: `bindings::lsm_info` is a C struct. Zero-initialisation
// gives valid zero/null values for every optional field. The caller
// is responsible for providing a valid `id` and `init`.
- let mut info: bindings::lsm_info =
- unsafe { MaybeUninit::zeroed().assume_init() };
+ let mut info: bindings::lsm_info = unsafe { MaybeUninit::zeroed().assume_init() };
info.id = id;
info.init = init;
LsmInfo(info)
Diff in rust/kernel/lsm.rs:230:
// The LSM identity — must be 'static because the static-call
// table holds a back-pointer to it via security_hook_list.lsmid.
// LsmId wraps lsm_id with `unsafe impl Sync` so it can be `static`.
- static __LSM_ID: $crate::lsm::LsmId =
- $crate::lsm::LsmId($crate::bindings::lsm_id {
- name: $name.as_ptr().cast(),
- id: $id,
- });
+ static __LSM_ID: $crate::lsm::LsmId = $crate::lsm::LsmId($crate::bindings::lsm_id {
+ name: $name.as_ptr().cast(),
+ id: $id,
+ });
// The hook list array. MaybeUninit avoids needing security_hook_list
// to implement a const-initialiser; the C shims fill each slot in
Diff in rust/kernel/lsm.rs:242:
//
// SAFETY: This array must be 'static — the static-call table holds
// back-pointers (scall->hl) into it after registration.
- static mut __LSM_HOOKS: [
- ::core::mem::MaybeUninit<$crate::bindings::security_hook_list>;
- 3
- ] = [::core::mem::MaybeUninit::zeroed(); 3];
+ static mut __LSM_HOOKS: [::core::mem::MaybeUninit<
+ $crate::bindings::security_hook_list,
+ >; 3] = [::core::mem::MaybeUninit::zeroed(); 3];
// The init function stored in lsm_info.init. Called once by
// security_init() in single-threaded boot context.
Diff in rust/kernel/lsm.rs:283:
#[link_section = ".lsm_info.init"]
static __LSM_INFO: $crate::lsm::LsmInfo = {
// SAFETY: __LSM_ID and __lsm_init have 'static lifetime.
- unsafe {
- $crate::lsm::new_lsm_info(
- &raw const __LSM_ID.0,
- Some(__lsm_init),
- )
- }
+ unsafe { $crate::lsm::new_lsm_info(&raw const __LSM_ID.0, Some(__lsm_init)) }
};
}
};
make[1]: Leaving directory '/kbuild/obj/consumer/x86_64-rhel-9.4-rust'
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Target 'rustfmtcheck' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2
make[2]: *** [Makefile:1912: rustfmt] Error 123
make: Target 'rustfmtcheck' not remade because of errors.
make[2]: Target 'rustfmtcheck' not remade because of errors.
make: Leaving directory '/kbuild/src/consumer'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v2 1/2] kthread: remove kthread_exit()
From: David Laight @ 2026-03-11 10:47 UTC (permalink / raw)
To: Christian Brauner
Cc: Linus Torvalds, linux-kernel, linux-modules, linux-nfs, bpf,
kunit-dev, linux-doc, linux-trace-kernel, netfs, io-uring, audit,
rcu, kvm, virtualization, netdev, linux-mm, linux-security-module,
Christian Loehle, linux-fsdevel
In-Reply-To: <20260310-work-kernel-exit-v2-1-30711759d87b@kernel.org>
On Tue, 10 Mar 2026 15:56:09 +0100
Christian Brauner <brauner@kernel.org> wrote:
> In 28aaa9c39945 ("kthread: consolidate kthread exit paths to prevent use-after-free")
> we folded kthread_exit() into do_exit() when we fixed a nasty UAF bug.
> We left kthread_exit() around as an alias to do_exit(). Remove it
> completely.
...
> -#define module_put_and_kthread_exit(code) kthread_exit(code)
> +#define module_put_and_kthread_exit(code) do_exit(code)
I'm intrigued...
How does that actually know to do the module_put()?
(I know it does one - otherwise my driver wouldn't unload.)
The corresponding try_module_get(THIS_MODULE) is done before the
kthread_run() (and has to be 'put' if that fails).
So there is an explicit 'get' but an implicit 'put'.
While a loadable module that creates a kthread usually needs to give
the kthread a reference to its module and then have that reference
released as the kthread exits, I can imagine cases where that isn't true.
(Or broken code that just hopes the module won't be unloaded just
as the kthread exits.)
It actually makes me think that module_put_and_exit() ought to have
a 'module' parameter.
Or, perhaps, kthread_create() should have the module parameter and
hold a reference to that module until it exits.
David
^ permalink raw reply
* Re: [PATCH v6] ima_fs: Correctly create securityfs files for unsupported hash algos
From: Roberto Sassu @ 2026-03-11 9:25 UTC (permalink / raw)
To: dima, Mimi Zohar, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
Paul Moore, James Morris, Serge E. Hallyn, Silvia Sisinni,
Enrico Bravi
Cc: Jonathan McDowell, linux-integrity, linux-security-module,
linux-kernel, stable, Dmitry Safonov
In-Reply-To: <20260310-ima-oob-v6-1-dc111c846ff4@arista.com>
On Tue, 2026-03-10 at 17:40 +0000, Dmitry Safonov via B4 Relay wrote:
> From: Dmitry Safonov <dima@arista.com>
>
> ima_tpm_chip->allocated_banks[i].crypto_id is initialized to
> HASH_ALGO__LAST if the TPM algorithm is not supported. However there
> are places relying on the algorithm to be valid because it is accessed
> by hash_algo_name[].
>
> On 6.12.40 I observe the following read out-of-bounds in hash_algo_name:
> ==================================================================
> BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440
> Read of size 8 at addr ffffffff83e18138 by task swapper/0/1
>
> CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3
> Call Trace:
> <TASK>
> dump_stack_lvl+0x61/0x90
> print_report+0xc4/0x580
> ? kasan_addr_to_slab+0x26/0x80
> ? create_securityfs_measurement_lists+0x396/0x440
> kasan_report+0xc2/0x100
> ? create_securityfs_measurement_lists+0x396/0x440
> create_securityfs_measurement_lists+0x396/0x440
> ima_fs_init+0xa3/0x300
> ima_init+0x7d/0xd0
> init_ima+0x28/0x100
> do_one_initcall+0xa6/0x3e0
> kernel_init_freeable+0x455/0x740
> kernel_init+0x24/0x1d0
> ret_from_fork+0x38/0x80
> ret_from_fork_asm+0x11/0x20
> </TASK>
>
> The buggy address belongs to the variable:
> hash_algo_name+0xb8/0x420
>
> Memory state around the buggy address:
> ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9
> ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9
> ^
> ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9
> ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
> ==================================================================
>
> Seems like the TPM chip supports sha3_256, which isn't yet in
> tpm_algorithms:
> tpm tpm0: TPM with unsupported bank algorithm 0x0027
>
> That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0
> Library Part 2: Structures", page 51 [1].
> See also the related U-Boot algorithms update [2].
>
> Thus solve the problem by creating a file name with "_tpm_alg_<ID>"
> postfix if the crypto algorithm isn't initialized.
>
> This is how it looks on the test machine (patch ported to v6.12 release):
> # ls -1 /sys/kernel/security/ima/
> ascii_runtime_measurements
> ascii_runtime_measurements_tpm_alg_27
> ascii_runtime_measurements_sha1
> ascii_runtime_measurements_sha256
> binary_runtime_measurements
> binary_runtime_measurements_tpm_alg_27
> binary_runtime_measurements_sha1
> binary_runtime_measurements_sha256
> policy
> runtime_measurements_count
> violations
>
> [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf
> [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html
>
> Fixes: 9fa8e7625008 ("ima: add crypto agility support for template-hash algorithm")
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> Cc: Enrico Bravi <enrico.bravi@polito.it>
> Cc: Silvia Sisinni <silvia.sisinni@polito.it>
> Cc: Roberto Sassu <roberto.sassu@huawei.com>
> Cc: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com>
Tested-by: Roberto Sassu <roberto.sassu@huawei.com>
Thanks
Roberto
> ---
> Changes in v6:
> - Change subject now that securityfs files are created (Mimi Zohar)
> - Added a link to TCG document and the related U-Boot changes
> - Link to v5: https://lore.kernel.org/r/20260223-ima-oob-v5-1-91cc1064e767@arista.com
>
> Changes in v5:
> - Use lower-case for sysfs file name (as suggested-by Jonathan and Roberto)
> - Don't use email quotes for patch description (Roberto)
> - Re-word the patch description (suggested-by Roberto)
> - Link to v4: https://lore.kernel.org/r/20260127-ima-oob-v4-1-bf0cd7f9b4d4@arista.com
>
> Changes in v4:
> - Use ima_tpm_chip->allocated_banks[algo_idx].digest_size instead of hash_digest_size[algo]
> (Roberto Sassu)
> - Link to v3: https://lore.kernel.org/r/20260127-ima-oob-v3-1-1dd09f4c2a6a@arista.com
> Testing note: I test it on v6.12.40 kernel backport, which slightly differs as
> lookup_template_data_hash_algo() was yet present.
>
> Changes in v3:
> - Now fix the spelling *for real* (sorry, messed it up in v2)
> - Link to v2: https://lore.kernel.org/r/20260127-ima-oob-v2-1-f38a18c850cf@arista.com
>
> Changes in v2:
> - Instead of skipping unknown algorithms, add files under their TPM_ALG_ID (Roberto Sassu)
> - Fix spelling (Roberto Sassu)
> - Copy @stable on the fix
> - Link to v1: https://lore.kernel.org/r/20260127-ima-oob-v1-1-2d42f3418e57@arista.com
> ---
> security/integrity/ima/ima_fs.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
> index 23d3a14b8ce3..ca4931a95098 100644
> --- a/security/integrity/ima/ima_fs.c
> +++ b/security/integrity/ima/ima_fs.c
> @@ -398,16 +398,24 @@ static int __init create_securityfs_measurement_lists(void)
> char file_name[NAME_MAX + 1];
> struct dentry *dentry;
>
> - sprintf(file_name, "ascii_runtime_measurements_%s",
> - hash_algo_name[algo]);
> + if (algo == HASH_ALGO__LAST)
> + sprintf(file_name, "ascii_runtime_measurements_tpm_alg_%x",
> + ima_tpm_chip->allocated_banks[i].alg_id);
> + else
> + sprintf(file_name, "ascii_runtime_measurements_%s",
> + hash_algo_name[algo]);
> dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
> ima_dir, (void *)(uintptr_t)i,
> &ima_ascii_measurements_ops);
> if (IS_ERR(dentry))
> return PTR_ERR(dentry);
>
> - sprintf(file_name, "binary_runtime_measurements_%s",
> - hash_algo_name[algo]);
> + if (algo == HASH_ALGO__LAST)
> + sprintf(file_name, "binary_runtime_measurements_tpm_alg_%x",
> + ima_tpm_chip->allocated_banks[i].alg_id);
> + else
> + sprintf(file_name, "binary_runtime_measurements_%s",
> + hash_algo_name[algo]);
> dentry = securityfs_create_file(file_name, S_IRUSR | S_IRGRP,
> ima_dir, (void *)(uintptr_t)i,
> &ima_measurements_ops);
>
> ---
> base-commit: 343f51842f4ed7143872f3aa116a214a5619a4b9
> change-id: 20260127-ima-oob-9fa83a634d7b
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 41/61] pinctrl: Prefer IS_ERR_OR_NULL over manual NULL check
From: Linus Walleij @ 2026-03-11 9:32 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs
In-Reply-To: <20260310-b4-is_err_or_null-v1-41-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:55 PM Philipp Hahn <phahn-oss@avm.de> wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Linus Walleij <linusw@kernel.org>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Patch applied to the pinctrl tree as obviously correct.
Yours,
Linus Walleij
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 54/61] aoe: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:26 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Justin Sanders, Jens Axboe
In-Reply-To: <20260310-b4-is_err_or_null-v1-54-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Justin Sanders <justin@coraid.com>; Jens Axboe <axboe@kernel.dk>
> Subject: [Intel-wired-lan] [PATCH 54/61] aoe: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Justin Sanders <justin@coraid.com>
> To: Jens Axboe <axboe@kernel.dk>
> Cc: linux-block@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/block/aoe/aoecmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
> index
> a4744a30a8af4ff05113f3234021eec728265b4f..b31e539a66433a0a5d6e81117a32
> d12735ffc1bc 100644
> --- a/drivers/block/aoe/aoecmd.c
> +++ b/drivers/block/aoe/aoecmd.c
> @@ -1268,7 +1268,7 @@ aoe_ktstart(struct ktstate *k)
>
> init_completion(&k->rendez);
> task = kthread_run(kthread, k, "%s", k->name);
> - if (task == NULL || IS_ERR(task))
> + if (IS_ERR_OR_NULL(task))
> return -ENOMEM;
> k->task = task;
> wait_for_completion(&k->rendez); /* allow kthread to start */
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 50/61] iommu: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:26 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Joerg Roedel, Will Deacon, Robin Murphy
In-Reply-To: <20260310-b4-is_err_or_null-v1-50-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Joerg Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>;
> Robin Murphy <robin.murphy@arm.com>
> Subject: [Intel-wired-lan] [PATCH 50/61] iommu: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Joerg Roedel <joro@8bytes.org>
> To: Will Deacon <will@kernel.org>
> To: Robin Murphy <robin.murphy@arm.com>
> Cc: iommu@lists.linux.dev
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/iommu/omap-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index
> 8231d7d6bb6a9202025643639a6b28e6faa84659..500a42b57a997696ff37c76f028a
> 717ab71d01f9 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -881,7 +881,7 @@ static int omap_iommu_attach(struct omap_iommu
> *obj, u32 *iopgd)
> **/
> static void omap_iommu_detach(struct omap_iommu *obj) {
> - if (!obj || IS_ERR(obj))
> + if (IS_ERR_OR_NULL(obj))
> return;
>
> spin_lock(&obj->iommu_lock);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 49/61] media: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:25 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab
In-Reply-To: <20260310-b4-is_err_or_null-v1-49-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; Kieran Bingham
> <kieran.bingham@ideasonboard.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>
> Subject: [Intel-wired-lan] [PATCH 49/61] media: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Shuah Khan <skhan@linuxfoundation.org>
> To: Kieran Bingham <kieran.bingham@ideasonboard.com>
> To: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: linux-media@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/media/test-drivers/vimc/vimc-streamer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/test-drivers/vimc/vimc-streamer.c
> b/drivers/media/test-drivers/vimc/vimc-streamer.c
> index
> 15d863f97cbf96b7ca7fbf3d7b6b6ec39fcc8ae3..da5aca50bcb4990c06f28e5a883e
> b398606991e9 100644
> --- a/drivers/media/test-drivers/vimc/vimc-streamer.c
> +++ b/drivers/media/test-drivers/vimc/vimc-streamer.c
> @@ -167,7 +167,7 @@ static int vimc_streamer_thread(void *data)
> for (i = stream->pipe_size - 1; i >= 0; i--) {
> frame = stream->ved_pipeline[i]->process_frame(
> stream->ved_pipeline[i], frame);
> - if (!frame || IS_ERR(frame))
> + if (IS_ERR_OR_NULL(frame))
> break;
> }
> //wait for 60hz
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 46/61] vfio: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:25 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Alex Williamson
In-Reply-To: <20260310-b4-is_err_or_null-v1-46-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Alex Williamson <alex@shazbot.org>
> Subject: [Intel-wired-lan] [PATCH 46/61] vfio: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Alex Williamson <alex@shazbot.org>
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/vfio/vfio_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c index
> 742477546b15d4dbaf9ebcfb2e67627db71521e0..d71922dfde5885967398deddec3e
> 9e04b05adfec 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -923,7 +923,7 @@ vfio_ioctl_device_feature_mig_device_state(struct
> vfio_device *device,
>
> /* Handle the VFIO_DEVICE_FEATURE_SET */
> filp = device->mig_ops->migration_set_state(device,
> mig.device_state);
> - if (IS_ERR(filp) || !filp)
> + if (IS_ERR_OR_NULL(filp))
> goto out_copy;
>
> return vfio_ioct_mig_return_fd(filp, arg, &mig);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 39/61] irqchip: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:24 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <20260310-b4-is_err_or_null-v1-39-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Marc Zyngier <maz@kernel.org>; Thomas Gleixner <tglx@kernel.org>;
> Andrew Lunn <andrew@lunn.ch>; Gregory Clement
> <gregory.clement@bootlin.com>; Sebastian Hesselbarth
> <sebastian.hesselbarth@gmail.com>
> Subject: [Intel-wired-lan] [PATCH 39/61] irqchip: Prefer
> IS_ERR_OR_NULL over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Marc Zyngier <maz@kernel.org>
> To: Thomas Gleixner <tglx@kernel.org>
> To: Andrew Lunn <andrew@lunn.ch>
> To: Gregory Clement <gregory.clement@bootlin.com>
> To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/irqchip/irq-gic-v3.c | 2 +-
> drivers/irqchip/irq-mvebu-odmi.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-
> v3.c index
> 20f13b686ab22faf722dd2b24faf96af636a4bbd..6dc9827357a21ae05dd838fb7178
> 71c73f3c7562 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -2252,7 +2252,7 @@ static int __init gic_of_init(struct device_node
> *node, struct device_node *pare
>
> out_unmap_rdist:
> for (i = 0; i < nr_redist_regions; i++)
> - if (rdist_regs[i].redist_base &&
> !IS_ERR(rdist_regs[i].redist_base))
> + if (!IS_ERR_OR_NULL(rdist_regs[i].redist_base))
> iounmap(rdist_regs[i].redist_base);
> kfree(rdist_regs);
> out_unmap_dist:
> diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-
> mvebu-odmi.c
> index
> b99ab9dcc14b3ba982876cf5525499d02bc1c997..94e7eda46e81833cfe0479b6fabb
> a715bf4ef6b8 100644
> --- a/drivers/irqchip/irq-mvebu-odmi.c
> +++ b/drivers/irqchip/irq-mvebu-odmi.c
> @@ -217,7 +217,7 @@ static int __init mvebu_odmi_init(struct
> device_node *node,
> for (i = 0; i < odmis_count; i++) {
> struct odmi_data *odmi = &odmis[i];
>
> - if (odmi->base && !IS_ERR(odmi->base))
> + if (!IS_ERR_OR_NULL(odmi->base))
> iounmap(odmis[i].base);
> }
> bitmap_free(odmis_bm);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 38/61] net: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:24 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Igor Russkikh, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Pavan Chebbi, Michael Chan,
Potnuri Bharat Teja, Nguyen, Anthony L, Kitszel, Przemyslaw,
Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Russell King
In-Reply-To: <20260310-b4-is_err_or_null-v1-38-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Igor Russkikh <irusskikh@marvell.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Pavan Chebbi <pavan.chebbi@broadcom.com>;
> Michael Chan <mchan@broadcom.com>; Potnuri Bharat Teja
> <bharat@chelsio.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Taras Chornyi
> <taras.chornyi@plvision.eu>; Maxime Coquelin
> <mcoquelin.stm32@gmail.com>; Alexandre Torgue
> <alexandre.torgue@foss.st.com>; Iyappan Subramanian
> <iyappan@os.amperecomputing.com>; Keyur Chudgar
> <keyur@os.amperecomputing.com>; Quan Nguyen
> <quan@os.amperecomputing.com>; Heiner Kallweit <hkallweit1@gmail.com>;
> Russell King <linux@armlinux.org.uk>
> Subject: [Intel-wired-lan] [PATCH 38/61] net: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Igor Russkikh <irusskikh@marvell.com>
> To: Andrew Lunn <andrew+netdev@lunn.ch>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Pavan Chebbi <pavan.chebbi@broadcom.com>
> To: Michael Chan <mchan@broadcom.com>
> To: Potnuri Bharat Teja <bharat@chelsio.com>
> To: Tony Nguyen <anthony.l.nguyen@intel.com>
> To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> To: Taras Chornyi <taras.chornyi@plvision.eu>
> To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> To: Alexandre Torgue <alexandre.torgue@foss.st.com>
> To: Iyappan Subramanian <iyappan@os.amperecomputing.com>
> To: Keyur Chudgar <keyur@os.amperecomputing.com>
> To: Quan Nguyen <quan@os.amperecomputing.com>
> To: Heiner Kallweit <hkallweit1@gmail.com>
> To: Russell King <linux@armlinux.org.uk>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 2 +-
> drivers/net/ethernet/broadcom/tg3.c | 2 +-
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 3 +--
> drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 +-
> drivers/net/ethernet/marvell/prestera/prestera_router.c | 2 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> drivers/net/mdio/mdio-xgene.c | 2 +-
> drivers/net/usb/r8152.c | 2 +-
> 8 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> index
> e270327e47fd804cc8ee5cfd53ed1b993c955c41..43edef35c4b1ff606b2f1519a07f
> ad4c9a990ad4 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> @@ -810,7 +810,7 @@ static int __aq_ring_xdp_clean(struct aq_ring_s
> *rx_ring,
> }
>
> skb = aq_xdp_run_prog(aq_nic, &xdp, rx_ring, buff);
> - if (IS_ERR(skb) || !skb)
> + if (IS_ERR_OR_NULL(skb))
> continue;
>
> if (ptp_hwtstamp_len > 0)
> diff --git a/drivers/net/ethernet/broadcom/tg3.c
> b/drivers/net/ethernet/broadcom/tg3.c
> index
> 2328fce336447eb4a796f9300ccc0ab536ff0a35..8ed79f34f03d81184dcc12e6eaff
> 009cb8f7756e 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -7943,7 +7943,7 @@ static int tg3_tso_bug(struct tg3 *tp, struct
> tg3_napi *tnapi,
>
> segs = skb_gso_segment(skb, tp->dev->features &
> ~(NETIF_F_TSO | NETIF_F_TSO6));
> - if (IS_ERR(segs) || !segs) {
> + if (IS_ERR_OR_NULL(segs)) {
> tnapi->tx_dropped++;
> goto tg3_tso_bug_end;
> }
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> index
> 3307e50426819087ad985178c4a5383f16b8e7b4..1c8a6445d4b2e3535d8f1b7908dd
> 02d8dd2f23fa 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> @@ -1032,8 +1032,7 @@ static void ch_flower_stats_handler(struct
> work_struct *work)
> do {
> rhashtable_walk_start(&iter);
>
> - while ((flower_entry = rhashtable_walk_next(&iter)) &&
> - !IS_ERR(flower_entry)) {
> + while (!IS_ERR_OR_NULL((flower_entry =
> rhashtable_walk_next(&iter))))
> +{
> ret = cxgb4_get_filter_counters(adap->port[0],
> flower_entry-
> >filter_id,
> &packets, &bytes,
> diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> index
> 6c72bd15db6d75a1d4fa04ef8fefbd26fb6e84bd..3d08b9187fd76ca3198af28111b6
> f1c1765ea01e 100644
> --- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> +++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> @@ -791,7 +791,7 @@ static void ice_traverse_tx_tree(struct devlink
> *devlink, struct ice_sched_node
> node->parent->rate_node);
> }
>
> - if (rate_node && !IS_ERR(rate_node))
> + if (!IS_ERR_OR_NULL(rate_node))
> node->rate_node = rate_node;
>
> traverse_children:
> diff --git a/drivers/net/ethernet/marvell/prestera/prestera_router.c
> b/drivers/net/ethernet/marvell/prestera/prestera_router.c
> index
> b036b173a308b5f994ad8538eb010fa27196988c..4492938e8a3da91d32efe8d45ccb
> e2eb437c0e49 100644
> --- a/drivers/net/ethernet/marvell/prestera/prestera_router.c
> +++ b/drivers/net/ethernet/marvell/prestera/prestera_router.c
> @@ -1061,7 +1061,7 @@ static void __prestera_k_arb_hw_state_upd(struct
> prestera_switch *sw,
> n = NULL;
> }
>
> - if (!IS_ERR(n) && n) {
> + if (!IS_ERR_OR_NULL(n)) {
> neigh_event_send(n, NULL);
> neigh_release(n);
> } else {
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index
> 6827c99bde8c22db42b363d2d36ad6f26075ed50..356a4e9ce04b1fcf8786d7274d31
> ace404be2cf6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1275,7 +1275,7 @@ static int stmmac_init_phy(struct net_device
> *dev)
> /* Some DT bindings do not set-up the PHY handle. Let's try to
> * manually parse it
> */
> - if (!phy_fwnode || IS_ERR(phy_fwnode)) {
> + if (IS_ERR_OR_NULL(phy_fwnode)) {
> int addr = priv->plat->phy_addr;
> struct phy_device *phydev;
>
> diff --git a/drivers/net/mdio/mdio-xgene.c b/drivers/net/mdio/mdio-
> xgene.c index
> a8f91a4b7fed0927ee14e408000cd3a2bfb9b09a..09b30b563295c6085dc1358ac361
> 301e5cf6b2a8 100644
> --- a/drivers/net/mdio/mdio-xgene.c
> +++ b/drivers/net/mdio/mdio-xgene.c
> @@ -265,7 +265,7 @@ struct phy_device *xgene_enet_phy_register(struct
> mii_bus *bus, int phy_addr)
> struct phy_device *phy_dev;
>
> phy_dev = get_phy_device(bus, phy_addr, false);
> - if (!phy_dev || IS_ERR(phy_dev))
> + if (IS_ERR_OR_NULL(phy_dev))
> return NULL;
>
> if (phy_device_register(phy_dev))
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index
> 0c83bbbea2e7c322ee6339893e281237663bd3ae..73f17ebd7d40007eec5004f887a4
> 6249defd28ab 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -2218,7 +2218,7 @@ static void r8152_csum_workaround(struct r8152
> *tp, struct sk_buff *skb,
>
> features &= ~(NETIF_F_SG | NETIF_F_IPV6_CSUM |
> NETIF_F_TSO6);
> segs = skb_gso_segment(skb, features);
> - if (IS_ERR(segs) || !segs)
> + if (IS_ERR_OR_NULL(segs))
> goto drop;
>
> __skb_queue_head_init(&seg_list);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 30/61] net/sunrpc: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:22 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
In-Reply-To: <20260310-b4-is_err_or_null-v1-30-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Trond Myklebust <trondmy@kernel.org>; Anna Schumaker
> <anna@kernel.org>; Chuck Lever <chuck.lever@oracle.com>; Jeff Layton
> <jlayton@kernel.org>; NeilBrown <neil@brown.name>; Olga Kornievskaia
> <okorniev@redhat.com>; Dai Ngo <Dai.Ngo@oracle.com>; Tom Talpey
> <tom@talpey.com>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>
> Subject: [Intel-wired-lan] [PATCH 30/61] net/sunrpc: Prefer
> IS_ERR_OR_NULL over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Trond Myklebust <trondmy@kernel.org>
> To: Anna Schumaker <anna@kernel.org>
> To: Chuck Lever <chuck.lever@oracle.com>
> To: Jeff Layton <jlayton@kernel.org>
> To: NeilBrown <neil@brown.name>
> To: Olga Kornievskaia <okorniev@redhat.com>
> To: Dai Ngo <Dai.Ngo@oracle.com>
> To: Tom Talpey <tom@talpey.com>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Simon Horman <horms@kernel.org>
> Cc: linux-nfs@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index
> 9b623849723ed0eb74b827881c6f32d3434c891b..b4d03e59a8202f20360cff1e2e79
> b1e325396517 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -578,7 +578,7 @@ static struct svc_xprt *svc_rdma_accept(struct
> svc_xprt *xprt)
> errout:
> /* Take a reference in case the DTO handler runs */
> svc_xprt_get(&newxprt->sc_xprt);
> - if (newxprt->sc_qp && !IS_ERR(newxprt->sc_qp))
> + if (!IS_ERR_OR_NULL(newxprt->sc_qp))
> ib_destroy_qp(newxprt->sc_qp);
> rdma_destroy_id(newxprt->sc_cm_id);
> rpcrdma_rn_unregister(dev, &newxprt->sc_rn); @@ -608,7 +608,7
> @@ static void svc_rdma_free(struct svc_xprt *xprt)
> might_sleep();
>
> /* This blocks until the Completion Queues are empty */
> - if (rdma->sc_qp && !IS_ERR(rdma->sc_qp))
> + if (!IS_ERR_OR_NULL(rdma->sc_qp))
> ib_drain_qp(rdma->sc_qp);
> flush_workqueue(svcrdma_wq);
>
> @@ -619,16 +619,16 @@ static void svc_rdma_free(struct svc_xprt *xprt)
> svc_rdma_recv_ctxts_destroy(rdma);
>
> /* Destroy the QP if present (not a listener) */
> - if (rdma->sc_qp && !IS_ERR(rdma->sc_qp))
> + if (!IS_ERR_OR_NULL(rdma->sc_qp))
> ib_destroy_qp(rdma->sc_qp);
>
> - if (rdma->sc_sq_cq && !IS_ERR(rdma->sc_sq_cq))
> + if (!IS_ERR_OR_NULL(rdma->sc_sq_cq))
> ib_free_cq(rdma->sc_sq_cq);
>
> - if (rdma->sc_rq_cq && !IS_ERR(rdma->sc_rq_cq))
> + if (!IS_ERR_OR_NULL(rdma->sc_rq_cq))
> ib_free_cq(rdma->sc_rq_cq);
>
> - if (rdma->sc_pd && !IS_ERR(rdma->sc_pd))
> + if (!IS_ERR_OR_NULL(rdma->sc_pd))
> ib_dealloc_pd(rdma->sc_pd);
>
> /* Destroy the CM ID */
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 28/61] net/sched: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:22 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Hadi Salim, Jamal, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
In-Reply-To: <20260310-b4-is_err_or_null-v1-28-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Hadi Salim, Jamal <jhs@mojatatu.com>; Jiri Pirko
> <jiri@resnulli.us>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Simon Horman <horms@kernel.org>
> Subject: [Intel-wired-lan] [PATCH 28/61] net/sched: Prefer
> IS_ERR_OR_NULL over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Jamal Hadi Salim <jhs@mojatatu.com>
> To: Jiri Pirko <jiri@resnulli.us>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Simon Horman <horms@kernel.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> net/sched/cls_api.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c index
> 4829c27446e3369ad2ae9b3fcb285eca47d59933..4208225e7a4acaf0c331096ebf94
> 1f68cc2ed992 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -2444,7 +2444,7 @@ static int tc_new_tfilter(struct sk_buff *skb,
> struct nlmsghdr *n,
> tcf_chain_tp_delete_empty(chain, tp, rtnl_held, NULL);
> errout_tp:
> if (chain) {
> - if (tp && !IS_ERR(tp))
> + if (!IS_ERR_OR_NULL(tp))
> tcf_proto_put(tp, rtnl_held, NULL);
> if (!tp_created)
> tcf_chain_put(chain);
> @@ -2612,7 +2612,7 @@ static int tc_del_tfilter(struct sk_buff *skb,
> struct nlmsghdr *n,
>
> errout:
> if (chain) {
> - if (tp && !IS_ERR(tp))
> + if (!IS_ERR_OR_NULL(tp))
> tcf_proto_put(tp, rtnl_held, NULL);
> tcf_chain_put(chain);
> }
> @@ -2741,7 +2741,7 @@ static int tc_get_tfilter(struct sk_buff *skb,
> struct nlmsghdr *n,
> tfilter_put(tp, fh);
> errout:
> if (chain) {
> - if (tp && !IS_ERR(tp))
> + if (!IS_ERR_OR_NULL(tp))
> tcf_proto_put(tp, rtnl_held, NULL);
> tcf_chain_put(chain);
> }
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 25/61] net/bluetooth: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:21 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz
In-Reply-To: <20260310-b4-is_err_or_null-v1-25-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Marcel Holtmann <marcel@holtmann.org>; Johan Hedberg
> <johan.hedberg@gmail.com>; Luiz Augusto von Dentz
> <luiz.dentz@gmail.com>
> Subject: [Intel-wired-lan] [PATCH 25/61] net/bluetooth: Prefer
> IS_ERR_OR_NULL over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Marcel Holtmann <marcel@holtmann.org>
> To: Johan Hedberg <johan.hedberg@gmail.com>
> To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> Cc: linux-bluetooth@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> net/bluetooth/mgmt.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index
> a7238fd3b03bb54f39af1afee74dc1acd931c324..06d2da67bbe14e17ee478aa939de
> 26526c333d91 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -4169,7 +4169,7 @@ static void set_default_phy_complete(struct
> hci_dev *hdev, void *data, int err)
> mgmt_phy_configuration_changed(hdev, cmd->sk);
> }
>
> - if (skb && !IS_ERR(skb))
> + if (!IS_ERR_OR_NULL(skb))
> kfree_skb(skb);
>
> mgmt_pending_free(cmd);
> @@ -5730,7 +5730,7 @@ static void read_local_oob_data_complete(struct
> hci_dev *hdev, void *data,
> MGMT_STATUS_SUCCESS, &mgmt_rp, rp_size);
>
> remove:
> - if (skb && !IS_ERR(skb))
> + if (!IS_ERR_OR_NULL(skb))
> kfree_skb(skb);
>
> mgmt_pending_free(cmd);
> @@ -8277,7 +8277,7 @@ static void
> read_local_oob_ext_data_complete(struct hci_dev *hdev, void *data,
> mgmt_rp, sizeof(*mgmt_rp) + eir_len,
> HCI_MGMT_OOB_DATA_EVENTS, cmd->sk);
> done:
> - if (skb && !IS_ERR(skb))
> + if (!IS_ERR_OR_NULL(skb))
> kfree_skb(skb);
>
> kfree(mgmt_rp);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 24/61] net/9p: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:19 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
In-Reply-To: <20260310-b4-is_err_or_null-v1-24-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Eric Van Hensbergen <ericvh@kernel.org>; Latchesar Ionkov
> <lucho@ionkov.net>; Dominique Martinet <asmadeus@codewreck.org>;
> Christian Schoenebeck <linux_oss@crudebyte.com>; David S. Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Simon
> Horman <horms@kernel.org>
> Subject: [Intel-wired-lan] [PATCH 24/61] net/9p: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Eric Van Hensbergen <ericvh@kernel.org>
> To: Latchesar Ionkov <lucho@ionkov.net>
> To: Dominique Martinet <asmadeus@codewreck.org>
> To: Christian Schoenebeck <linux_oss@crudebyte.com>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Simon Horman <horms@kernel.org>
> Cc: v9fs@lists.linux.dev
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> include/net/9p/client.h | 2 +-
> net/9p/trans_rdma.c | 8 ++++----
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/9p/client.h b/include/net/9p/client.h index
> 838a94218b593f3fb19e6827c472753380193461..4bde6bd716f323c819745e64c7aa
> c0dea7beb72f 100644
> --- a/include/net/9p/client.h
> +++ b/include/net/9p/client.h
> @@ -364,7 +364,7 @@ static inline struct p9_fid *p9_fid_get(struct
> p9_fid *fid)
>
> static inline int p9_fid_put(struct p9_fid *fid) {
> - if (!fid || IS_ERR(fid))
> + if (IS_ERR_OR_NULL(fid))
> return 0;
>
> if (tracepoint_enabled(9p_fid_ref))
> diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c index
> aa5bd74d333f3b5e6fd1e4344d26bc0201ff7f7f..60461344b536bcb6e94112aace75
> a88b6a99ad86 100644
> --- a/net/9p/trans_rdma.c
> +++ b/net/9p/trans_rdma.c
> @@ -252,16 +252,16 @@ static void rdma_destroy_trans(struct
> p9_trans_rdma *rdma)
> if (!rdma)
> return;
>
> - if (rdma->qp && !IS_ERR(rdma->qp))
> + if (!IS_ERR_OR_NULL(rdma->qp))
> ib_destroy_qp(rdma->qp);
>
> - if (rdma->pd && !IS_ERR(rdma->pd))
> + if (!IS_ERR_OR_NULL(rdma->pd))
> ib_dealloc_pd(rdma->pd);
>
> - if (rdma->cq && !IS_ERR(rdma->cq))
> + if (!IS_ERR_OR_NULL(rdma->cq))
> ib_free_cq(rdma->cq);
>
> - if (rdma->cm_id && !IS_ERR(rdma->cm_id))
> + if (!IS_ERR_OR_NULL(rdma->cm_id))
> rdma_destroy_id(rdma->cm_id);
>
> kfree(rdma);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox