* [PATCH v2 0/3] Bring includes in linux/kmod.h up to date
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
The usermode helper declarations were previously provided by linux/kmod.h
but commit c1f3fa2a4fde ("kmod: split off umh headers into its own file")
moved them to linux/umh.h in 2017. Add explicit includes of linux/umh.h to
files that use usermode helpers and remove linux/kmod.h where it is no
longer needed.
Also add a missing include of linux/sysctl.h to kernel/time/jiffies.c.
Finally, clean up linux/kmod.h so that it includes only the headers that it
actually requires, importantly removing the compat linux/umh.h include.
This cleanup is motivated by trying to reduce the preprocessed size of
linux/module.h, which includes linux/kmod.h. The linux/module.h header is
included by every *.mod.c file to provide `struct module` and other related
definitions, so it should avoid pulling in unnecessary dependencies. Note
that this series doesn't immediately improve the situation, since most of
the files included by linux/kmod.h are, for now, also included by
linux/module.h through other paths.
Apologies for the wide distribution. Acked-bys are appreciated.
Changes in v2:
- Remove the linux/kmod.h include from kernel/cgroup/cgroup-v1.c.
- Add a missing include of linux/sysctl.h to kernel/time/jiffies.c.
- Link to v1: https://lore.kernel.org/linux-modules/20260708154510.6794-1-petr.pavlu@suse.com/
Petr Pavlu (3):
umh, treewide: Explicitly include linux/umh.h where needed
time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
module: Bring includes in linux/kmod.h up to date
arch/x86/kernel/cpu/mce/dev-mcelog.c | 2 +-
drivers/block/drbd/drbd_nl.c | 1 +
drivers/greybus/svc_watchdog.c | 1 +
drivers/macintosh/windfarm_core.c | 1 +
drivers/pnp/pnpbios/core.c | 2 +-
drivers/video/fbdev/uvesafb.c | 1 +
fs/coredump.c | 2 +-
fs/nfs/cache_lib.c | 2 +-
fs/nfsd/nfs4layouts.c | 2 +-
fs/nfsd/nfs4recover.c | 1 +
fs/ocfs2/stackglue.c | 1 +
include/linux/kmod.h | 12 ++----------
kernel/cgroup/cgroup-v1.c | 2 +-
kernel/module/kmod.c | 1 +
kernel/power/process.c | 2 +-
kernel/reboot.c | 2 +-
kernel/time/jiffies.c | 1 +
kernel/umh.c | 2 +-
lib/kobject_uevent.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
security/keys/request_key.c | 2 +-
security/tomoyo/common.h | 2 +-
22 files changed, 23 insertions(+), 23 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/3] umh, treewide: Explicitly include linux/umh.h where needed
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
The usermode helper declarations were previously provided by linux/kmod.h
but commit c1f3fa2a4fde ("kmod: split off umh headers into its own file")
moved them to linux/umh.h in 2017. Add explicit includes of linux/umh.h to
files that use usermode helpers and remove linux/kmod.h where it is no
longer needed.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
arch/x86/kernel/cpu/mce/dev-mcelog.c | 2 +-
drivers/block/drbd/drbd_nl.c | 1 +
drivers/greybus/svc_watchdog.c | 1 +
drivers/macintosh/windfarm_core.c | 1 +
drivers/pnp/pnpbios/core.c | 2 +-
drivers/video/fbdev/uvesafb.c | 1 +
fs/coredump.c | 2 +-
fs/nfs/cache_lib.c | 2 +-
fs/nfsd/nfs4layouts.c | 2 +-
fs/nfsd/nfs4recover.c | 1 +
fs/ocfs2/stackglue.c | 1 +
kernel/cgroup/cgroup-v1.c | 2 +-
kernel/module/kmod.c | 1 +
kernel/power/process.c | 2 +-
kernel/reboot.c | 2 +-
kernel/umh.c | 2 +-
lib/kobject_uevent.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
security/keys/request_key.c | 2 +-
security/tomoyo/common.h | 2 +-
20 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
index 053555206d81..af4e76babe7a 100644
--- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
+++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
@@ -11,7 +11,7 @@
#include <linux/miscdevice.h>
#include <linux/slab.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/poll.h>
#include "internal.h"
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index f9ffcd67607b..de90cf4a0789 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/module.h>
+#include <linux/umh.h>
#include <linux/drbd.h>
#include <linux/in.h>
#include <linux/fs.h>
diff --git a/drivers/greybus/svc_watchdog.c b/drivers/greybus/svc_watchdog.c
index 16e6de5e9eff..b318eb34bcca 100644
--- a/drivers/greybus/svc_watchdog.c
+++ b/drivers/greybus/svc_watchdog.c
@@ -7,6 +7,7 @@
#include <linux/delay.h>
#include <linux/suspend.h>
+#include <linux/umh.h>
#include <linux/workqueue.h>
#include <linux/greybus.h>
diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
index 5307b1e34261..e66de11c69a3 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -34,6 +34,7 @@
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/freezer.h>
+#include <linux/umh.h>
#include "windfarm.h"
diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index f7e86ae9f72f..46af1f549337 100644
--- a/drivers/pnp/pnpbios/core.c
+++ b/drivers/pnp/pnpbios/core.c
@@ -47,7 +47,7 @@
#include <linux/delay.h>
#include <linux/acpi.h>
#include <linux/freezer.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/kthread.h>
#include <asm/page.h>
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 9d82326c744f..6c503e6914d6 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -23,6 +23,7 @@
#include <linux/io.h>
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/umh.h>
#include <video/edid.h>
#include <video/uvesafb.h>
#ifdef CONFIG_X86
diff --git a/fs/coredump.c b/fs/coredump.c
index e68a76ff92a3..4908b44f6fdc 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -32,7 +32,7 @@
#include <linux/tsacct_kern.h>
#include <linux/cn_proc.h>
#include <linux/audit.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/fsnotify.h>
#include <linux/fs_struct.h>
#include <linux/pipe_fs_i.h>
diff --git a/fs/nfs/cache_lib.c b/fs/nfs/cache_lib.c
index 9738a1ae92ca..ca4e81d4e315 100644
--- a/fs/nfs/cache_lib.c
+++ b/fs/nfs/cache_lib.c
@@ -6,7 +6,7 @@
*
* Copyright (c) 2009 Trond Myklebust <Trond.Myklebust@netapp.com>
*/
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/mount.h>
diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
index f34320e4c2f4..008f0f088c3a 100644
--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@ -3,7 +3,7 @@
* Copyright (c) 2014 Christoph Hellwig.
*/
#include <linux/exportfs_block.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/file.h>
#include <linux/jhash.h>
#include <linux/sched.h>
diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 6ea25a52d2f4..20b98e43f668 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -41,6 +41,7 @@
#include <linux/fs.h>
#include <linux/hex.h>
#include <linux/module.h>
+#include <linux/umh.h>
#include <net/net_namespace.h>
#include <linux/sunrpc/rpc_pipe_fs.h>
#include <linux/sunrpc/clnt.h>
diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 741d6191d871..0ccaab29426d 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -18,6 +18,7 @@
#include <linux/kobject.h>
#include <linux/sysfs.h>
#include <linux/sysctl.h>
+#include <linux/umh.h>
#include "ocfs2_fs.h"
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index a4337c9b5287..cbcde5c28b18 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -2,7 +2,7 @@
#include "cgroup-internal.h"
#include <linux/ctype.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/sort.h>
#include <linux/delay.h>
#include <linux/mm.h>
diff --git a/kernel/module/kmod.c b/kernel/module/kmod.c
index a25dccdf7aa7..dcaad5d65275 100644
--- a/kernel/module/kmod.c
+++ b/kernel/module/kmod.c
@@ -28,6 +28,7 @@
#include <linux/ptrace.h>
#include <linux/async.h>
#include <linux/uaccess.h>
+#include <linux/umh.h>
#include <trace/events/module.h>
#include "internal.h"
diff --git a/kernel/power/process.c b/kernel/power/process.c
index dc0dfc349f22..295904ec9a82 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -16,7 +16,7 @@
#include <linux/freezer.h>
#include <linux/delay.h>
#include <linux/workqueue.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <trace/events/power.h>
#include <linux/cpuset.h>
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 695c33e75efd..3d4a262973e7 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -11,13 +11,13 @@
#include <linux/ctype.h>
#include <linux/export.h>
#include <linux/kexec.h>
-#include <linux/kmod.h>
#include <linux/kmsg_dump.h>
#include <linux/reboot.h>
#include <linux/suspend.h>
#include <linux/syscalls.h>
#include <linux/syscore_ops.h>
#include <linux/uaccess.h>
+#include <linux/umh.h>
/*
* this indicates whether you can reboot with ctrl-alt-del: the default is yes
diff --git a/kernel/umh.c b/kernel/umh.c
index 48117c569e1a..72b2d9a878aa 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -8,7 +8,7 @@
#include <linux/binfmts.h>
#include <linux/syscalls.h>
#include <linux/unistd.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/slab.h>
#include <linux/completion.h>
#include <linux/cred.h>
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index ddbc4d7482d2..a67129e452a3 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -17,7 +17,7 @@
#include <linux/string.h>
#include <linux/kobject.h>
#include <linux/export.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/slab.h>
#include <linux/socket.h>
#include <linux/skbuff.h>
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index a7e5422eb5d1..89bc161a4b47 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -8,7 +8,7 @@
*/
#include <linux/kernel.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/etherdevice.h>
#include <linux/rtnetlink.h>
#include <net/switchdev.h>
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index fa2bb9f2f538..e6ba2d054399 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -9,7 +9,7 @@
#include <linux/export.h>
#include <linux/sched.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/err.h>
#include <linux/keyctl.h>
#include <linux/slab.h>
diff --git a/security/tomoyo/common.h b/security/tomoyo/common.h
index d098cf8aae61..d26034000913 100644
--- a/security/tomoyo/common.h
+++ b/security/tomoyo/common.h
@@ -16,7 +16,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/file.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/fs.h>
#include <linux/sched.h>
#include <linux/namei.h>
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/3] time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
The kernel/time/jiffies.c file uses proc_int_u2k_conv_uop(),
proc_int_k2u_conv_kop(), proc_int_conv(), proc_dointvec_conv() and
proc_doulongvec_minmax_conv(), which are declared in linux/sysctl.h. It
currently relies on this header being included indirectly through
linux/module.h -> linux/kmod.h. Add the missing include in preparation for
removing the linux/sysctl.h include from linux/kmod.h.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
kernel/time/jiffies.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index d51428867a33..17cdb5ef8893 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -8,6 +8,7 @@
#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/init.h>
+#include <linux/sysctl.h>
#include "timekeeping.h"
#include "tick-internal.h"
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/3] module: Bring includes in linux/kmod.h up to date
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
Including linux/kmod.h alone results in 1.5 MB of preprocessed output, even
though it provides only a few functions and macros.
The header currently depends on:
* __printf() -> linux/compiler_attributes.h,
* ENOSYS -> linux/errno.h,
* bool -> linux/types.h.
Include only these files, reducing the preprocessed output to 10 kB.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
---
include/linux/kmod.h | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index 9a07c3215389..b9474a62a568 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -2,17 +2,9 @@
#ifndef __LINUX_KMOD_H__
#define __LINUX_KMOD_H__
-/*
- * include/linux/kmod.h
- */
-
-#include <linux/umh.h>
-#include <linux/gfp.h>
-#include <linux/stddef.h>
+#include <linux/compiler_attributes.h>
#include <linux/errno.h>
-#include <linux/compiler.h>
-#include <linux/workqueue.h>
-#include <linux/sysctl.h>
+#include <linux/types.h>
#ifdef CONFIG_MODULES
/* modprobe exit status on success, -ve on error. Return value
--
2.54.0
^ permalink raw reply related
* [PATCH net v3] sctp: don't free the ASCONF's own transport in DEL-IP processing
From: Jun Yang @ 2026-07-21 13:14 UTC (permalink / raw)
To: netdev
Cc: Marcelo Ricardo Leitner, Xin Long, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-sctp,
linux-kernel, Jun Yang, stable
From: Jun Yang <junvyyang@tencent.com>
sctp_process_asconf() caches the transport the ASCONF chunk is processed
against in asconf->transport (== chunk->transport, set once in sctp_rcv()).
For an ASCONF located through its Address Parameter by
__sctp_rcv_asconf_lookup(), that cached transport corresponds to the
Address Parameter, which need not be the packet's source address.
sctp_process_asconf_param() rejects a DEL-IP for the packet source address
(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport.
A single ASCONF can therefore carry, in order:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
where L differs from the source. The DEL-IP for L passes the D8 check and
calls sctp_assoc_rm_peer() on the transport that asconf->transport still
points at, freeing it (RCU-deferred). The following wildcard DEL-IP then
reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and
sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed
transport (->ipaddr, ->state) and plants the dangling pointer into
asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping
only the pointer that is no longer on the list, removes every real
transport, leaving the association with a transport_count of 0 and
primary_path/active_path pointing at freed memory.
Reject a DEL-IP that targets the transport the ASCONF is being processed
against, mirroring the existing source-address guard, so the wildcard
branch can never reuse a freed transport.
Fixes: 42e30bf3463c ("[SCTP]: Handle the wildcard ADD-IP Address parameter")
Cc: stable@kernel.org
Signed-off-by: Jun Yang <junvyyang@tencent.com>
Acked-by: Xin Long <lucien.xin@gmail.com>
---
v3: return Request Refused instead of Request to Delete Source IP Address,
as the protected transport need not be the packet's source address.
v2: add [net] subject prefix to target the net tree.
net/sctp/sm_make_chunk.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 8adac9e0cd66..b14251214896 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3153,6 +3153,12 @@ static __be16 sctp_process_asconf_param(struct sctp_association *asoc,
if (!peer)
return SCTP_ERROR_DNS_FAILED;
+ /* Don't free asconf->transport; a later wildcard DEL-IP
+ * parameter reuses it.
+ */
+ if (peer == asconf->transport)
+ return SCTP_ERROR_REQ_REFUSED;
+
sctp_assoc_rm_peer(asoc, peer);
break;
case SCTP_PARAM_SET_PRIMARY:
--
2.55.0
^ permalink raw reply related
* Re: [PATCH v3 0/9] pci: fix UAF and TOCTOU related to dynamic ID
From: Gary Guo @ 2026-07-21 13:17 UTC (permalink / raw)
To: Bjorn Helgaas, Zhenzhong Duan, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Damien Le Moal,
Niklas Cassel, GOTO Masanori, YOKOTA Hiroshi,
James E.J. Bottomley, Martin K. Petersen, Vaibhav Gupta,
Jens Taprogge, Ido Schimmel, Petr Machata, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Airlie
Cc: linux-pci, driver-core, linux-kernel, linux-ide, linux-scsi,
industrypack-devel, netdev, dri-devel, Sashiko
In-Reply-To: <20260706-pci_id_fix-v3-0-2d48fc025acc@garyguo.net>
On Mon Jul 6, 2026 at 3:11 PM BST, Gary Guo wrote:
> While working on improving the Rust abstractions [1], Sashiko reported that
> an existing UAF issue related to dynamic ID, which I find to be genuine.
> When taking a look at the code I also find a TOCTOU issue where the
> existence check of dynamic ID happens in a separate critical section as the
> actual insertion. This series fix both issues.
>
> There are two exported functions "pci_match_id" and "pci_add_dynid" which I
> have to tweak to implement this cleanly; I created separate "do_xxx"
> functions to keep the existing APIs because they all have multiple users.
>
> There're a few existing users which stores their pci_device_id argument in
> probe callback. This is a bad pattern because nothing except driver_data
> inside pci_device_id is what they want; actual ID information can be
> retrieved from pci_dev instead.
>
> There are two users that performs pointer arithmetic on the pci_device_id;
> these are also problematic with dynamic ID and driver_override, so fix them
> as well.
>
> I've used the following coccinelle script to flag all cases where the
> pci_device_id is used other than reading its fields.
Hi Bjorn,
Could you take a look at the series?
For reference, this series is the USB equivalent which is already applied:
https://lore.kernel.org/driver-core/20260707-usb_dyn_id_uaf-v2-0-632dcf3adfba@garyguo.net/
Thanks,
Gary
>
> @usage@
> identifier fn, id;
> position p;
> @@
> fn(..., struct pci_device_id *id, ...)
> {
> ...
> id@p
> ...
> }
>
> // Due to cocci isomorphism this needs to be explicit
> @bad@
> identifier fn, id;
> type T;
> position usage.p;
> @@
> fn(..., struct pci_device_id *id, ...)
> {
> ...
> (T*)id@p
> ...
> }
>
> // Good use cases
> @good@
> identifier fn, id, fld;
> expression E;
> position usage.p;
> @@
> fn(..., struct pci_device_id *id, ...)
> {
> ...
> (
> id@p->fld
> |
> E(..., id@p, ...)
> |
> // Redundant checks, but ignore
> !id@p
> |
> // Redundant checks, but ignorehttps://lore.kernel.org/driver-core/20260707-usb_dyn_id_uaf-v2-0-632dcf3adfba@garyguo.net/
> id ? ... : ...
> )
> ...
> }
>
> @script:python depends on usage && (bad || !good)@
> p << usage.p;
> @@
> coccilib.report.print_report(p[0], "suspicious use of pci_device_id")
>
> Link: https://lore.kernel.org/all/20260618-id_info-v1-0-96af1e559ef9@garyguo.net/ [1]
> Link: https://lore.kernel.org/all/20260619170503.518F61F00A3A@smtp.kernel.org/ [2]
>
> ---
> Changes in v3:
> - Fix users which uses pci_device_id for pointer arithmetic. (Sashiko)
> - Convert to scoped_guard. (Danilo)
> - For static IDs, still give out static pointers and avoid making a copy.
> - Link to v2: https://patch.msgid.link/20260630-pci_id_fix-v2-0-b834a98c0af2@garyguo.net
>
> Changes in v2:
> - Fix users which store pci_device_id.
> - Clarify in probe documentation about the lifetime of pci_device_id
> parameter.
> - Dynamic ID conflict check now ignores override_only. (Sashiko)
> - Link to v1: https://patch.msgid.link/20260626-pci_id_fix-v1-0-a35c803f1b95@garyguo.net
>
> ---
> Gary Guo (9):
> ata: don't store pci_device_id
> nsp32: don't store pci_device_id
> ipack: tpci200: don't store pci_device_id
> mlxsw: don't store pci_device_id
> agp/via: don't rely on address of pci_device_id
> agp/amd-k7: don't rely on address of pci_device_id
> pci: make pci_match_one_device match on ID instead of device
> pci: fix dyn_id add TOCTOU
> pci: fix UAF when probe runs concurrent to dyn ID removal
>
> drivers/ata/ata_generic.c | 6 +-
> drivers/char/agp/amd-k7-agp.c | 26 +--
> drivers/char/agp/via-agp.c | 308 +++++++-----------------------
> drivers/ipack/carriers/tpci200.c | 1 -
> drivers/ipack/carriers/tpci200.h | 1 -
> drivers/net/ethernet/mellanox/mlxsw/pci.c | 11 +-
> drivers/pci/pci-driver.c | 193 ++++++++++---------
> drivers/pci/pci.h | 36 +++-
> drivers/pci/search.c | 6 +-
> drivers/scsi/nsp32.c | 8 +-
> drivers/scsi/nsp32.h | 8 +-
> include/linux/pci.h | 1 +
> 12 files changed, 230 insertions(+), 375 deletions(-)
> ---
> base-commit: 2b763db0c2763d6bf73d7d3e69665222d1f377cf
> change-id: 20260626-pci_id_fix-83eaec007674
>
> Best regards,
> --
> Gary Guo <gary@garyguo.net>
^ permalink raw reply
* Re: [PATCH net-next v7 08/15] net: ethernet: oa_tc6: Support for hardware timestamp
From: Paolo Abeni @ 2026-07-21 13:17 UTC (permalink / raw)
To: Selvamani.Rajagopal
Cc: andrew, pier.beruto, hkallweit1, linux, davem, edumazet, kuba,
pabeni, andrew+netdev, parthiban.veerasooran, selvamani.rajagopal,
richardcochran, robh, krzk+dt, conor+dt, horms, corbet, skhan,
netdev, linux-kernel, devicetree, linux-doc, jerry.ray
In-Reply-To: <20260708-s2500-mac-phy-support-v7-8-478c877aa1a9@onsemi.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
net: ethernet: oa_tc6: Support for hardware timestamp
This adds hardware timestamping support to the OA TC6 MAC-PHY framework,
splitting PTP registration and hwtstamp helpers into new oa_tc6_ptp.c and
oa_tc6_tstamp.c files, and wiring TSC handling into the TX and RX chunk
paths.
Thanks for the patch; a few questions inline.
> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6.c b/drivers/net/ethernet/oa_tc6/oa_tc6.c
> index bf96e8d1ccb9..939935cb170d 100644
> --- a/drivers/net/ethernet/oa_tc6/oa_tc6.c
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6.c
[ ... ]
> +static void oa_tc6_defer_for_hwtstamp(struct oa_tc6 *tc6,
> + struct sk_buff *skb)
> +{
> + if (!tc6->hw_tstamp_enabled)
> + return;
> + if (!skb || (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) == 0)
> + return;
> + if (tc6->ts_config.tx_type != HWTSTAMP_TX_ON) {
> + tc6->tx_hwtstamp_lost++;
> + return;
> + }
> +
> + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
> + u8 ret = tc6->tx_ts_idx++;
> +
> + if (ret == OA_TC6_TTSCC_REG_ID)
> + tc6->tx_ts_idx = OA_TC6_TTSCA_REG_ID;
> + oa_tc6_tsinfo_tx(skb)->tsc = ret;
> +
> + list_add_tail(&skb->list, &tc6->tx_ts_skb_q);
> +}
[High]
The hardware exposes three timestamp capture slots (TTSCA, TTSCB, TTSCC),
but tx_ts_idx cycles through them unconditionally, with no check that
the previous capture in a given slot has already been drained by the
TTSCA/B/C completion IRQ.
When tx_credits allows more than three timestamped skbs to be pipelined,
the same tsc value is assigned to two skbs. The earlier skb's TTSCx
register is then overwritten by the later capture before
oa_tc6_process_deferred_skb() reads it, and two skbs end up on
tx_ts_skb_q with an identical tsc.
Should this scheme track per-slot in-use state and either back-pressure
or fall back to software timestamping when all three slots are pending?
[High]
tc6->hw_tstamp_enabled and tc6->ts_config are written from the ioctl
path through oa_tc6_hwtstamp_set()->oa_tc6_set_hwtstamp_settings() and
read here on the threaded IRQ path with no lock, RCU, WRITE_ONCE, or
memory barrier. Is there some serialization not visible here?
On the disable path, oa_tc6_set_hwtstamp_settings() programs the
hardware first and only afterwards clears hw_tstamp_enabled. Can this
happen:
CPU0 (ioctl disable) CPU1 (threaded IRQ)
write CONFIG0 (clear FTSE)
write INT_MASK0 (mask TTSCA)
if (!tc6->hw_tstamp_enabled) /* still true */
...
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
list_add_tail(&skb->list, &tc6->tx_ts_skb_q);
tc6->hw_tstamp_enabled = false;
At that point the TTSCA/B/C interrupts are already masked, so
oa_tc6_process_deferred_skb() will never run for that tsc; the skb is
stuck on tx_ts_skb_q, and because SKBTX_IN_PROGRESS was set the socket
TX completion is also blocked.
Would a mutex around the reconfiguration (plus draining tx_ts_skb_q)
be more appropriate than the plain flag read?
> +static int oa_tc6_process_deferred_skb(struct oa_tc6 *tc6, u8 tsc)
> +{
> + struct skb_shared_hwtstamps tstamp;
> + struct oa_tc6_ts_info_tx *ski;
> + struct sk_buff *skb, *tmp;
> + bool found = false;
> + int ret = 0;
> +
> + /* Size of data must match OA_TC6_TSTAMP_SZ */
> + u32 data[2];
> +
> + list_for_each_entry_safe(skb, tmp, &tc6->tx_ts_skb_q, list) {
> + ski = oa_tc6_tsinfo_tx(skb);
> + if (ski->tsc != tsc)
> + continue;
> + if (found) {
> + dev_warn_ratelimited(&tc6->spi->dev,
> + "Multiple skbs. tsc = %d\n",
> + tsc);
> + tc6->tx_hwtstamp_err++;
> + }
> + found = true;
> + list_del(&skb->list);
> +
> + /* Retrieve the timestamping info */
> + ret = oa_tc6_read_registers(tc6,
> + OA_TC6_REG_TTSCA_HIGH +
> + 2 * (tsc - 1), &data[0], 2);
> +
> + if (!ret) {
> + tstamp.hwtstamp = ktime_set(data[0], data[1]);
> + skb_tstamp_tx(skb, &tstamp);
> + tc6->tx_hwtstamp_pkts++;
> + }
> +
> + dev_kfree_skb(skb);
> + }
> + return ret;
> +}
[Medium]
When more than one skb matches the same tsc, this loop still calls
skb_tstamp_tx() with the identical hardware timestamp for every match
and increments tx_hwtstamp_pkts on each.
Should only the first match report a timestamp, with the remaining
matches freed as errors and neither reporting a bogus duplicate to
userspace nor inflating tx_hwtstamp_pkts?
> +static void oa_tc6_update_ts_in_rx_skb(struct oa_tc6 *tc6)
> +{
> + struct sk_buff *skb = tc6->rx_skb;
> + struct oa_tc6_ts_info_rx *ski;
> + __be32 ts_val[2];
> + u32 ts[2];
> +
> + if (!tc6->hw_tstamp_enabled)
> + return;
> + ski = oa_tc6_tsinfo_rx(skb);
> + if (!ski->rtsa)
> + return;
> +
> + memcpy(&ts_val[0], skb->data, 4);
> + memcpy(&ts_val[1], (u32 *)skb->data + 1, 4);
> +
> + ts[0] = be32_to_cpu(ts_val[0]);
> + ts[1] = be32_to_cpu(ts_val[1]);
> +
> + /* Check parity */
> + if ((oa_tc6_get_parity(ts[0]) ^ oa_tc6_get_parity(ts[1])) ==
> + !ski->rtsp) {
> + struct skb_shared_hwtstamps *hw_ts;
> +
> + /* Report timestamp to the upper layers */
> + hw_ts = skb_hwtstamps(skb);
> + memset(hw_ts, 0, sizeof(*hw_ts));
> + hw_ts->hwtstamp = ktime_set(ts[0], ts[1]);
> + }
> + skb_pull(skb, sizeof(ts));
> +}
[Medium]
The two 4-byte memcpys and the skb_pull() assume the linear region
holds at least 8 bytes, but skb->len is never checked. If a short
frame arrives with RTSA_VALID set in the footer, the memcpys read past
the received payload (still inside the allocated buffer, so no OOB,
but garbage becomes a "hardware timestamp"), and skb_pull() returns
NULL without advancing skb->data.
The return value is ignored, so eth_type_trans() then parses the
would-be timestamp bytes as the Ethernet header and delivers a corrupt
frame upstream.
Should this bail out early if skb->len < OA_TC6_TSTAMP_SZ, and check
the return of skb_pull()?
[ ... ]
> @@ -887,12 +1060,18 @@ static void oa_tc6_add_tx_skb_to_spi_buf(struct oa_tc6 *tc6)
> tc6->tx_skb_offset = 0;
> tc6->netdev->stats.tx_bytes += tc6->ongoing_tx_skb->len;
> tc6->netdev->stats.tx_packets++;
> - kfree_skb(tc6->ongoing_tx_skb);
> +
> + /* Free the ones that are not saved for later processing,
> + * like timestamping.
> + */
> + if (!(skb_shinfo(tc6->ongoing_tx_skb)->tx_flags &
> + SKBTX_IN_PROGRESS))
> + kfree_skb(tc6->ongoing_tx_skb);
> tc6->ongoing_tx_skb = NULL;
> }
[High]
When SKBTX_IN_PROGRESS is set the ongoing_tx_skb reference is dropped
without a free, leaving the skb owned solely by tx_ts_skb_q. The only
path that removes and frees these skbs is oa_tc6_process_deferred_skb()
driven by the TTSCA/B/C interrupt.
Two lifetime questions:
On module unload/unbind, oa_tc6_free_pending_skbs() only touches
ongoing_tx_skb, ongoing_rx_skb, and waiting_tx_skb. What frees the
skbs still linked on tx_ts_skb_q?
When hwtstamp is disabled via SIOCSHWTSTAMP,
oa_tc6_set_hwtstamp_settings() masks INT_MASK0_TTSCA_MASK. Any skb
already queued for a pending capture will not receive its completion
IRQ. What drains tx_ts_skb_q in that case?
Because SKBTX_IN_PROGRESS is set on these skbs, their socket-level TX
completion is also blocked until skb_tstamp_tx() or free happens, so a
leak here stalls sockets in addition to leaking memory.
[ ... ]
> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6_ptp.c b/drivers/net/ethernet/oa_tc6/oa_tc6_ptp.c
> new file mode 100644
> index 000000000000..0cde5545ee27
> --- /dev/null
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6_ptp.c
[ ... ]
> +int oa_tc6_ptp_register(struct oa_tc6 *tc6, struct ptp_clock_info *info)
> +{
> + /* Not supporting hardware timestamp isn't an error */
> + if (!tc6->hw_tstamp_supported)
> + return 0;
> +
> + snprintf(info->name, sizeof(info->name), "%s",
> + "OA TC6 PTP clock");
[Low]
This unconditionally overwrites the caller-provided info->name with a
fixed string. If a board hosts more than one OA TC6 MAC-PHY, all PTP
clocks register under the identical name "OA TC6 PTP clock", making
ptp4l/phc2sys logging and pinning ambiguous.
Could the name be derived from dev_name(&spi->dev) or the netdev name,
or left untouched so the vendor caller can set a unique value?
> + tc6->ptp_clock = ptp_clock_register(info, &tc6->spi->dev);
> + if (IS_ERR(tc6->ptp_clock)) {
> + dev_err(&tc6->spi->dev, "Registration of %s failed",
> + info->name);
> + return -EFAULT;
> + }
[High, Low]
Two questions about this failure path:
On failure, tc6->ptp_clock retains the ERR_PTR value from
ptp_clock_register(). oa_tc6_ptp_unregister() later guards on
`if (tc6->ptp_clock)` and oa_tc6_get_ts_info() on `if (!tc6->ptp_clock)`.
Both checks pass for an ERR_PTR, so ptp_clock_unregister() and
ptp_clock_index() end up dereferencing an ERR_PTR. Should tc6->ptp_clock
be reset to NULL before returning here?
-EFAULT is documented for bad userspace addresses. Would returning
PTR_ERR(tc6->ptp_clock) preserve the real errno from ptp_clock_register()
(typically -ENOMEM, -EBUSY, or -EINVAL)?
[ ... ]
> +MODULE_DESCRIPTION("OPEN Alliance 10BASE‑T1x MAC‑PHY Serial Interface Lib");
> +MODULE_AUTHOR("Selva Rajagopal <selvamani.rajagopal@onsemi.com>");
> +MODULE_LICENSE("GPL");
[Low]
All three .c files (oa_tc6.c, oa_tc6_ptp.c, oa_tc6_tstamp.c) link into
the single oa_tc6_mod.ko per the Makefile change, yet each translation
unit declares its own MODULE_DESCRIPTION/MODULE_AUTHOR/MODULE_LICENSE.
This produces duplicate __UNIQUE_ID_license sections and duplicate
modinfo strings.
Would keeping the module metadata only in oa_tc6.c be cleaner?
> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6_std_def.h b/drivers/net/ethernet/oa_tc6/oa_tc6_std_def.h
[ ... ]
> @@ -127,6 +147,17 @@ struct oa_tc6 {
> bool rx_buf_overflow;
> bool int_flag;
> bool disable_traffic;
> + struct ptp_clock_info ptp_clock_info;
[Low]
This ptp_clock_info field does not appear to be assigned or read
anywhere in the series. oa_tc6_ptp_register() takes a struct
ptp_clock_info * argument and forwards it to ptp_clock_register()
directly, and vendor drivers embed their own ptp_clock_info in their
own state. Is this field intended for future use, or can it be
dropped?
> + struct hwtstamp_config ts_config;
> + struct list_head tx_ts_skb_q;
> + struct ptp_clock *ptp_clock;
> + bool hw_tstamp_supported;
> + bool hw_tstamp_enabled;
> + u32 tx_hwtstamp_pkts;
> + u32 tx_hwtstamp_lost;
> + u32 tx_hwtstamp_err;
> + int vend1_mms;
> + u8 tx_ts_idx;
> };
> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c b/drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c
> new file mode 100644
> index 000000000000..f80f1a4916a3
> --- /dev/null
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6_tstamp.c
[ ... ]
> +static int oa_tc6_set_hwtstamp_settings(struct oa_tc6 *tc6)
> +{
> + u32 cfg0, irqm, status0;
> + int ret;
> +
> + ret = oa_tc6_read_register(tc6, OA_TC6_REG_CONFIG0, &cfg0);
> + if (ret) {
> + dev_err(&tc6->spi->dev, "Failed to read CFG0 register\n");
> + goto out;
> + }
[ ... ]
> + ret = oa_tc6_write_register(tc6, OA_TC6_REG_CONFIG0, cfg0);
[Medium]
oa_tc6_read_register() and oa_tc6_write_register() each take
spi_ctrl_lock individually, but the read-modify-write pair on CONFIG0
(and on INT_MASK0) is not atomic across the two calls.
oa_tc6_zero_align_receive_frame_enable() also RMWs CONFIG0. Today
that call comes only from vendor probe (single-threaded), but this
function runs at runtime from ioctl.
Would a dedicated register-state mutex covering the whole RMW sequence
protect against a future runtime user of a different CONFIG0 bit
losing an update?
[ ... ]
> +int oa_tc6_hwtstamp_set(struct oa_tc6 *tc6,
> + struct kernel_hwtstamp_config *cfg)
> +{
[ ... ]
> + switch (cfg->rx_filter) {
> + case HWTSTAMP_FILTER_NONE:
> + case HWTSTAMP_FILTER_ALL:
> + case HWTSTAMP_FILTER_SOME:
> + case HWTSTAMP_FILTER_PTP_V1_L4_EVENT:
[ ... every PTP filter accepted ... ]
> + case HWTSTAMP_FILTER_NTP_ALL:
> + break;
> + default:
> + return -ERANGE;
> + }
> + hwtstamp_config_from_kernel(&tc6->ts_config, cfg);
> +
> + /* Supports timestamping all traffic */
> + if (cfg->rx_filter != HWTSTAMP_FILTER_NONE)
> + tc6->ts_config.rx_filter = HWTSTAMP_FILTER_ALL;
> + return oa_tc6_set_hwtstamp_settings(tc6);
> +}
[Medium]
The coerced filter is written to tc6->ts_config.rx_filter but not
back into the caller-supplied *cfg. When this is wired to
ndo_hwtstamp_set(), dev_set_hwtstamp() copies kernel_hwtstamp_config
back to userspace unchanged, so userspace sees its original request
(for example HWTSTAMP_FILTER_PTP_V2_L2_EVENT) reported as accepted
while the hardware silently applies HWTSTAMP_FILTER_ALL.
Should cfg->rx_filter be updated to HWTSTAMP_FILTER_ALL before returning,
so userspace can observe the coercion the way other drivers signal it?
[Medium]
oa_tc6_get_ts_info() advertises rx_filters = BIT(HWTSTAMP_FILTER_ALL)
alone, while this switch accepts every PTP-related filter and
HWTSTAMP_FILTER_NTP_ALL. ethtool -T therefore describes a different
set of accepted filters than what oa_tc6_hwtstamp_set() actually takes.
Additionally, cfg->flags is not validated on this path; only the ioctl
wrapper oa_tc6_tstamp_ioctl() rejects a non-zero tscfg.flags. Any
HWTSTAMP_FLAG_* bits arriving via ndo_hwtstamp_set() are silently
swallowed.
Should the advertised rx_filters mask reflect what is actually accepted
here, and should cfg->flags be validated in this function too?
--
This is an AI-generated review.
^ permalink raw reply
* Re: [PATCH net-next v7 14/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Paolo Abeni @ 2026-07-21 13:17 UTC (permalink / raw)
To: Selvamani.Rajagopal
Cc: andrew, pier.beruto, hkallweit1, linux, davem, edumazet, kuba,
pabeni, andrew+netdev, parthiban.veerasooran, selvamani.rajagopal,
richardcochran, robh, krzk+dt, conor+dt, horms, corbet, skhan,
netdev, linux-kernel, devicetree, linux-doc, jerry.ray
In-Reply-To: <20260708-s2500-mac-phy-support-v7-14-478c877aa1a9@onsemi.com>
From: AI Reviewer <ai@example.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
onsemi: s2500: Add driver support for TS2500 MAC-PHY
This patch adds a driver for onsemi's S2500 10BASE-T1S MAC-PHY, built on
top of the Open Alliance TC6 framework. It provides ndo_* callbacks,
ethtool statistics/regdump/RMON support, and a PTP clock implementation
including an in-driver adjtime that mixes adjfine-based slewing with
settime.
A few questions and observations below.
> diff --git a/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
> new file mode 100644
> index 000000000000..7e96d9ad563f
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
[ ... ]
> +static const char s2500_mac_stat_strings[][ETH_GSTRING_LEN] = {
> + "tx_bytes",
> + "tx_frames",
> + "tx_broadcast_frames",
> + "tx_multicast_frames",
> + "tx_underflow_errors",
> + "tx_single_collisions",
> + "tx_multiple_collisions",
> + "tx_excessive_collisions",
> + "tx_deferred_frames",
> + "tx_carrier_sense_errors",
> + "rx_bytes",
> + "rx_frames",
> + "rx_broadcast_frames",
> + "rx_multicast_frames",
> + "rx_runts",
> + "rx_oversize_frames",
> + "rx_crc_errors",
> + "rx_symbol_errors",
> + "rx_alignment_errors",
> + "rx_busy_drops",
> + "rx_mismatch_drops",
> +};
[Medium]
Do these ethtool -S entries duplicate counters that have a standard uAPI?
tx_bytes, tx_frames, rx_bytes, rx_frames, rx_broadcast_frames,
rx_multicast_frames, rx_crc_errors, rx_alignment_errors (=rx_frame_errors),
tx_carrier_sense_errors (=tx_carrier_errors), tx_underflow_errors
(=tx_fifo_errors), tx_excessive_collisions (=tx_aborted_errors),
rx_oversize_frames and rx_runts (=rx_length_errors) all appear to fall
into rtnl_link_stats64 categories exposed via ip -s link show.
The driver also does not implement ndo_get_stats64, so those standard
counters are reported as zero. Would it make sense to route these
through ndo_get_stats64 and keep ethtool -S only for the truly
driver-private counters (rx_busy_drops, rx_mismatch_drops, symbol
errors, single/multiple collisions, deferred frames)?
Documentation/networking/statistics.rst describes the expected hierarchy.
[ ... ]
> +static void s2500_rmon_stats(struct net_device *ndev,
> + struct ethtool_rmon_stats *rmon_stats,
> + const struct ethtool_rmon_hist_range **ranges)
> +{
> + struct s2500_info *priv = netdev_priv(ndev);
> + u8 offset;
> + int i;
> +
> + s2500_update_stats(priv);
> +
> + memset(rmon_stats, 0, sizeof(*rmon_stats));
> + rmon_stats->src = ETHTOOL_MAC_STATS_SRC_AGGREGATE;
> + rmon_stats->undersize_pkts = priv->stats_data[S2500_MSTRUNTSERR_IDX];
> + rmon_stats->oversize_pkts = priv->stats_data[S2500_MSTRXTOOLONG_IDX];
> + rmon_stats->fragments = priv->stats_data[S2500_MSTFCSERRS_IDX];
> + rmon_stats->jabbers = priv->stats_data[S2500_MSTALIGNERRS_IDX];
[Medium]
Do fragments and jabbers here match the RFC 2819 / RMON MIB definitions?
RMON defines fragments as undersized frames with a bad FCS/alignment and
jabbers as oversized frames with a bad FCS/alignment, not the raw FCS or
alignment error counters.
If the hardware does not have dedicated fragment/jabber counters, would
leaving these at zero avoid producing misleading data when compared
across devices?
[ ... ]
> +static void s2500_get_regs(struct net_device *ndev,
> + struct ethtool_regs *regs, void *p)
> +{
[ ... ]
> + for (i = 0; i < S2500_NUM_REGS; i++) {
> + val = 0;
> + reg = s2500_reg_map[i].reg;
> + mms = s2500_reg_map[i].mms;
> + ret = oa_tc6_read_register_mms(priv->tc6, reg, mms,
> + &val);
> + if (ret)
> + continue;
> + *pbuff++ = cpu_to_be32(((u32)mms << 16) | reg);
> + *pbuff++ = cpu_to_be32(val);
> + }
> +}
[Medium]
Why is the regdump written as big-endian u32 values via cpu_to_be32()?
The ethtool -d convention (and every other in-tree driver's regdump) is
to write host-native u32 values. On little-endian hosts the current
code produces byte-swapped mms/reg headers and register values, which
generic decoders would misinterpret. Would writing the values without
the byte swap be more consistent with existing drivers?
[ ... ]
> +const struct ethtool_ops s2500_ethtool_ops = {
[ ... ]
> + .get_sset_count = s2500_get_sset_count,
> + .get_strings = s2500_get_strings,
[ ... ]
> + .self_test = net_selftest,
> +};
[Low]
Since .self_test = net_selftest is wired up here, should get_sset_count
also return net_selftest_get_count() for ETH_SS_TEST and should
get_strings populate the strings via net_selftest_get_strings()? Without
those, ethtool cannot enumerate the tests. The follow-up patch in the
series adds this handling, but each patch typically needs to be
self-contained.
> diff --git a/drivers/net/ethernet/onsemi/s2500/s2500_main.c b/drivers/net/ethernet/onsemi/s2500/s2500_main.c
> new file mode 100644
> index 000000000000..2d81b44f8c76
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_main.c
[ ... ]
> +static int s2500_init(struct s2500_info *priv)
> +{
[ ... ]
> + /* Program the source MAC address into the device */
> + ret = s2500_set_mac_filter(priv->ndev, priv->ndev->dev_addr);
> +
> + val = S2500_MAC_CTRL_ADRF_BIT | S2500_MAC_CTRL_FCSA_BIT;
> +
> + return s2500_mac_ctrl_modify_bits(priv, val, false);
> +}
[Medium]
Is the return value of s2500_set_mac_filter() intentionally discarded
here? It is assigned to ret but then overwritten by
s2500_mac_ctrl_modify_bits(). If any of the four SPI writes inside
s2500_set_mac_filter() fails, the driver will still enable address
filtering with a mis-programmed FILT0 register, which would silently
drop all traffic. Should the error be propagated?
[ ... ]
> +/* Deferred function for applying RX mode flags in non-atomic context */
> +static int s2500_rx_mode_update(struct s2500_info *priv)
[ ... ]
> +static void s2500_set_rx_mode(struct net_device *ndev)
> +{
> + struct s2500_info *priv = netdev_priv(ndev);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> +
> + priv->rx_flags_upd = true;
> + priv->ndev_flags = ndev->flags;
> +
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + if (priv->thread)
> + wake_up_process(priv->thread);
> +}
[High, High]
Can priv->thread be dereferenced when it is an ERR_PTR or a freed task?
In s2500_open() on failure of kthread_run(), priv->thread is left as
ERR_PTR(-errno):
priv->thread = kthread_run(s2500_thread_fun, priv, ...);
if (IS_ERR(priv->thread)) {
ret = PTR_ERR(priv->thread);
} else {
...
}
return ret;
An ERR_PTR is non-NULL, so a later s2500_set_rx_mode() would pass the
if (priv->thread) check and hand the ERR_PTR to wake_up_process() as a
task_struct pointer. Would setting priv->thread = NULL on the failure
branch be safer?
There is also a window in s2500_stop():
kthread_stop(priv->thread);
priv->thread = NULL;
kthread_stop() internally does put_task_struct() before it returns, so
between the two statements priv->thread references freed memory.
s2500_set_rx_mode() reads priv->thread without holding priv->lock, and
ndo_set_rx_mode can be invoked from BH context via dev_mc_sync-like
paths rather than under rtnl. Would clearing priv->thread under
priv->lock before calling kthread_stop() (or performing the check under
priv->lock) close this race?
[ ... ]
> +static netdev_tx_t s2500_start_xmit(struct sk_buff *skb,
[ ... ]
> +static void s2500_process_events(struct s2500_info *priv)
> +{
> + u32 val;
> + int ret;
> +
> + if (!priv->event_pending)
> + return;
> +
> + priv->event_pending = false;
> +
> + ret = oa_tc6_read_register(priv->tc6, S2500_REG_SPI_ST0, &val);
> + if (ret) {
> + dev_err(&priv->spi->dev, "Error reading ST0 register");
> + return;
> + }
> +}
[High]
Should this handler write back the observed ST0 bits to acknowledge
them?
The probe path treats ST0 as write-1-to-clear:
/* Acknowledge all IRQ status bits */
ret = oa_tc6_read_register(priv->tc6, S2500_REG_SPI_ST0, &val);
if (!ret) {
u32 mask = S2500_STATUS0_MASK;
val &= mask;
oa_tc6_write_register(priv->tc6, S2500_REG_SPI_ST0, val);
}
At runtime the read value is discarded and never written back, so any
status bits latched later (TX FCS errors, buffer over/underflow, LOFE,
header errors, reset-complete, timestamp captures) would remain set
indefinitely. Does the device gate further status changes or IRQs when
bits are already asserted?
[ ... ]
> +static int s2500_thread_fun(void *data)
[ ... ]
> +static int s2500_open(struct net_device *ndev)
> +{
> + struct s2500_info *priv = netdev_priv(ndev);
> + int ret = 0;
> + u32 val;
> +
> + dev_dbg(&ndev->dev, "%s", "s2500_open");
> + phy_start(priv->ndev->phydev);
> +
> + priv->thread = kthread_run(s2500_thread_fun, priv,
> + DRV_NAME "/%s:%d",
> + dev_name(&priv->spi->dev),
> + spi_get_chipselect(priv->spi, 0));
> +
> + if (IS_ERR(priv->thread)) {
> + ret = PTR_ERR(priv->thread);
> + } else {
> + val = S2500_MAC_CTRL_TXEN_BIT | S2500_MAC_CTRL_RXEN_BIT;
> + ret = s2500_mac_ctrl_modify_bits(priv, val, false);
> +
> + netif_start_queue(priv->ndev);
> + }
> + return ret;
> +}
[Medium]
If s2500_mac_ctrl_modify_bits() fails, should netif_start_queue() still
be called and should ret still be returned as failure?
Right now the queue is started even when the MAC-CTRL write returned an
error, and the function returns the error to the network stack. Since
ndo_open returned failure, s2500_stop() will not be called by the stack
to unwind, leaving the kthread running and the queue started.
[Medium]
Is phy_start() balanced on every failure path from s2500_open()?
phy_start() is called unconditionally at the top. If kthread_run() or
s2500_mac_ctrl_modify_bits() fails, s2500_open returns an error without
a matching phy_stop(), and because ndo_open failed the stack will not
call s2500_stop(). Would a goto-based unwind be more appropriate?
[ ... ]
> +static int s2500_probe(struct spi_device *spi)
> +{
[ ... ]
> + spi->dev.platform_data = priv;
> + spi_set_drvdata(spi, priv);
[Low]
Is overwriting spi->dev.platform_data intentional?
platform_data is normally a channel for the platform layer to hand
pre-populated data to a driver; drivers overwriting it can clobber data
the DT/platform code placed there. spi_set_drvdata() is already called
on the next line, so s2500_remove() could use spi_get_drvdata() /
dev_get_drvdata() instead of reading spi->dev.platform_data.
[ ... ]
> + priv->tc6 = oa_tc6_init(spi, ndev);
> + if (!priv->tc6) {
> + dev_err(&spi->dev, "OA TC6 init failed");
> + return -ENODEV;
> + }
> + oa_tc6_set_vend1_mms(priv->tc6, OA_TC6_PHY_C45_VS_MMS12);
> +
> + /* Clear RSTS, if set */
> + oa_tc6_read_register_mms(priv->tc6, S2500_REG_VS_MIIMIRQS,
> + OA_TC6_PHY_C45_VS_MMS12, &val);
> + val &= MIIM_IRQ_STATUS_RSTS;
> + if (val != 0)
> + oa_tc6_write_register_mms(priv->tc6,
> + S2500_REG_VS_MIIMIRQS,
> + OA_TC6_PHY_C45_VS_MMS12,
> + MIIM_IRQ_STATUS_RSTS);
[Medium]
Is val guaranteed to be initialized before the val &= ... read here?
val is declared uninitialized above and oa_tc6_read_register_mms()'s
return value is discarded. If the underlying read returns early
(e.g. -EINVAL) or fails on the SPI bus, *value is not written and the
subsequent test acts on stack garbage, which could produce an
unintended write to MIIMIRQS or skip a required RSTS acknowledgement.
[ ... ]
> + ret = s2500_init(priv);
> + if (unlikely(ret)) {
> + dev_err(&spi->dev, "failed to s2500_init the device");
> + goto err_reg_read;
> + }
> +
> + /* Configure PTP if the model supports it */
> + ret = s2500_ptp_register(priv);
> + if (unlikely(ret))
> + goto err_reg_read;
> +
> + ret = register_netdev(ndev);
> + if (ret) {
> + dev_err(&spi->dev, "failed to register netdev\n");
> + ret = -ENODEV;
> +
> + goto err_reg_read;
> + }
> + return 0;
> +
> +err_reg_read:
> + dev_err(&spi->dev, "could not initialize macphy");
> + return ret;
> +}
[High]
Does the err_reg_read path leak the resources acquired earlier in probe?
oa_tc6_init() installs a threaded IRQ, initializes the PHY and enables
data transfer, and s2500_ptp_register() calls ptp_clock_register(),
which is not devm-managed. If register_netdev() fails after PTP
registration, the ptp_clock (with its posix_clock device, debugfs
entries and aux kworker) has no owner.
Would the error path benefit from oa_tc6_ptp_unregister() and
oa_tc6_exit() to unwind these in reverse order?
> +static void s2500_remove(struct spi_device *spi)
> +{
> + struct s2500_info *priv = spi->dev.platform_data;
> +
> + dev_dbg(&priv->ndev->dev, "%s", "s2500_remove");
> +
> + oa_tc6_ptp_unregister(priv->tc6);
> + unregister_netdev(priv->ndev);
> + oa_tc6_exit(priv->tc6);
> +}
[Medium]
Is the teardown order in s2500_remove() safe against concurrent user
API access?
While the netdev is still registered, userspace can still invoke
ndo_hwtstamp_get/set via SIOCSHWTSTAMP and the ethtool get_ts_info /
get_ts_stats callbacks, which reach into the OA-TC6 PTP state. Calling
oa_tc6_ptp_unregister() before unregister_netdev() looks like the
reverse of registration order (oa_tc6_init -> s2500_ptp_register ->
register_netdev). Would unregister_netdev() first (which quiesces
user-visible ops through rtnl) close this window?
> diff --git a/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c b/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c
> new file mode 100644
> index 000000000000..7da660cb5b19
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c
[ ... ]
> adjtime callback is implemented using adjfine. If time
> delta is too big, bigger than 1 second, using adjtime
> would take long to reduce the delta. In those cases,
> settime callback is used to reduce the delta. Once delta
> becomes less than a second, it uses adjfine to reduce
> the drift further.
[Medium]
Does the implementation match this description?
For |delta| > 1s the code calls s2500_use_settime() which computes
target = now + rem and calls ptp->settime64(target) - a full step, not
a partial reduction down to below 1s followed by adjfine. The claimed
coarse-then-fine hybrid does not appear to be implemented.
Beyond the mismatch, is hiding a time step inside adjtime consistent
with the PTP uAPI? Step and slew are exposed as different ops so
userspace daemons like phc2sys / ptp4l can choose the policy and audit
time steps; conflating them inside a driver can confuse those consumers.
[ ... ]
> +static int s2500_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
> +{
[ ... ]
> + if (mutex_lock_interruptible(&priv->ptp_adj_lock))
> + return -EINTR;
> +
> + /* Try to slew the clock using adjfine for better accuracy.
> + * For large adjustments fall back to setting time directly.
> + */
> + rem = delta;
> +
> + while (rem != 0 && max_iters--) {
[ ... ]
> + /* Choose a slewing period depending on magnitude */
> + if (abs_delta <= 1000000LL) /* <= 1ms */
> + period_ms = 1000; /* 1 s */
> + else if (abs_delta <= 100000000LL) /* <= 100ms */
> + period_ms = 10000; /* 10 s */
> + else
> + period_ms = 60000; /* 60 s */
[ ... ]
> + /* Apply frequency adjustment */
> + ret = ptp->adjfine(ptp, (long)scaled_ppm);
> + if (ret)
> + break;
> +
> + /* Sleep for the slew period (interruptible). If
> + * interrupted, clear the adjfine and return -EINTR.
> + */
> + if (msleep_interruptible(period_ms)) {
[ ... ]
> + mutex_unlock(&priv->ptp_adj_lock);
> + return ret;
> +}
[High]
Should priv->ptp_adj_lock be held across msleep_interruptible() for up
to ~180 seconds (3 iterations at 60s)?
adjtime is invoked from userspace via PTP_CLOCK_ADJTIME, and the PTP
core does not serialize adjfine/settime64/gettimex64 with adjtime.
Holding the mutex across long sleeps blocks the calling task and any
other adjtime caller for minutes.
Also, s2500_ptp_adjfine() and s2500_ptp_set_time64() do not take
ptp_adj_lock, so a concurrent userspace adjfine or settime64 can
clobber (or be clobbered by) the writes to S2500_REG_VS_PTP_ADJ and the
PTP SEC/NSEC registers that this loop performs.
More broadly, would it be preferable to expose only the primitive ops
(adjfine, settime64, adjphase where supported) and let userspace
daemons implement any coarse-then-fine discipline?
--
This is an AI-generated review.
^ permalink raw reply
* Re: [PATCH net] vhost-net: fix TX stall when vhost owns virtio-net header
From: patchwork-bot+netdevbpf @ 2026-07-21 13:20 UTC (permalink / raw)
To: enrico.zanda
Cc: jasowangio, virtualization, mst, netdev, kuba, kvm, linux-kernel,
eperezma, nd
In-Reply-To: <20260708152242.2268848-1-enrico.zanda@arm.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 8 Jul 2026 16:22:42 +0100 you wrote:
> From: Enrico Zanda <enrico.zanda@arm.com>
>
> When vhost owns the virtio-net header, i.e. when
> VHOST_NET_F_VIRTIO_NET_HDR is negotiated, sock_hlen is 0,
> meaning that no header will be forwarded to the TAP device.
>
> In the current vhost_net_build_xdp() implementation,
> when sock_hlen == 0, the gso pointer can point at the start of the
> Ethernet frame instead of a virtio-net header.
> This results in a wrong interpretation of the destination MAC address
> bytes as struct virtio_net_hdr fields.
>
> [...]
Here is the summary with links:
- [net] vhost-net: fix TX stall when vhost owns virtio-net header
https://git.kernel.org/netdev/net/c/3c0d10f233f1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] pds_core: reject component parameter in legacy firmware update
From: patchwork-bot+netdevbpf @ 2026-07-21 13:20 UTC (permalink / raw)
To: Nikhil P. Rao
Cc: netdev, kuba, brett.creeley, eric.joyner, andrew+netdev, davem,
edumazet, pabeni
In-Reply-To: <20260708163649.128620-1-nikhil.rao@amd.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 8 Jul 2026 16:36:49 +0000 you wrote:
> The legacy firmware update path does not support per-component updates.
> If a user specifies a component parameter with devlink flash, reject
> the request with -EOPNOTSUPP rather than silently ignoring the component
> parameter and flashing the entire firmware image.
>
> Fixes: 49ce92fbee0b ("pds_core: add FW update feature to devlink")
> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
>
> [...]
Here is the summary with links:
- [net] pds_core: reject component parameter in legacy firmware update
https://git.kernel.org/netdev/net/c/7be2552e601c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v5] tipc: fix u16 MTU truncation in media and bearer MTU validation
From: Simon Horman @ 2026-07-21 13:22 UTC (permalink / raw)
To: Cen Zhang (Microsoft)
Cc: jmaloy, davem, edumazet, kuba, pabeni, andrew, netdev,
tipc-discussion, linux-kernel, vadim.fedorenko, tung.quang.nguyen,
AutonomousCodeSecurity, tgopinath, kys
In-Reply-To: <20260714041541.307702-1-blbllhy@gmail.com>
On Tue, Jul 14, 2026 at 12:15:41AM -0400, Cen Zhang (Microsoft) wrote:
> Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied
> MTU values but only enforce a minimum bound, not a maximum. When a user
> sets the MTU to a value exceeding U16_MAX (65535), it passes validation
> but is silently truncated when assigned to u16 fields l->mtu and
> l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000)
> truncate to 0, causing a division by zero in tipc_link_set_queue_limits()
> which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing
> values (e.g. 65537-131071) produce small incorrect MTU values, resulting
> in link malfunction behaviors.
>
> Crash stack (triggered as unprivileged user via user namespace):
>
> tipc_link_set_queue_limits net/tipc/link.c:2531
> tipc_link_create net/tipc/link.c:520
> tipc_node_check_dest net/tipc/node.c:1279
> tipc_disc_rcv net/tipc/discover.c:252
> tipc_rcv net/tipc/node.c:2129
> tipc_udp_recv net/tipc/udp_media.c:392
>
> Two independent paths lack the upper bound check:
> 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET)
> 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET)
>
> Fix both by rejecting MTU values above U16_MAX.
>
> Fixes: 901271e0403a ("tipc: implement configuration of UDP media MTU")
> Reported-by: AutonomousCodeSecurity@microsoft.com
> Closes: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com
> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com>
> ---
> v5: Drop .min from range struct (min check already in handler)
> v4: Add .min check value
> v3: Use nla_policy check to limit MTU max value as suggested by Vadim
> v2: Solved format issue
> Link: https://lore.kernel.org/all/CAB8m9WgETt0AjmFwE=F-CKjGXsK6_WDv0=kbYRcC8-noo+amnA@mail.gmail.com
Thanks,
I believe that v5 covers all the bases wrt review of earlier versions.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 2/3] drm/xe/xe_ras: Report correctable error events to userspace
From: Tauro, Riana @ 2026-07-21 13:22 UTC (permalink / raw)
To: Raag Jadav
Cc: intel-xe, dri-devel, netdev, aravind.iddamsetty, anshuman.gupta,
rodrigo.vivi, joonas.lahtinen, kuba, simona.vetter, airlied,
pratik.bari, joshua.santosh.ranjan, ashwin.kumar.kulkarni,
shubham.kumar, ravi.kishore.koppuravuri, maarten.lankhorst,
mallesh.koujalagi, soham.purkait, Michal Wajdeczko
In-Reply-To: <al8v2STXTiMhp5C5@black.igk.intel.com>
On 21-07-2026 14:07, Raag Jadav wrote:
> On Mon, Jul 20, 2026 at 01:52:11PM +0530, Riana Tauro wrote:
>> When an interrupt is received indicating that error counter has crossed
>> its threshold, read the current counter value and deliver a drm_ras error
>> event to userspace for each affected component.
>>
>> To avoid sending duplicate events when the same component appears multiple
>> times in the response. Send the error-event once per component.
> ...
>
>> +void xe_drm_ras_event(struct xe_device *xe, u8 component, u8 severity, u32 value)
>> +{
>> + struct xe_drm_ras *ras = &xe->ras;
>> + struct xe_drm_ras_counter *info;
>> + struct drm_ras_node *node;
>> + int ret;
>> +
>> + /* Event is supported only if drm_ras is enabled */
>> + if (!xe->info.has_drm_ras)
>> + return;
>> +
>> + if (component >= DRM_XE_RAS_ERR_COMP_MAX) {
> IIUC this is error_id and should be validated against first/last counter
> range in drm_ras layer (similar to registration code).
This should be done before because we are accessing the nodes here.
The nodes anyway won't be available in xe_drm_ras if not registered with
drm_ras.
>
>> + drm_warn(&xe->drm, "unsupported component %u\n", component);
>> + return;
>> + }
>> +
>> + if (severity >= DRM_XE_RAS_ERR_SEV_MAX) {
>> + drm_warn(&xe->drm, "unsupported severity %u\n", severity);
>> + return;
>> + }
>> +
>> + node = &ras->node[severity];
>> + info = ras->info[severity];
>> +
>> + if (!info || !info[component].name)
>> + return;
>> +
>> + ret = drm_ras_nl_error_event(node, component, info[component].name, value);
>> + if (ret)
>> + drm_err_ratelimited(&xe->drm, "drm_ras error-event failed: %d for %s %s\n", ret,
>> + info[component].name, error_severity[severity]);
>> +}
> ...
>
>> +static void ras_send_error_event(struct xe_device *xe, u8 severity, u8 component)
>> +{
>> + struct xe_ras_error_class counter = {0};
>> + u8 drm_severity, drm_component;
>> + u32 value;
>> + int ret;
>> +
>> + counter.common.severity = severity;
>> + counter.common.component = component;
>> +
>> + ret = get_counter(xe, &counter, &value);
>> + if (ret)
>> + return;
>> +
>> + drm_severity = xe_to_drm_ras_severity(severity);
>> + drm_component = xe_to_drm_ras_component(component);
>> +
>> + xe_drm_ras_event(xe, drm_component, drm_severity, value);
>> +}
> This entire function can be dropped. See below.
We don't need to drop function. It's cleaner to have it in the function
than repeating it twice.
>
>> static u8 handle_core_compute_errors(struct xe_ras_error_array *arr)
>> {
>> struct xe_ras_compute_error *error_info = (void *)arr->details;
>> @@ -312,8 +364,10 @@ void xe_ras_counter_threshold_crossed(struct xe_device *xe,
>> struct xe_ras_threshold_crossed *pending = (void *)&response->data;
>> struct xe_ras_error_class *errors = pending->counters;
>> u32 id, ncounters = pending->ncounters;
>> + u8 sent = 0;
>>
>> BUILD_BUG_ON(sizeof(response->data) < sizeof(*pending));
>> + BUILD_BUG_ON(BITS_PER_TYPE(sent) < XE_RAS_COMP_MAX);
>> xe_device_assert_mem_access(xe);
>>
>> if (!ncounters || ncounters > XE_RAS_NUM_COUNTERS)
>> @@ -327,8 +381,21 @@ void xe_ras_counter_threshold_crossed(struct xe_device *xe,
>> severity = errors[id].common.severity;
>> component = errors[id].common.component;
>>
>> + if (severity != XE_RAS_SEV_CORRECTABLE) {
>> + xe_warn(xe, "sysctrl: unexpected severity %s (%u)\n", sev_to_str(severity),
>> + severity);
> Sanity checks are good, but I think this needs to be extended a bit.
> I have something[1] more robust, feel free to reuse.
>
> [1] https://lore.kernel.org/intel-xe/20260721082953.640497-1-raag.jadav@intel.com
Agreed. I'll drop the checks. We can merge [1] first.
We can drop the drm checks above also if [1] is merged.
Will remove all checks and resend a new version.
>
>> + continue;
>> + }
>> +
>> xe_warn(xe, "[RAS]: %s %s detected\n",
>> comp_to_str(component), sev_to_str(severity));
>> +
>> + /* Send event once per component */
>> + if (sent & BIT(component))
>> + continue;
>> + sent |= BIT(component);
> With [1] in place you can just get_counter(&counter) and drm_ras_event()
> directly.
Same as above. Better to retain function.
Thanks
Riana
>
> Raag
>
>> + ras_send_error_event(xe, severity, component);
>> }
>> }
>>
>> --
>> 2.47.1
>>
^ permalink raw reply
* Re: [PATCH net-next] net/tcp: Prevent inlining tcp_syn_ack_timeout()
From: Paolo Abeni @ 2026-07-21 13:24 UTC (permalink / raw)
To: Emil Tsalapatis, netdev, edumazet; +Cc: ncardwell, kuniyu, davem, kuba
In-Reply-To: <20260708180837.9507-1-emil@etsalapatis.com>
On 7/8/26 8:08 PM, Emil Tsalapatis wrote:
> The tcp_syn_ack_timeout() function gets inlined by Clang,
> preventing tracing. Since the call is not in the fast
> path, prevent it from being inlined.
>
> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
> net/ipv4/tcp_timer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
> index bf171b5e1eb3..f7215d53bbda 100644
> --- a/net/ipv4/tcp_timer.c
> +++ b/net/ipv4/tcp_timer.c
> @@ -748,7 +748,7 @@ static void tcp_write_timer(struct timer_list *t)
> sock_put(sk);
> }
>
> -void tcp_syn_ack_timeout(const struct request_sock *req)
> +noinline_for_tracing void tcp_syn_ack_timeout(const struct request_sock *req)
> {
> struct net *net = read_pnet(&inet_rsk(req)->ireq_net);
>
What's the point of tracing such function? It just increment a mib. If
you want to discriminate between TFO and non TFO syn ack timeout,
possibly adding another MIB counter and incrementing it in
tcp_fastopen_synack_timer() would be better???
/P
^ permalink raw reply
* Re: [PATCH] docs: ACPI: DSD: motorcomm: fix docs build error
From: Rafael J. Wysocki (Intel) @ 2026-07-21 13:25 UTC (permalink / raw)
To: Andrew Lunn, Randy Dunlap
Cc: linux-kernel, chunzhi.lin, Jakub Kicinski, netdev, Russell King,
linux-acpi, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman
In-Reply-To: <532f6e46-ee9f-4170-8ec4-72374e761cb0@lunn.ch>
On Fri, Jul 10, 2026 at 6:37 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Jul 09, 2026 at 10:31:06PM -0700, Randy Dunlap wrote:
> > Separate the title with commas (since they are all run togethe in the
>
> nitpick: together.
Fixed up and applied as 7.3 material, thanks!
^ permalink raw reply
* Re: [PATCH net-next v5] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Andrew Lunn @ 2026-07-21 13:27 UTC (permalink / raw)
To: Kyle Switch
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, ming.xu, xiaolin.xu, jianmin.wang, jie.han
In-Reply-To: <20260721114810.660718-1-kyle.switch@motor-comm.com>
> +#define YT8824_UTP_TEMPLATE_MODE_CTRL (0x84)
> +#define YT8824_UTP_TEMPLATE_MODE_MASK GENMASK(15, 13)
> +#define YT8824_UTP_TEMPLATE_TEST_MODE1 BIT(13)
Is this MultiGBASE-T test mode register (Register 1.132)?
The test mode control is not a single bit, but three bits. So you
should not be using BIT(13).
Since this is a standard part of C45, please add a helper to phy-c45.c
Another thing i want to take a look at is the locking. It is pretty
ugly having to use so many __ functions, and not being able to use the
helpers. I want to see if we can avoid this.
Andrew
---
pw-bot: cr
^ permalink raw reply
* [PATCH net-next v5 0/3] ptp: Add driver for R-Car Gen4
From: Niklas Söderlund @ 2026-07-21 13:29 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Richard Cochran, Andrew Lunn,
DavidS. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Vadim Fedorenko, linux-renesas-soc, devicetree, linux-kernel,
netdev
Cc: Niklas Söderlund
Hello,
This series is the first part cleaning up how PTP timer support is
implemented on R-Car Gen4. Currently there is partial support for it in
some of the Ethernet devices that can use it, but not all.
The partial support have been implemented by hacking the gPTP module
directly into the first Ethernet device driver that used it, RTSN for
V4H and RSWITCH for S4. This is understandable as earlier R-Car
generations had a dedicated gPTP timer for each Ethernet device, but on
Gen4 there is a single system-wide PTP timer shared by all.
The current implementation makes it impossible for other Ethernet
devices on the platform to use the PTP timer without messing around with
other Ethernet device drivers.
The effort to clean this up starts with this series which adds the
system-wide gPTP timer as its own driver and device tree node.
This series will then be followed by work to add proper PTP support to
the R-Car RAVB Gen4 driver, which currently advertises to user-space it
supports PTP but which implementation is broken and does not work.
This will in turn be followed by work to the RTSN and RSWITCH drivers
will be be switched from its current partial support by mapping the gPTP
address space directly to instead use this driver.
Having both this and RTSN/RSWITCH described and enabled (!) in device
tree will not work as they will try to use the same memory region. For
this reason this new solution will only be enabled on platforms
after all user's of the gPTP clock have moved to only use the new
centralized timer. But in the interim both devices will be described
(but not enabled) in the platforms base dtsi file.
For some platforms this is straight forward, such as V4H Sparrow Hawk,
which only have the RAVB Ethernet interface. This platform currently
have no users of the PTP timer, but still advertise it supports it. This
and the soon to be posted RAVB patches solves that.
As the RAVB patches depends on this series the device tree node for the
gPTP clock is added in this series but will be enabled and linked to
consumers in the RAVB gPTP series for platforms where it will not
conflict with RTSN and RSWITCH. And further enabled as more of this is
cleaned up.
The gPTP driver itself is heavily influence by the existing partial
support for gPTP in the RTSN and RSWITCH drivers and the Renesas BSP.
Niklas Söderlund (3):
dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4
ptp: Add driver for R-Car Gen4
arm64: dts: renesas: r8a779g0: Add gPTP node
.../bindings/ptp/renesas,rcar-gen4-gptp.yaml | 64 +++++
MAINTAINERS | 7 +
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 9 +
drivers/ptp/Kconfig | 12 +
drivers/ptp/Makefile | 1 +
drivers/ptp/ptp_rcar_gen4.c | 225 ++++++++++++++++++
6 files changed, 318 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
create mode 100644 drivers/ptp/ptp_rcar_gen4.c
--
2.55.0
^ permalink raw reply
* [PATCH net-next v5 1/3] dt-bindings: ptp: renesas,rcar-gen4-gptp: Add R-Car Gen4
From: Niklas Söderlund @ 2026-07-21 13:29 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Richard Cochran, Andrew Lunn,
DavidS. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Vadim Fedorenko, linux-renesas-soc, devicetree, linux-kernel,
netdev
Cc: Niklas Söderlund, Krzysztof Kozlowski
In-Reply-To: <20260721132936.1331318-1-niklas.soderlund+renesas@ragnatech.se>
Add bindings for the R-Car Gen4 gPTP timer. The timer enables accurate
synchronization of the clock in the control system. The timer is
system-wide and used by different Ethernet devices on each Gen4 platform.
- On R-Car S4 it is shared between RSWITCH and RAVB.
- On R-Car V4H it is shared between RTSN and RAVB.
- On R-Car V4M it is only used by RAVB.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
* Changes since v1
- Drop 'binding for' for patch subject.
- Drop comment for renesas,rcar-gen4-gptp compatible to match other
Renesas bindings.
- Drop unused label in example.
- Rename node ptp in example.
---
.../bindings/ptp/renesas,rcar-gen4-gptp.yaml | 64 +++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
diff --git a/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
new file mode 100644
index 000000000000..3edd64d40038
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2026 Renesas Electronics Corp.
+# Copyright (C) 2026 Niklas Söderlund <niklas.soderlund@ragnatech.se>
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ptp/renesas,rcar-gen4-gptp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen4 gPTP timer
+
+maintainers:
+ - Niklas Söderlund <niklas.soderlund@ragnatech.se>
+
+description:
+ The R-Car Gen4 gPTP timer enables accurate synchronization of the clock in
+ the control system. The timer is system-wide and used by different Ethernet
+ devices on each Gen4 platform.
+
+ - On R-Car S4 it is shared between RSWITCH and RAVB.
+ - On R-Car V4H it is shared between RTSN and RAVB.
+ - On R-Car V4M it is only used by RAVB.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - renesas,r8a779f0-gptp # S4-8
+ - renesas,r8a779g0-gptp # V4H
+ - renesas,r8a779h0-gptp # V4M
+ - const: renesas,rcar-gen4-gptp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - power-domains
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
+ #include <dt-bindings/power/r8a779g0-sysc.h>
+
+ ptp@e6449000 {
+ compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
+ reg = <0xe6449000 0x500>;
+ clocks = <&cpg CPG_MOD 2723>;
+ power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+ resets = <&cpg 2723>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 6940aa3d498b..4e1c4ed038c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22914,6 +22914,12 @@ S: Maintained
F: Documentation/devicetree/bindings/mtd/renesas-nandc.yaml
F: drivers/mtd/nand/raw/renesas-nand-controller.c
+RENESAS R-CAR GEN4 GPTP DRIVER
+M: Niklas Söderlund <niklas.soderlund@ragnatech.se>
+L: linux-renesas-soc@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
+
RENESAS R-CAR GYROADC DRIVER
M: Marek Vasut <marek.vasut+renesas@mailbox.org>
L: linux-iio@vger.kernel.org
--
2.55.0
^ permalink raw reply related
* [PATCH net-next v5 2/3] ptp: Add driver for R-Car Gen4
From: Niklas Söderlund @ 2026-07-21 13:29 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Richard Cochran, Andrew Lunn,
DavidS. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Vadim Fedorenko, linux-renesas-soc, devicetree, linux-kernel,
netdev
Cc: Niklas Söderlund
In-Reply-To: <20260721132936.1331318-1-niklas.soderlund+renesas@ragnatech.se>
Add driver for the gPTP timer found on R-Car Gen4 devices. The timer is
system-wide and shared by different Ethernet devices on each Gen4
platform. The operation of the timer is however not completely in
depended of the systems Ethernet devices.
- On R-Car S4 is gated by the RSWITCH Ethernet module clock.
- On R-Car V4H is gated by the RTSN Ethernet module clock.
- On R-Car V4M is gated by its own module clock, the system have
neither RTSN or RSWITCH device. But the module clock is the same as
RTSN on V4H and the documentation referees to it as tsn (EtherTSN).
The gPTP device do have its own register space on all three platforms.
But on S4 and V4H it will share its clock and reset property with
RSWITCH or RTSN, respectively.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
* Changes since v4
- Drop mod_devicetable.h include.
- Remove clap of register value as .max_adj prevents any overflow.
* Changes since v3
- Clamp increment calculated to register limitations.
- Check return value of clk_get_rate().
- Disable PM if ptp_clock_register() fails.
---
MAINTAINERS | 1 +
drivers/ptp/Kconfig | 12 ++
drivers/ptp/Makefile | 1 +
drivers/ptp/ptp_rcar_gen4.c | 225 ++++++++++++++++++++++++++++++++++++
4 files changed, 239 insertions(+)
create mode 100644 drivers/ptp/ptp_rcar_gen4.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e1c4ed038c5..ed54ac3cf550 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22919,6 +22919,7 @@ M: Niklas Söderlund <niklas.soderlund@ragnatech.se>
L: linux-renesas-soc@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/ptp/renesas,rcar-gen4-gptp.yaml
+F: drivers/ptp/ptp_rcar_gen4.c
RENESAS R-CAR GYROADC DRIVER
M: Marek Vasut <marek.vasut+renesas@mailbox.org>
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index b93640ca08b7..3593fd9da92a 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -263,4 +263,16 @@ config PTP_NETC_V4_TIMER
synchronization. It also supports periodic output signal (e.g. PPS)
and external trigger timestamping.
+config PTP_RCAR_GEN4
+ tristate "Renesas R-Car Gen4 PTP Driver"
+ depends on ARCH_RENESAS || COMPILE_TEST
+ depends on PTP_1588_CLOCK
+ help
+ This driver adds support for using the Renesas R-Car Gen4 gPTP timer
+ as a PTP clock, the clock can then be used by Gen4 Ethernet drivers
+ for PTP time synchronization.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ptp_rcar_gen4.
+
endmenu
diff --git a/drivers/ptp/Makefile b/drivers/ptp/Makefile
index bdc47e284f14..0464a586bed2 100644
--- a/drivers/ptp/Makefile
+++ b/drivers/ptp/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_PTP_1588_CLOCK_OCP) += ptp_ocp.o
obj-$(CONFIG_PTP_DFL_TOD) += ptp_dfl_tod.o
obj-$(CONFIG_PTP_S390) += ptp_s390.o
obj-$(CONFIG_PTP_NETC_V4_TIMER) += ptp_netc.o
+obj-$(CONFIG_PTP_RCAR_GEN4) += ptp_rcar_gen4.o
diff --git a/drivers/ptp/ptp_rcar_gen4.c b/drivers/ptp/ptp_rcar_gen4.c
new file mode 100644
index 000000000000..8072d5f2b72d
--- /dev/null
+++ b/drivers/ptp/ptp_rcar_gen4.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Renesas R-Car Gen4 gPTP device driver
+ *
+ * Copyright (C) 2026 Renesas Electronics Corporation
+ * Copyright (C) 2026 Niklas Söderlund <niklas.soderlund@ragnatech.se>
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/ptp_clock_kernel.h>
+#include <linux/types.h>
+
+#define PTPTMEC_REG 0x0010
+#define PTPTMDC_REG 0x0014
+#define PTPTIVC0_REG 0x0020
+#define PTPTOVC00_REG 0x0030
+#define PTPTOVC10_REG 0x0034
+#define PTPTOVC20_REG 0x0038
+#define PTPGPTPTM00_REG 0x0050
+#define PTPGPTPTM10_REG 0x0054
+#define PTPGPTPTM20_REG 0x0058
+
+struct ptp_rcar_gen4_priv {
+ void __iomem *base;
+ struct clk *clk;
+
+ struct ptp_clock *clock;
+ struct ptp_clock_info info;
+
+ spinlock_t lock; /* Registers access. */
+ s64 default_addend;
+};
+
+#define ptp_to_priv(ptp) container_of(ptp, struct ptp_rcar_gen4_priv, info)
+
+static int ptp_rcar_gen4_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
+{
+ struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+ s64 addend = priv->default_addend;
+ bool neg_adj = scaled_ppm < 0;
+ unsigned long flags;
+ s64 diff;
+
+ if (neg_adj)
+ scaled_ppm = -scaled_ppm;
+ diff = div_s64(addend * scaled_ppm_to_ppb(scaled_ppm), NSEC_PER_SEC);
+ addend = neg_adj ? addend - diff : addend + diff;
+
+ spin_lock_irqsave(&priv->lock, flags);
+ iowrite32(addend, priv->base + PTPTIVC0_REG);
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ return 0;
+}
+
+static void _ptp_rcar_gen4_gettime(struct ptp_clock_info *ptp,
+ struct timespec64 *ts)
+{
+ struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+
+ lockdep_assert_held(&priv->lock);
+
+ ts->tv_nsec = ioread32(priv->base + PTPGPTPTM00_REG);
+ ts->tv_sec = ioread32(priv->base + PTPGPTPTM10_REG) |
+ ((s64)ioread32(priv->base + PTPGPTPTM20_REG) << 32);
+}
+
+static int ptp_rcar_gen4_gettime(struct ptp_clock_info *ptp,
+ struct timespec64 *ts)
+{
+ struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
+ _ptp_rcar_gen4_gettime(ptp, ts);
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ return 0;
+}
+
+static void _ptp_rcar_gen4_settime(struct ptp_clock_info *ptp,
+ const struct timespec64 *ts)
+{
+ struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+
+ lockdep_assert_held(&priv->lock);
+
+ iowrite32(1, priv->base + PTPTMDC_REG);
+ iowrite32(0, priv->base + PTPTOVC20_REG);
+ iowrite32(0, priv->base + PTPTOVC10_REG);
+ iowrite32(0, priv->base + PTPTOVC00_REG);
+ iowrite32(1, priv->base + PTPTMEC_REG);
+ iowrite32(ts->tv_sec >> 32, priv->base + PTPTOVC20_REG);
+ iowrite32(ts->tv_sec, priv->base + PTPTOVC10_REG);
+ iowrite32(ts->tv_nsec, priv->base + PTPTOVC00_REG);
+}
+
+static int ptp_rcar_gen4_settime(struct ptp_clock_info *ptp,
+ const struct timespec64 *ts)
+{
+ struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+ unsigned long flags;
+
+ spin_lock_irqsave(&priv->lock, flags);
+ _ptp_rcar_gen4_settime(ptp, ts);
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ return 0;
+}
+
+static int ptp_rcar_gen4_adjtime(struct ptp_clock_info *ptp, s64 delta)
+{
+ struct ptp_rcar_gen4_priv *priv = ptp_to_priv(ptp);
+ struct timespec64 ts;
+ unsigned long flags;
+ s64 now;
+
+ spin_lock_irqsave(&priv->lock, flags);
+ _ptp_rcar_gen4_gettime(ptp, &ts);
+ now = ktime_to_ns(timespec64_to_ktime(ts));
+ ts = ns_to_timespec64(now + delta);
+ _ptp_rcar_gen4_settime(ptp, &ts);
+ spin_unlock_irqrestore(&priv->lock, flags);
+
+ return 0;
+}
+
+static struct ptp_clock_info ptp_rcar_gen4_info = {
+ .owner = THIS_MODULE,
+ .name = "R-Car Gen4 gPTP",
+ .max_adj = 50000000,
+ .adjfine = ptp_rcar_gen4_adjfine,
+ .adjtime = ptp_rcar_gen4_adjtime,
+ .gettime64 = ptp_rcar_gen4_gettime,
+ .settime64 = ptp_rcar_gen4_settime,
+};
+
+static int ptp_rcar_gen4_probe(struct platform_device *pdev)
+{
+ struct ptp_rcar_gen4_priv *priv;
+ struct device *dev = &pdev->dev;
+ unsigned long rate;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ priv->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(priv->clk))
+ return PTR_ERR(priv->clk);
+
+ rate = clk_get_rate(priv->clk);
+ if (!rate)
+ return -ENODEV;
+
+ spin_lock_init(&priv->lock);
+
+ priv->info = ptp_rcar_gen4_info;
+
+ /* Default timer increment in ns.
+ * bit[31:27] - integer
+ * bit[26:0] - decimal
+ * increment[ns] = perid[ns] * 2^27 => (1ns * 2^27) / rate[hz]
+ */
+
+ priv->default_addend = div_s64(1000000000LL << 27, rate);
+
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
+ iowrite32(priv->default_addend, priv->base + PTPTIVC0_REG);
+ iowrite32(1, priv->base + PTPTMEC_REG);
+
+ priv->clock = ptp_clock_register(&priv->info, dev);
+ if (IS_ERR(priv->clock)) {
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+ return PTR_ERR(priv->clock);
+ }
+
+ return 0;
+}
+
+static void ptp_rcar_gen4_remove(struct platform_device *pdev)
+{
+ struct ptp_rcar_gen4_priv *priv = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
+
+ ptp_clock_unregister(priv->clock);
+
+ iowrite32(1, priv->base + PTPTMDC_REG);
+
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+}
+
+static const struct of_device_id ptp_rcar_gen4_of_match[] = {
+ { .compatible = "renesas,rcar-gen4-gptp", },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ptp_rcar_gen4_of_match);
+
+static struct platform_driver ptp_rcar_gen4_driver = {
+ .driver = {
+ .name = "ptp-rcar-gen4",
+ .of_match_table = ptp_rcar_gen4_of_match,
+ },
+ .probe = ptp_rcar_gen4_probe,
+ .remove = ptp_rcar_gen4_remove,
+};
+module_platform_driver(ptp_rcar_gen4_driver);
+
+MODULE_AUTHOR("Niklas Söderlund");
+MODULE_DESCRIPTION("Renesas R-Car Gen4 gPTP driver");
+MODULE_LICENSE("GPL");
--
2.55.0
^ permalink raw reply related
* [PATCH net-next v5 3/3] arm64: dts: renesas: r8a779g0: Add gPTP node
From: Niklas Söderlund @ 2026-07-21 13:29 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Richard Cochran, Andrew Lunn,
DavidS. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Vadim Fedorenko, linux-renesas-soc, devicetree, linux-kernel,
netdev
Cc: Niklas Söderlund
In-Reply-To: <20260721132936.1331318-1-niklas.soderlund+renesas@ragnatech.se>
The gPTP module is shared between the RAVB and RTSN Ethernet devices on
the SoC.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
* Changes since v2
- Preserve sort order by unit-address.
* Changes since v1
- Rename node ptp.
---
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
index 82a7278836e5..b9b860ef7035 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
@@ -589,6 +589,15 @@ tmu4: timer@ffc00000 {
status = "disabled";
};
+ gptp: ptp@e6449000 {
+ compatible = "renesas,r8a779g0-gptp", "renesas,rcar-gen4-gptp";
+ reg = <0 0xe6449000 0 0x500>;
+ clocks = <&cpg CPG_MOD 2723>;
+ power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+ resets = <&cpg 2723>;
+ status = "disabled";
+ };
+
tsn0: ethernet@e6460000 {
compatible = "renesas,r8a779g0-ethertsn", "renesas,rcar-gen4-ethertsn";
reg = <0 0xe6460000 0 0x7000>,
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] amt: fix use-after-free in AMT delayed works
From: Simon Horman @ 2026-07-21 13:34 UTC (permalink / raw)
To: Shihuang Liu
Cc: netdev, ap420073, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-kernel, stable
In-Reply-To: <20260714072705.129262-1-shlomojune6@gmail.com>
On Tue, Jul 14, 2026 at 03:27:05PM +0800, Shihuang Liu wrote:
> When an AMT device is removed, pending delayed works can still access
> the freed amt_dev structure, which may result in kernel crashes or
> memory corruption.
>
> amt_dev_stop() cancels req_wq and discovery_wq with
> cancel_delayed_work_sync(), but these works can be scheduled again
> from event_wq after the cancellation. This allows delayed works to
> access the freed amt_dev structure after the netdev has been released.
>
> The following is a simple race scenario:
>
> CPU0 CPU1
>
> amt_dev_stop()
> cancel_delayed_work_sync()
> amt_event_work()
> mod_delayed_work(req_wq)
> free netdev
> req_wq accesses freed amt_dev
>
> Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and
> discovery_wq from being queued again and wait for running work items
> to complete.
>
> The delayed works are disabled after initialization in
> amt_newlink() and enabled only when the device is successfully opened.
> This keeps the delayed work lifecycle synchronized with the lifetime
> of the AMT device.
>
> Fixes: cbc21dc1cfe9 ("amt: add data plane of amt interface")
> Cc: stable@vger.kernel.org
> Signed-off-by: Shihuang Liu <shlomojune6@gmail.com>
...
This patch seems fine to me, however, as it was not marked as
being for net our CI tried to apply it to net-next, which failed
due to a conflict there.
Please consider resubmitting with the patch targeted at the net tree like
this:
Subject: [PATCH REPOST net] ...
Feel free to include:
Reviewed-by: Simon Horman <horms@kernel.org>
Thanks!
--
pw-bot: changes-requested
^ permalink raw reply
* [PATCH net] nfc: trf7970a: drain timeout_work and keep trf->lock valid across teardown
From: Fan Wu @ 2026-07-21 13:35 UTC (permalink / raw)
To: netdev; +Cc: mgreer, sameo, linux-wireless, linux-kernel, stable, Fan Wu
The threaded IRQ handler and timeout work can wait on trf->lock while
teardown destroys it. The timeout handler can also access the digital
device after it has been freed.
Synchronize timeout_work before releasing the digital device, and leave
the embedded mutex alive for devres cleanup to synchronize the IRQ
handler before trf is freed: devm_request_threaded_irq() is registered
after devm_kzalloc(), so devm_free_irq() runs before trf is released.
This issue was found by an in-house static analysis tool.
Fixes: 165063f1dac4 ("NFC: trf7970a: Add driver with ISO/IEC 14443 Type 2 Tag Support")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
---
drivers/nfc/trf7970a.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index d17c701..fa2f75a 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -2206,13 +2206,13 @@ static int trf7970a_probe(struct spi_device *spi)
err_shutdown:
trf7970a_shutdown(trf);
err_free_ddev:
+ cancel_delayed_work_sync(&trf->timeout_work);
nfc_digital_free_device(trf->ddev);
err_disable_vddio_regulator:
regulator_disable(trf->vddio_regulator);
err_disable_vin_regulator:
regulator_disable(trf->vin_regulator);
err_destroy_lock:
- mutex_destroy(&trf->lock);
return ret;
}
@@ -2226,13 +2226,13 @@ static void trf7970a_remove(struct spi_device *spi)
mutex_unlock(&trf->lock);
+ cancel_delayed_work_sync(&trf->timeout_work);
+
nfc_digital_unregister_device(trf->ddev);
nfc_digital_free_device(trf->ddev);
regulator_disable(trf->vddio_regulator);
regulator_disable(trf->vin_regulator);
-
- mutex_destroy(&trf->lock);
}
#ifdef CONFIG_PM_SLEEP
--
2.34.1
^ permalink raw reply related
* [TEST] google runner needs nested cases
From: Jakub Kicinski @ 2026-07-21 13:38 UTC (permalink / raw)
To: Sheena Mohan, Harshitha Ramamurthy; +Cc: netdev, Willem de Bruijn
Hi!
Another ask, please parse the TAP output of the tests and provide
a nested array of results per-subcase, see:
https://github.com/linux-netdev/nipa/wiki/Netdev-CI-system/#results
right now you only seem to report top level pass/fail but most tests
have at least one sub-case the driver doesn't support.
^ permalink raw reply
* linux-next: manual merge of the bpf-next tree with the net tree
From: Mark Brown @ 2026-07-21 13:46 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: Jakub Kicinski, Jordan Rife, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
net/core/filter.c
between commit:
3f4920d165b29 ("bpf: Reject redirect helpers without a bpf_net_context")
from the net tree and commit:
509ca545d4255 ("bpf: Support BPF_F_EGRESS with bpf_redirect_peer")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc net/core/filter.c
index 11bb0d236822a,0b7afdd0ae474..0000000000000
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -2575,13 -2578,12 +2580,13 @@@ static const struct bpf_func_proto bpf_
BPF_CALL_2(bpf_redirect_peer, u32, ifindex, u64, flags)
{
- struct bpf_redirect_info *ri = bpf_net_ctx_get_ri();
+ struct bpf_redirect_info *ri;
- if (unlikely(!bpf_net_ctx_get() || flags))
- if (unlikely(flags & ~BPF_F_EGRESS))
++ if (unlikely(!bpf_net_ctx_get() || flags & ~BPF_F_EGRESS))
return TC_ACT_SHOT;
+ ri = bpf_net_ctx_get_ri();
- ri->flags = BPF_F_PEER;
+ ri->flags = BPF_F_PEER | flags;
ri->tgt_index = ifindex;
return TC_ACT_REDIRECT;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3 net-next] ipv6: add CAP_NET_ADMIN check for forwarding and force_forwarding sysctl
From: Fernando Fernandez Mancera @ 2026-07-21 13:46 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, horms, pabeni, kuba, edumazet, davem, dsahern
In-Reply-To: <20260721122430.GC2592863@shredder>
On 7/21/26 2:24 PM, Ido Schimmel wrote:
> On Thu, Jul 16, 2026 at 10:37:13PM +0200, Fernando Fernandez Mancera wrote:
>> As commit 8292d7f6e871 ("net: ipv4: add capability check for net
>> administration") did for IPv4, make sure that CAP_NET_ADMIN is required
>> to modify IPv6 forwarding and force_forwarding sysctl. This keep the
>> consistency of permission check logic between both protocols.
>
> What's the value beyond protocol consistency given that it creates
> intra-protocol inconsistency (none of the other IPv6 sysctl handlers
> have this check)? 8292d7f6e871 does not explain why only forwarding was
> changed. As-is, I don't see much value in this change. Tested using
> [1].
>
Ideally, all IPv6 and IPv4 should require CAP_NET_ADMIN as they are
indeed configuring networking interface configuration. I thought
changing all of them all of a sudden would be too much so I went for
forwarding only.
As to answer why it was done for IPv4 in first place, I guess it was
done because forwarding is the most popular option and also quite
relevant in terms of impact in the system behaviour.
If we don't want to merge this as it is, I see 3 ways forward:
1. drop this patch from the series
2. drop the permission check in IPv4 forwarding sysctl
3. extend the check to all sysctls of IPv4 and IPv6
Ideally I would go for 3. if it isn't too much in your opinion.
Otherwise, likely 1.
Thanks,
Fernando.
> Before:
>
> uid=0(root) gid=0(root) groups=0(root)
> v4 fwd: 1
> v4 rp_filter: 0
> v6 fwd: 0
> v6 accept_ra: 0
>
> After:
>
> uid=0(root) gid=0(root) groups=0(root)
> v4 fwd: 1
> v4 rp_filter: 0
> v6 fwd: 1
> v6 accept_ra: 0
>
> [1]
> #!/bin/bash
>
> id
> capsh --drop=cap_net_admin -- -c '
> sysctl -wq net.ipv4.conf.all.forwarding=1 &> /dev/null
> echo "v4 fwd: $?"
> sysctl -wq net.ipv4.conf.all.rp_filter=2 &> /dev/null
> echo "v4 rp_filter: $?"
> sysctl -wq net.ipv6.conf.all.forwarding=1 &> /dev/null
> echo "v6 fwd: $?"
> sysctl -wq net.ipv6.conf.all.accept_ra=2 &> /dev/null
> echo "v6 accept_ra: $?"
> '
>
^ permalink raw reply
* Re: [PATCH] net: pcs: xpcs-plat: fix runtime PM initialization
From: Jakub Kicinski @ 2026-07-21 13:49 UTC (permalink / raw)
To: Coia Prant
Cc: netdev, Andrew Lunn, Heiner Kallweit, Russell King,
David S . Miller, Eric Dumazet, Paolo Abeni, Serge Semin,
linux-kernel, stable
In-Reply-To: <7BA9366A-3243-4A46-BA8F-BB170C8AD912@gmail.com>
On Tue, 21 Jul 2026 09:53:53 +0800 Coia Prant wrote:
> I came across what looks like a runtime PM initialization issue while
> using pcs-xpcs-plat.c as a reference for the Rockchip XPCS glue driver
> (drivers/net/pcs/pcs-xpcs-rk.c).
>
> The current code in pcs-xpcs-plat.c does:
>
> pm_runtime_set_active(dev);
> ret = devm_pm_runtime_enable(dev);
>
> This sets the initial PM state to ACTIVE before runtime PM is fully
> enabled, and before the clock is prepared and enabled.
>
> If the device is later suspended (e.g., during unbind), the suspend
> callback may try to disable a clock that was never enabled, leading to:
>
> clk_csr already disabled
> clk_csr already unprepared
>
> On Rockchip platforms, the CSR clock (PCLK_XPCS) is required for register
> access, and this pattern seems problematic when a clock is actually
> provided.
Thanks for a clear explanation! A couple of sentences to this effect in
the commit msg could help backporters understand the severity of the
issue.
> I have a few questions:
>
> 1. Is there a reason this hasn't been noticed before?
> As far as I can tell, there is currently no mainline device tree
> user that enables this driver on a platform with a real clock
> dependency. Out-of-tree users might be using it without any clock
> at all, or ACPI users might behave differently.
Ditto. I think we should drop the Fixes / CC: stable and instead
add a sentence that no upstream platform can currently trigger this.
> 2. Should we select PM in Kconfig and drop __maybe_unused from the
> PM callbacks? Since this driver relies on runtime PM for clock
> management, it seems odd to allow !PM builds.
I'm no PM expert but if it works for current users I don't see the need
to force the dependency?
> 3. Should we add a .remove callback to force suspend the device on
> unbind? Otherwise the clock might remain enabled if the driver is
> removed while active.
Embedded experts would have to chime in on this one. AFAIK this is a bit
of a gray area. Some users may want the link to stay up, eg to allow
WoL or avoid link training, maybe?
> I'm happy to send a follow-up patch addressing these points if you
> agree with the direction. Let me know what you think.
^ 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