* Re: [PATCH net] net: phy: qcom: at803x: Use the correct bit to disable extended next page
From: Andrew Lunn @ 2026-04-11 14:10 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, thomas.petazzoni, netdev, linux-kernel,
linux-arm-msm
In-Reply-To: <20260410171021.1277138-1-maxime.chevallier@bootlin.com>
On Fri, Apr 10, 2026 at 07:10:20PM +0200, Maxime Chevallier wrote:
> As noted in the blamed commit, the AR8035 and other PHYs from this
> family advertise the Extended Next Page support by default, which may be
> understood by some partners as this PHY being multi-gig capable.
>
> The fix is to disable XNP advertising, which is done by setting bit 12
> of the Auto-Negotiation Advertisement Register (MII_ADVERTISE).
>
> The blamed commit incorrectly uses MDIO_AN_CTRL1_XNP, which is bit 13 as per
> 802.3 : 45.2.7.1 AN control register (Register 7.0)
>
> BIT 12 in MII_ADVERTISE is wrapped by ADVERTISE_RESV, used by some
> drivers such as the aquantia one. 802.3 Clause 28 defines bit 12 as
> Extended Next Page ability, at least in recent versions of the standard.
> Let's add a define for it and use it in the at803x driver.
I agree with this, it defines the C22 4.12 bit. And this is what the
at803x driver is using it for.
> static void at803x_link_change_notify(struct phy_device *phydev)
> diff --git a/include/uapi/linux/mii.h b/include/uapi/linux/mii.h
> index 39f7c44baf53..61d6edad4b94 100644
> --- a/include/uapi/linux/mii.h
> +++ b/include/uapi/linux/mii.h
> @@ -82,7 +82,8 @@
> #define ADVERTISE_100BASE4 0x0200 /* Try for 100mbps 4k packets */
> #define ADVERTISE_PAUSE_CAP 0x0400 /* Try for pause */
> #define ADVERTISE_PAUSE_ASYM 0x0800 /* Try for asymetric pause */
> -#define ADVERTISE_RESV 0x1000 /* Unused... */
> +#define ADVERTISE_XNP 0x1000 /* Extended Next Page */
> +#define ADVERTISE_RESV ADVERTISE_XNP /* Used to be reserved */
Should we keep ADVERTISE_RESV?
45.2.7.6 AN advertisement register
If the Auto-Negotiation advertisement register (register 4) is
present, (see 28.2.4.1.3), then this register is a copy of the
Auto-Negotiation advertisement register (register 4). In this case,
reads to the AN advertisement register (7.16) report the value of
the Auto-Negotiation advertisement register (register 4); writes to
the AN advertisement register (7.16) cause a write to occur to the
Auto-Negotiation advertisement register.
So MDIO_MMD_AN:MDIO_AN_ADVERTISE is a straight copy of MII_ADVERTISE.
ef4_mdio_write(efx, MDIO_MMD_AN, MDIO_AN_ADVERTISE, reg);
ret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE, adv);
So ADVERTISE_XNP is just as valid in the other two drivers using
ADVERTISE_RESV. I think we should change those as well to
ADVERTISE_XNP and remove ADVERTISE_RESV?
Andrew
^ permalink raw reply
* [PATCH v2 net] openvswitch: fix vport netlink reply size for large upcall PID arrays
From: Weiming Shi @ 2026-04-11 14:14 UTC (permalink / raw)
To: Aaron Conole, Eelco Chaudron, Ilya Maximets
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Pravin B Shelar, Flavio Leitner, Mark Gray, netdev,
Xiang Mei, Weiming Shi
In-Reply-To: <v1-message-id>
The vport netlink reply helpers allocate a fixed-size skb with
nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID
array via ovs_vport_get_upcall_portids(). Since
ovs_vport_set_upcall_portids() accepts any non-zero multiple of
sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID
array large enough to overflow the reply buffer. On systems with
unprivileged user namespaces enabled (e.g., Ubuntu default), this is
reachable via unshare -Urn since all OVS vport genl operations use
GENL_UNS_ADMIN_PERM.
When the subsequent nla_put() fails with -EMSGSIZE, five BUG_ON(err < 0)
sites fire and panic the kernel:
kernel BUG at net/openvswitch/datapath.c:2414!
Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1
RIP: 0010:ovs_vport_cmd_set+0x34c/0x400
Call Trace:
<TASK>
genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116)
genl_rcv_msg (net/netlink/genetlink.c:1194)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
genl_rcv (net/netlink/genetlink.c:1219)
netlink_unicast (net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
__sys_sendto (net/socket.c:2206)
__x64_sys_sendto (net/socket.c:2209)
do_syscall_64 (arch/x86/entry/syscall_64.c:63)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
Kernel panic - not syncing: Fatal exception
Fix this by dynamically sizing the reply skb to account for the actual
PID array length, and replace the BUG_ON() calls with graceful error
returns.
Fixes: b83d23a2a38b ("openvswitch: Introduce per-cpu upcall dispatch")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
Changes in v2:
- Dynamically size reply skb instead of using fixed NLMSG_DEFAULT_SIZE.
- Drop WARN_ON_ONCE (still panics with panic_on_warn); use plain error
returns instead.
net/openvswitch/datapath.c | 102 +++++++++++++++++++++++++------------
net/openvswitch/vport.c | 12 +++++
net/openvswitch/vport.h | 1 +
3 files changed, 82 insertions(+), 33 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index e209099218b4..72e27a38d3a7 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -2184,9 +2184,11 @@ static int ovs_vport_cmd_fill_info(struct vport *vport, struct sk_buff *skb,
return err;
}
-static struct sk_buff *ovs_vport_cmd_alloc_info(void)
+static struct sk_buff *ovs_vport_cmd_alloc_info(struct vport *vport)
{
- return nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ return nlmsg_new(NLMSG_DEFAULT_SIZE +
+ ovs_vport_get_upcall_portids_size(vport),
+ GFP_KERNEL);
}
/* Called with ovs_mutex, only via ovs_dp_notify_wq(). */
@@ -2196,13 +2198,16 @@ struct sk_buff *ovs_vport_cmd_build_info(struct vport *vport, struct net *net,
struct sk_buff *skb;
int retval;
- skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ skb = ovs_vport_cmd_alloc_info(vport);
if (!skb)
return ERR_PTR(-ENOMEM);
retval = ovs_vport_cmd_fill_info(vport, skb, net, portid, seq, 0, cmd,
GFP_KERNEL);
- BUG_ON(retval < 0);
+ if (retval < 0) {
+ kfree_skb(skb);
+ return ERR_PTR(retval);
+ }
return skb;
}
@@ -2303,10 +2308,6 @@ static int ovs_vport_cmd_new(struct sk_buff *skb, struct genl_info *info)
if (port_no >= DP_MAX_PORTS)
return -EFBIG;
- reply = ovs_vport_cmd_alloc_info();
- if (!reply)
- return -ENOMEM;
-
ovs_lock();
restart:
dp = get_dp(sock_net(skb->sk), ovs_header->dp_ifindex);
@@ -2347,6 +2348,13 @@ static int ovs_vport_cmd_new(struct sk_buff *skb, struct genl_info *info)
goto exit_unlock_free;
}
+ reply = ovs_vport_cmd_alloc_info(vport);
+ if (!reply) {
+ ovs_dp_detach_port(vport);
+ err = -ENOMEM;
+ goto exit_unlock_free;
+ }
+
err = ovs_vport_cmd_fill_info(vport, reply, genl_info_net(info),
info->snd_portid, info->snd_seq, 0,
OVS_VPORT_CMD_NEW, GFP_KERNEL);
@@ -2358,7 +2366,11 @@ static int ovs_vport_cmd_new(struct sk_buff *skb, struct genl_info *info)
else
netdev_set_rx_headroom(vport->dev, dp->max_headroom);
- BUG_ON(err < 0);
+ if (err < 0) {
+ ovs_unlock();
+ kfree_skb(reply);
+ return err;
+ }
ovs_unlock();
ovs_notify(&dp_vport_genl_family, reply, info);
@@ -2366,7 +2378,6 @@ static int ovs_vport_cmd_new(struct sk_buff *skb, struct genl_info *info)
exit_unlock_free:
ovs_unlock();
- kfree_skb(reply);
return err;
}
@@ -2377,10 +2388,6 @@ static int ovs_vport_cmd_set(struct sk_buff *skb, struct genl_info *info)
struct vport *vport;
int err;
- reply = ovs_vport_cmd_alloc_info();
- if (!reply)
- return -ENOMEM;
-
ovs_lock();
vport = lookup_vport(sock_net(skb->sk), genl_info_userhdr(info), a);
err = PTR_ERR(vport);
@@ -2399,7 +2406,6 @@ static int ovs_vport_cmd_set(struct sk_buff *skb, struct genl_info *info)
goto exit_unlock_free;
}
-
if (a[OVS_VPORT_ATTR_UPCALL_PID]) {
struct nlattr *ids = a[OVS_VPORT_ATTR_UPCALL_PID];
@@ -2408,10 +2414,20 @@ static int ovs_vport_cmd_set(struct sk_buff *skb, struct genl_info *info)
goto exit_unlock_free;
}
+ reply = ovs_vport_cmd_alloc_info(vport);
+ if (!reply) {
+ err = -ENOMEM;
+ goto exit_unlock_free;
+ }
+
err = ovs_vport_cmd_fill_info(vport, reply, genl_info_net(info),
info->snd_portid, info->snd_seq, 0,
OVS_VPORT_CMD_SET, GFP_KERNEL);
- BUG_ON(err < 0);
+ if (err < 0) {
+ ovs_unlock();
+ kfree_skb(reply);
+ return err;
+ }
ovs_unlock();
ovs_notify(&dp_vport_genl_family, reply, info);
@@ -2419,7 +2435,6 @@ static int ovs_vport_cmd_set(struct sk_buff *skb, struct genl_info *info)
exit_unlock_free:
ovs_unlock();
- kfree_skb(reply);
return err;
}
@@ -2433,10 +2448,6 @@ static int ovs_vport_cmd_del(struct sk_buff *skb, struct genl_info *info)
unsigned int new_headroom;
int err;
- reply = ovs_vport_cmd_alloc_info();
- if (!reply)
- return -ENOMEM;
-
ovs_lock();
vport = lookup_vport(sock_net(skb->sk), genl_info_userhdr(info), a);
err = PTR_ERR(vport);
@@ -2448,10 +2459,20 @@ static int ovs_vport_cmd_del(struct sk_buff *skb, struct genl_info *info)
goto exit_unlock_free;
}
+ reply = ovs_vport_cmd_alloc_info(vport);
+ if (!reply) {
+ err = -ENOMEM;
+ goto exit_unlock_free;
+ }
+
err = ovs_vport_cmd_fill_info(vport, reply, genl_info_net(info),
info->snd_portid, info->snd_seq, 0,
OVS_VPORT_CMD_DEL, GFP_KERNEL);
- BUG_ON(err < 0);
+ if (err < 0) {
+ ovs_unlock();
+ kfree_skb(reply);
+ return err;
+ }
/* the vport deletion may trigger dp headroom update */
dp = vport->dp;
@@ -2474,7 +2495,6 @@ static int ovs_vport_cmd_del(struct sk_buff *skb, struct genl_info *info)
exit_unlock_free:
ovs_unlock();
- kfree_skb(reply);
return err;
}
@@ -2484,29 +2504,45 @@ static int ovs_vport_cmd_get(struct sk_buff *skb, struct genl_info *info)
struct ovs_header *ovs_header = genl_info_userhdr(info);
struct sk_buff *reply;
struct vport *vport;
+ size_t portids_size;
int err;
- reply = ovs_vport_cmd_alloc_info();
+ /* Get portids size under RCU, then allocate outside RCU
+ * since nlmsg_new(GFP_KERNEL) may sleep.
+ */
+ rcu_read_lock();
+ vport = lookup_vport(sock_net(skb->sk), ovs_header, a);
+ if (IS_ERR(vport)) {
+ err = PTR_ERR(vport);
+ rcu_read_unlock();
+ return err;
+ }
+ portids_size = ovs_vport_get_upcall_portids_size(vport);
+ rcu_read_unlock();
+
+ reply = nlmsg_new(NLMSG_DEFAULT_SIZE + portids_size, GFP_KERNEL);
if (!reply)
return -ENOMEM;
rcu_read_lock();
vport = lookup_vport(sock_net(skb->sk), ovs_header, a);
- err = PTR_ERR(vport);
- if (IS_ERR(vport))
- goto exit_unlock_free;
+ if (IS_ERR(vport)) {
+ err = PTR_ERR(vport);
+ rcu_read_unlock();
+ kfree_skb(reply);
+ return err;
+ }
err = ovs_vport_cmd_fill_info(vport, reply, genl_info_net(info),
info->snd_portid, info->snd_seq, 0,
OVS_VPORT_CMD_GET, GFP_ATOMIC);
- BUG_ON(err < 0);
rcu_read_unlock();
- return genlmsg_reply(reply, info);
+ if (err < 0) {
+ kfree_skb(reply);
+ return err;
+ }
-exit_unlock_free:
- rcu_read_unlock();
- kfree_skb(reply);
- return err;
+ return genlmsg_reply(reply, info);
}
static int ovs_vport_cmd_dump(struct sk_buff *skb, struct netlink_callback *cb)
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 23f629e94a36..57a6df7d6829 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -424,6 +424,18 @@ int ovs_vport_set_upcall_portids(struct vport *vport, const struct nlattr *ids)
return 0;
}
+int ovs_vport_get_upcall_portids_size(const struct vport *vport)
+{
+ struct vport_portids *ids;
+
+ ids = rcu_dereference_ovsl(vport->upcall_portids);
+
+ if (vport->dp->user_features & OVS_DP_F_VPORT_PIDS)
+ return nla_total_size(ids->n_ids * sizeof(u32));
+ else
+ return nla_total_size(sizeof(u32));
+}
+
/**
* ovs_vport_get_upcall_portids - get the upcall_portids of @vport.
*
diff --git a/net/openvswitch/vport.h b/net/openvswitch/vport.h
index 9f67b9dd49f9..ee674d59a9c6 100644
--- a/net/openvswitch/vport.h
+++ b/net/openvswitch/vport.h
@@ -38,6 +38,7 @@ int ovs_vport_set_options(struct vport *, struct nlattr *options);
int ovs_vport_get_options(const struct vport *, struct sk_buff *);
int ovs_vport_set_upcall_portids(struct vport *, const struct nlattr *pids);
+int ovs_vport_get_upcall_portids_size(const struct vport *vport);
int ovs_vport_get_upcall_portids(const struct vport *, struct sk_buff *);
u32 ovs_vport_find_upcall_portid(const struct vport *, struct sk_buff *);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] gcov: use atomic counter updates to fix concurrent access crashes
From: kernel test robot @ 2026-04-11 14:17 UTC (permalink / raw)
To: Konstantin Khorenko, Peter Oberparleiter, Mikhail Zaslonko,
Nathan Chancellor, Nicolas Schier
Cc: oe-kbuild-all, Masahiro Yamada, Thomas Weißschuh,
Arnd Bergmann, Steffen Klassert, Herbert Xu, linux-kbuild,
linux-kernel, netdev, Konstantin Khorenko, Pavel Tikhomirov,
Vasileios Almpanis, Jakub Kicinski
In-Reply-To: <20260402141831.1437357-2-khorenko@virtuozzo.com>
Hi Konstantin,
kernel test robot noticed the following build warnings:
[auto build test WARNING on soc/for-next]
[also build test WARNING on linus/master v7.0-rc7 next-20260410]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Konstantin-Khorenko/gcov-use-atomic-counter-updates-to-fix-concurrent-access-crashes/20260411-133428
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
patch link: https://lore.kernel.org/r/20260402141831.1437357-2-khorenko%40virtuozzo.com
patch subject: [PATCH] gcov: use atomic counter updates to fix concurrent access crashes
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20260411/202604111946.Erd3tguU-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260411/202604111946.Erd3tguU-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202604111946.Erd3tguU-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> io_uring/io_uring.c:3224:1: warning: target does not support atomic profile update, single mode is selected
3224 | __initcall(io_uring_init);
| ^~~~~~~~~~
--
>> io_uring/opdef.c:890:1: warning: target does not support atomic profile update, single mode is selected
890 | }
| ^
--
>> io_uring/kbuf.c:740:1: warning: target does not support atomic profile update, single mode is selected
740 | }
| ^
--
>> io_uring/rsrc.c:1555:1: warning: target does not support atomic profile update, single mode is selected
1555 | }
| ^
--
>> io_uring/notif.c:141:1: warning: target does not support atomic profile update, single mode is selected
141 | }
| ^
--
>> io_uring/tctx.c:388:1: warning: target does not support atomic profile update, single mode is selected
388 | }
| ^
--
>> io_uring/filetable.c:158:1: warning: target does not support atomic profile update, single mode is selected
158 | }
| ^
--
>> io_uring/rw.c:1397:1: warning: target does not support atomic profile update, single mode is selected
1397 | }
| ^
--
>> io_uring/poll.c:963:1: warning: target does not support atomic profile update, single mode is selected
963 | }
| ^
--
>> io_uring/tw.c:355:1: warning: target does not support atomic profile update, single mode is selected
355 | }
| ^
--
>> io_uring/wait.c:308:1: warning: target does not support atomic profile update, single mode is selected
308 | }
| ^
..
vim +3224 io_uring/io_uring.c
76d3ccecfa186a io_uring/io_uring.c Matteo Rizzo 2023-08-21 3221
2b188cc1bb857a fs/io_uring.c Jens Axboe 2019-01-07 3222 return 0;
2b188cc1bb857a fs/io_uring.c Jens Axboe 2019-01-07 3223 };
2b188cc1bb857a fs/io_uring.c Jens Axboe 2019-01-07 @3224 __initcall(io_uring_init);
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH net-next v2] net: phy: call phy_init_hw() in phy resume path
From: Biju @ 2026-04-11 14:29 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Biju Das, Russell King, netdev, linux-kernel, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc, Ovidiu Panait
From: Biju Das <biju.das.jz@bp.renesas.com>
When mac_managed_pm flag is set, mdio_bus_phy_resume() is skipped, so
phy_init_hw(), which performs soft_reset and config_init, is not called
during resume.
This is inconsistent with the non-mac_managed_pm path, where
mdio_bus_phy_resume() calls phy_init_hw() before phy_resume() on every
resume.
To align both paths, move the phy_init_hw() call into phy_resume() itself,
before invoking the driver's resume callback. This ensures PHY soft reset
and re-initialization happen unconditionally, regardless of whether PM is
managed by the MAC or the MDIO bus. As a result, drop the redundant
phy_init_hw() call in mdio_bus_phy_resume().
Additionally, in phy_attach_direct(), replace the separate phy_init_hw()
and phy_resume() calls with a single phy_resume() call, since
phy_init_hw() is now handled inside phy_resume().
Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Updated commit description.
* phy_init_hw() is moved from __phy_resume() -> phy_resume() to make it
lock-free.
* Dropped redundant phy_init_hw() call from mdio_bus_phy_resume() and
phy_attach_direct().
---
drivers/net/phy/phy_device.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 0edff47478c2..4a2b19d39373 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -396,10 +396,6 @@ static __maybe_unused int mdio_bus_phy_resume(struct device *dev)
WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY &&
phydev->state != PHY_UP);
- ret = phy_init_hw(phydev);
- if (ret < 0)
- return ret;
-
ret = phy_resume(phydev);
if (ret < 0)
return ret;
@@ -1857,16 +1853,14 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
if (dev)
netif_carrier_off(phydev->attached_dev);
- /* Do initial configuration here, now that
+ /* Do initial configuration inside phy_init_hw(), now that
* we have certain key parameters
* (dev_flags and interface)
*/
- err = phy_init_hw(phydev);
+ err = phy_resume(phydev);
if (err)
goto error;
- phy_resume(phydev);
-
/**
* If the external phy used by current mac interface is managed by
* another mac interface, so we should create a device link between
@@ -2020,6 +2014,10 @@ int phy_resume(struct phy_device *phydev)
{
int ret;
+ ret = phy_init_hw(phydev);
+ if (ret)
+ return ret;
+
mutex_lock(&phydev->lock);
ret = __phy_resume(phydev);
mutex_unlock(&phydev->lock);
--
2.43.0
^ permalink raw reply related
* RE: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path
From: Biju Das @ 2026-04-11 14:32 UTC (permalink / raw)
To: Andrew Lunn, Russell King (Oracle)
Cc: biju.das.au, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Ovidiu Panait,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <dedab35c-39f4-469b-9227-cb8925d83b8e@lunn.ch>
Hi Andrew,
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 11 April 2026 14:50
> Subject: Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path
>
> > So, I question whether any of the functions in this driver actually
> > have a valid reason to take phydev->lock - looks to me like a not very
> > well written driver.
> >
> > In cases like this, I don't think we should make things more difficult
> > in the core just because we have a lockdep splat when that can be
> > avoided by killing off unnecessary locking.
>
> Agreed. This patchset should cleanup these locks.
OK, I will send a patch for removing these locks.
Cheers,
Biju
^ permalink raw reply
* Re: [PATTCH net v5 6/8] net/sched: netem: null-terminate tfifo linear queue tail
From: Stephen Hemminger @ 2026-04-11 14:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, Simon Horman, Jamal Hadi Salim, Jiri Pirko,
David S. Miller, Jakub Kicinski, Paolo Abeni, Peter Oskolkov,
open list
In-Reply-To: <CANn89iJeS-Hw7NNouSWYw6BZvTUG=-grVxAiYzg8a8pEO_LJXQ@mail.gmail.com>
On Fri, 10 Apr 2026 23:38:08 -0700
Eric Dumazet <edumazet@google.com> wrote:
> On Fri, Apr 10, 2026 at 10:17 PM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > When tfifo_enqueue() appends a packet to the linear queue tail,
> > nskb->next is never set to NULL. The list terminates correctly
> > only by accident if the skb arrived with next already NULL.
> >
> > Explicitly null-terminate the tail to prevent list corruption.
> >
> > Fixes: d66280b12bd7 ("net: netem: use a list in addition to rbtree")
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > Reviewed-by: Simon Horman <horms@kernel.org>
>
> Can you explain how skb->next could be not NULL ?
>
> This would be a bug in the upper stack.
>
> Only TCQ_F_NOLOCK qdiscs (pfifo_fast) can possibly get such skbs, and
> it would not care.
>
> Other qdiscs already get skbs with skb_mark_not_on_list(skb).
Thanks, this patch came from a false positive from one of the
review prompts. Dropping it.
^ permalink raw reply
* [PATCH 1/1] net: strparser: fix skb_head leak in strp_abort_strp()
From: Ren Wei @ 2026-04-11 15:10 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, nate.karstens, sd, linux,
Julia.Lawall, tom, yifanwucs, tomapufckgml, yuantan098, bird,
rakukuip, n05ec
In-Reply-To: <cover.1775482694.git.rakukuip@gmail.com>
From: Luxiao Xu <rakukuip@gmail.com>
When the stream parser is aborted, for example after a message assembly timeout,
it can still hold a reference to a partially assembled message in
strp->skb_head.
That skb is not released in strp_abort_strp(), which leaks the partially
assembled message and can be triggered repeatedly to exhaust memory.
Fix this by freeing strp->skb_head and resetting the parser state in the
abort path. Leave strp_stop() unchanged so final cleanup still happens in
strp_done() after the work and timer have been synchronized.
Fixes: 43a0c6751a32 ("strparser: Stream parser for messages")
Cc: stable@kernel.org
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Luxiao Xu <rakukuip@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/strparser/strparser.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/net/strparser/strparser.c b/net/strparser/strparser.c
index fe0e76fdd1f1..a23f4b4dfc67 100644
--- a/net/strparser/strparser.c
+++ b/net/strparser/strparser.c
@@ -45,6 +45,14 @@ static void strp_abort_strp(struct strparser *strp, int err)
strp->stopped = 1;
+ if (strp->skb_head) {
+ kfree_skb(strp->skb_head);
+ strp->skb_head = NULL;
+ }
+
+ strp->skb_nextp = NULL;
+ strp->need_bytes = 0;
+
if (strp->sk) {
struct sock *sk = strp->sk;
--
2.43.0
^ permalink raw reply related
* [PATCH net 1/1] net: caif: clear client service pointer on teardown
From: Ren Wei @ 2026-04-11 15:10 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, sjur.brandeland, yifanwucs,
tomapufckgml, yuantan098, bird, enjou1224z, zcliangcn, n05ec
In-Reply-To: <cover.1775897577.git.zcliangcn@gmail.com>
From: Zhengchuan Liang <zcliangcn@gmail.com>
`caif_connect()` can tear down an existing client after remote shutdown by
calling `caif_disconnect_client()` followed by `caif_free_client()`.
`caif_free_client()` releases the service layer referenced by
`adap_layer->dn`, but leaves that pointer stale.
When the socket is later destroyed, `caif_sock_destructor()` calls
`caif_free_client()` again and dereferences the freed service pointer.
Clear the client/service links before releasing the service object so
repeated teardown becomes harmless.
Fixes: 43e369210108 ("caif: Move refcount from service layer to sock and dev.")
Cc: stable@kernel.org
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/caif/cfsrvl.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/caif/cfsrvl.c b/net/caif/cfsrvl.c
index 171fa32ada85c..d687fd0b4ed3a 100644
--- a/net/caif/cfsrvl.c
+++ b/net/caif/cfsrvl.c
@@ -191,10 +191,20 @@ bool cfsrvl_phyid_match(struct cflayer *layer, int phyid)
void caif_free_client(struct cflayer *adap_layer)
{
+ struct cflayer *serv_layer;
struct cfsrvl *servl;
- if (adap_layer == NULL || adap_layer->dn == NULL)
+
+ if (!adap_layer)
+ return;
+
+ serv_layer = adap_layer->dn;
+ if (!serv_layer)
return;
- servl = container_obj(adap_layer->dn);
+
+ layer_set_dn(adap_layer, NULL);
+ layer_set_up(serv_layer, NULL);
+
+ servl = container_obj(serv_layer);
servl->release(&servl->layer);
}
EXPORT_SYMBOL(caif_free_client);
--
2.43.0
^ permalink raw reply related
* [PATCH next-next] net: phy: mscc: Drop redundant phydev->lock
From: Biju @ 2026-04-11 15:49 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Biju Das, Russell King, Lad Prabhakar, Horatiu Vultur,
Vladimir Oltean, netdev, linux-kernel, Geert Uytterhoeven,
Biju Das, linux-renesas-soc
From: Biju Das <biju.das.jz@bp.renesas.com>
Remove manual mutex_lock/unlock(&phydev->lock) calls from several
functions in the MSCC PHY driver, as the PHY core already holds this lock
when invoking these callbacks.
The affected functions are:
vsc85xx_edge_rate_cntl_set() — lock/unlock around phy_modify_paged()
vsc85xx_mac_if_set() — lock/unlock with a goto out_unlock error path
vsc8531_pre_init_seq_set() — lock/unlock around phy_select/restore_page()
vsc85xx_eee_init_seq_set() — lock/unlock around phy_select/restore_page()
Along with dropping the locks, error-path labels are renamed from
out_unlock to err or restore_oldpage to better reflect their purpose now
that no unlocking is performed. In vsc8531_pre_init_seq_set() and
vsc85xx_eee_init_seq_set(), the redundant intermediate assignment of
oldpage before returning is also eliminated.
No functional change intended.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Note: Only boot tested on Renesas RZ/{T2H,N2H} platform.
---
drivers/net/phy/mscc/mscc_main.c | 41 ++++++++++----------------------
1 file changed, 12 insertions(+), 29 deletions(-)
diff --git a/drivers/net/phy/mscc/mscc_main.c b/drivers/net/phy/mscc/mscc_main.c
index 2b9fb8a675a6..75430f55acfd 100644
--- a/drivers/net/phy/mscc/mscc_main.c
+++ b/drivers/net/phy/mscc/mscc_main.c
@@ -486,15 +486,9 @@ static int vsc85xx_dt_led_modes_get(struct phy_device *phydev,
static int vsc85xx_edge_rate_cntl_set(struct phy_device *phydev, u8 edge_rate)
{
- int rc;
-
- mutex_lock(&phydev->lock);
- rc = phy_modify_paged(phydev, MSCC_PHY_PAGE_EXTENDED_2,
- MSCC_PHY_WOL_MAC_CONTROL, EDGE_RATE_CNTL_MASK,
- edge_rate << EDGE_RATE_CNTL_POS);
- mutex_unlock(&phydev->lock);
-
- return rc;
+ return phy_modify_paged(phydev, MSCC_PHY_PAGE_EXTENDED_2,
+ MSCC_PHY_WOL_MAC_CONTROL, EDGE_RATE_CNTL_MASK,
+ edge_rate << EDGE_RATE_CNTL_POS);
}
static int vsc85xx_mac_if_set(struct phy_device *phydev,
@@ -503,7 +497,6 @@ static int vsc85xx_mac_if_set(struct phy_device *phydev,
int rc;
u16 reg_val;
- mutex_lock(&phydev->lock);
reg_val = phy_read(phydev, MSCC_PHY_EXT_PHY_CNTL_1);
reg_val &= ~(MAC_IF_SELECTION_MASK);
switch (interface) {
@@ -522,17 +515,15 @@ static int vsc85xx_mac_if_set(struct phy_device *phydev,
break;
default:
rc = -EINVAL;
- goto out_unlock;
+ goto err;
}
rc = phy_write(phydev, MSCC_PHY_EXT_PHY_CNTL_1, reg_val);
if (rc)
- goto out_unlock;
+ goto err;
rc = genphy_soft_reset(phydev);
-out_unlock:
- mutex_unlock(&phydev->lock);
-
+err:
return rc;
}
@@ -668,19 +659,15 @@ static int vsc8531_pre_init_seq_set(struct phy_device *phydev)
if (rc < 0)
return rc;
- mutex_lock(&phydev->lock);
oldpage = phy_select_page(phydev, MSCC_PHY_PAGE_TR);
if (oldpage < 0)
- goto out_unlock;
+ goto restore_oldpage;
for (i = 0; i < ARRAY_SIZE(init_seq); i++)
vsc85xx_tr_write(phydev, init_seq[i].reg, init_seq[i].val);
-out_unlock:
- oldpage = phy_restore_page(phydev, oldpage, oldpage);
- mutex_unlock(&phydev->lock);
-
- return oldpage;
+restore_oldpage:
+ return phy_restore_page(phydev, oldpage, oldpage);
}
static int vsc85xx_eee_init_seq_set(struct phy_device *phydev)
@@ -708,19 +695,15 @@ static int vsc85xx_eee_init_seq_set(struct phy_device *phydev)
unsigned int i;
int oldpage;
- mutex_lock(&phydev->lock);
oldpage = phy_select_page(phydev, MSCC_PHY_PAGE_TR);
if (oldpage < 0)
- goto out_unlock;
+ goto restore_oldpage;
for (i = 0; i < ARRAY_SIZE(init_eee); i++)
vsc85xx_tr_write(phydev, init_eee[i].reg, init_eee[i].val);
-out_unlock:
- oldpage = phy_restore_page(phydev, oldpage, oldpage);
- mutex_unlock(&phydev->lock);
-
- return oldpage;
+restore_oldpage:
+ return phy_restore_page(phydev, oldpage, oldpage);
}
/* phydev->bus->mdio_lock should be locked when using this function */
--
2.43.0
^ permalink raw reply related
* [PATCH net-next] r8169: Drop redundant phy_init_hw() call in rtl8169_up()
From: Biju @ 2026-04-11 16:07 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Biju Das, netdev, linux-kernel, Geert Uytterhoeven,
Prabhakar Mahadev Lad, Biju Das, linux-renesas-soc
From: Biju Das <biju.das.jz@bp.renesas.com>
phy_resume() called immediately after already invokes phy_init_hw()
internally as part of the resume sequence. Remove the explicit
phy_init_hw() call in rtl8169_up() as it is redundant.
No functional change intended.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
This patch depend upon [1]
[1] https://lore.kernel.org/all/20260411142956.88343-1-biju.das.jz@bp.renesas.com/
---
drivers/net/ethernet/realtek/r8169_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 791277e750ba..cb22105f323f 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5032,7 +5032,6 @@ static void rtl8169_up(struct rtl8169_private *tp)
rtl8168_driver_start(tp);
pci_set_master(tp->pci_dev);
- phy_init_hw(tp->phydev);
phy_resume(tp->phydev);
rtl8169_init_phy(tp);
napi_enable(&tp->napi);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next] net: phy: call phy_init_hw() in phy resume path
From: Russell King (Oracle) @ 2026-04-11 16:46 UTC (permalink / raw)
To: Andrew Lunn
Cc: Biju Das, biju.das.au, Heiner Kallweit, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Ovidiu Panait,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <dedab35c-39f4-469b-9227-cb8925d83b8e@lunn.ch>
On Sat, Apr 11, 2026 at 03:50:13PM +0200, Andrew Lunn wrote:
> > So, I question whether any of the functions in this driver actually
> > have a valid reason to take phydev->lock - looks to me like a not
> > very well written driver.
> >
> > In cases like this, I don't think we should make things more
> > difficult in the core just because we have a lockdep splat when that
> > can be avoided by killing off unnecessary locking.
>
> Agreed. This patchset should cleanup these locks.
>
> We also need to look at lan937x_dsp_workaround(). I also don't see
> what that mutex lock/unlock is protecting. Accessing bank registers
> need to be protected, so doing one additional access within that
> should not need additional protection.
Looking at access_ereg(), shouldn't it be taking the MDIO bus lock
and using the __phy_* accessors anyway because it's writing various
registers which determine what is being read via the
LAN87XX_EXT_REG_RD_DATA register or the value written via the
LAN87XX_EXT_REG_WR_DATA register.
Also, as it has access_ereg_modify_changed(), that entire sequence
needs to take the MDIO bus lock to safely do the read-modify-write.
Then there's lan87xx_config_rgmii_delay() which is a large open
coded read-modify-write for the PHYACC_ATTR_BANK_MISC, LAN87XX_CTRL_1
register.
To me, this looks like a racy driver, and it also looks like it's using
the wrong lock to try and protect hardware accesses.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net] net: phy: qcom: at803x: Use the correct bit to disable extended next page
From: Maxime Chevallier @ 2026-04-11 16:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, thomas.petazzoni, netdev, linux-kernel,
linux-arm-msm
In-Reply-To: <4b386a4a-9743-4e79-8d3d-3576bb9de492@lunn.ch>
Hi Andrew,
On 11/04/2026 16:10, Andrew Lunn wrote:
> On Fri, Apr 10, 2026 at 07:10:20PM +0200, Maxime Chevallier wrote:
>> As noted in the blamed commit, the AR8035 and other PHYs from this
>> family advertise the Extended Next Page support by default, which may be
>> understood by some partners as this PHY being multi-gig capable.
>>
>> The fix is to disable XNP advertising, which is done by setting bit 12
>> of the Auto-Negotiation Advertisement Register (MII_ADVERTISE).
>>
>> The blamed commit incorrectly uses MDIO_AN_CTRL1_XNP, which is bit 13 as per
>> 802.3 : 45.2.7.1 AN control register (Register 7.0)
>>
>> BIT 12 in MII_ADVERTISE is wrapped by ADVERTISE_RESV, used by some
>> drivers such as the aquantia one. 802.3 Clause 28 defines bit 12 as
>> Extended Next Page ability, at least in recent versions of the standard.
>
>> Let's add a define for it and use it in the at803x driver.
>
> I agree with this, it defines the C22 4.12 bit. And this is what the
> at803x driver is using it for.
>
>> static void at803x_link_change_notify(struct phy_device *phydev)
>> diff --git a/include/uapi/linux/mii.h b/include/uapi/linux/mii.h
>> index 39f7c44baf53..61d6edad4b94 100644
>> --- a/include/uapi/linux/mii.h
>> +++ b/include/uapi/linux/mii.h
>> @@ -82,7 +82,8 @@
>> #define ADVERTISE_100BASE4 0x0200 /* Try for 100mbps 4k packets */
>> #define ADVERTISE_PAUSE_CAP 0x0400 /* Try for pause */
>> #define ADVERTISE_PAUSE_ASYM 0x0800 /* Try for asymetric pause */
>> -#define ADVERTISE_RESV 0x1000 /* Unused... */
>> +#define ADVERTISE_XNP 0x1000 /* Extended Next Page */
>> +#define ADVERTISE_RESV ADVERTISE_XNP /* Used to be reserved */
>
> Should we keep ADVERTISE_RESV?
>
> 45.2.7.6 AN advertisement register
>
> If the Auto-Negotiation advertisement register (register 4) is
> present, (see 28.2.4.1.3), then this register is a copy of the
> Auto-Negotiation advertisement register (register 4). In this case,
> reads to the AN advertisement register (7.16) report the value of
> the Auto-Negotiation advertisement register (register 4); writes to
> the AN advertisement register (7.16) cause a write to occur to the
> Auto-Negotiation advertisement register.
>
> So MDIO_MMD_AN:MDIO_AN_ADVERTISE is a straight copy of MII_ADVERTISE.
>
> ef4_mdio_write(efx, MDIO_MMD_AN, MDIO_AN_ADVERTISE, reg);
> ret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE, adv);
>
> So ADVERTISE_XNP is just as valid in the other two drivers using
> ADVERTISE_RESV. I think we should change those as well to
> ADVERTISE_XNP and remove ADVERTISE_RESV?
>
> Andrew
I agree with that yes and I've considered converting these drivers once
we have net merged into net-next should this patch be applied :)
That said, ADVERTISE_RESV is in uapi, is it even possible to remove it ?
I think the best we can hope for is to no longer have in-tree users of
ADVERTISE_RESV :(
Maxime
^ permalink raw reply
* [RFC PATCH] bpf: cpumap: report queue_index to xdp_rxq_info
From: Jose A. Perez de Azpillaga @ 2026-04-11 17:51 UTC (permalink / raw)
To: bpf
Cc: Madalin Bucur, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
netdev, linux-kernel
When a packet is redirected to a CPU map entry,
cpu_map_bpf_prog_run_xdp() reconstructs a minimal xdp_rxq_info from
xdp_frame fields (dev_rx and mem_type) before re-running the BPF program
on the target CPU. However, queue_index was never preserved across the
CPU boundary, so BPF programs running in cpumap context always observe
ctx->rx_queue_index == 0, regardless of which hardware queue originally
received the packet.
Fix this by storing the originating queue_index in struct xdp_frame,
following the same pattern already established for dev_rx and mem_type.
The field is populated from rxq->queue_index in
xdp_convert_buff_to_frame() during NAPI context, when the rxq_info is
still valid, and restored into the reconstructed rxq_info in
cpu_map_bpf_prog_run_xdp().
Also use xdpf->queue_index in __xdp_build_skb_from_frame() to call
skb_record_rx_queue(), which was previously listed as missing
information in that function's comment.
Also propagate queue_index in dpaa_a050385_wa_xdpf(), which manually
constructs a new xdp_frame from an uninitialized page. Without this,
queue_index would contain stale data from the page allocator.
Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
---
Note: this patch was only compiled, not tested.
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 +
include/net/xdp.h | 4 +++-
kernel/bpf/cpumap.c | 2 +-
net/core/xdp.c | 2 +-
4 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 3edc8d142dd5..00e36b0ac74d 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2281,6 +2281,7 @@ static int dpaa_a050385_wa_xdpf(struct dpaa_priv *priv,
new_xdpf->headroom = priv->tx_headroom;
new_xdpf->frame_sz = DPAA_BP_RAW_SIZE;
new_xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
+ new_xdpf->queue_index = xdpf->queue_index;
/* Release the initial buffer */
xdp_return_frame_rx_napi(xdpf);
diff --git a/include/net/xdp.h b/include/net/xdp.h
index aa742f413c35..6db10e6a8864 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -297,10 +297,11 @@ struct xdp_frame {
u32 headroom;
u32 metasize; /* uses lower 8-bits */
/* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
- * while mem_type is valid on remote CPU.
+ * while mem_type and queue_index are valid on remote CPU.
*/
enum xdp_mem_type mem_type:32;
struct net_device *dev_rx; /* used by cpumap */
+ u32 queue_index; /* used by cpumap */
u32 frame_sz;
u32 flags; /* supported values defined in xdp_buff_flags */
};
@@ -441,6 +442,7 @@ struct xdp_frame *xdp_convert_buff_to_frame(struct xdp_buff *xdp)
/* rxq only valid until napi_schedule ends, convert to xdp_mem_type */
xdp_frame->mem_type = xdp->rxq->mem.type;
+ xdp_frame->queue_index = xdp->rxq->queue_index;
return xdp_frame;
}
diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
index 5e59ab896f05..448da572de9a 100644
--- a/kernel/bpf/cpumap.c
+++ b/kernel/bpf/cpumap.c
@@ -197,7 +197,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu,
rxq.dev = xdpf->dev_rx;
rxq.mem.type = xdpf->mem_type;
- /* TODO: report queue_index to xdp_rxq_info */
+ rxq.queue_index = xdpf->queue_index;
xdp_convert_frame_to_buff(xdpf, &xdp);
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 9890a30584ba..326e3057ed7f 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -829,11 +829,11 @@ struct sk_buff *__xdp_build_skb_from_frame(struct xdp_frame *xdpf,
/* Essential SKB info: protocol and skb->dev */
skb->protocol = eth_type_trans(skb, dev);
+ skb_record_rx_queue(skb, xdpf->queue_index);
/* Optional SKB info, currently missing:
* - HW checksum info (skb->ip_summed)
* - HW RX hash (skb_set_hash)
- * - RX ring dev queue index (skb_record_rx_queue)
*/
if (xdpf->mem_type == MEM_TYPE_PAGE_POOL)
--
2.53.0
^ permalink raw reply related
* Re: [RFC PATCH] bpf: cpumap: report queue_index to xdp_rxq_info
From: Alexei Starovoitov @ 2026-04-11 18:09 UTC (permalink / raw)
To: Jose A. Perez de Azpillaga
Cc: bpf, Madalin Bucur, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Network Development, LKML
In-Reply-To: <20260411175134.771552-1-azpijr@gmail.com>
On Sat, Apr 11, 2026 at 10:51 AM Jose A. Perez de Azpillaga
<azpijr@gmail.com> wrote:
>
> When a packet is redirected to a CPU map entry,
> cpu_map_bpf_prog_run_xdp() reconstructs a minimal xdp_rxq_info from
> xdp_frame fields (dev_rx and mem_type) before re-running the BPF program
> on the target CPU. However, queue_index was never preserved across the
> CPU boundary, so BPF programs running in cpumap context always observe
> ctx->rx_queue_index == 0, regardless of which hardware queue originally
> received the packet.
>
> Fix this by storing the originating queue_index in struct xdp_frame,
> following the same pattern already established for dev_rx and mem_type.
> The field is populated from rxq->queue_index in
> xdp_convert_buff_to_frame() during NAPI context, when the rxq_info is
> still valid, and restored into the reconstructed rxq_info in
> cpu_map_bpf_prog_run_xdp().
>
> Also use xdpf->queue_index in __xdp_build_skb_from_frame() to call
> skb_record_rx_queue(), which was previously listed as missing
> information in that function's comment.
>
> Also propagate queue_index in dpaa_a050385_wa_xdpf(), which manually
> constructs a new xdp_frame from an uninitialized page. Without this,
> queue_index would contain stale data from the page allocator.
>
> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> ---
> Note: this patch was only compiled, not tested.
>
> drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 +
> include/net/xdp.h | 4 +++-
> kernel/bpf/cpumap.c | 2 +-
> net/core/xdp.c | 2 +-
> 4 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> index 3edc8d142dd5..00e36b0ac74d 100644
> --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> @@ -2281,6 +2281,7 @@ static int dpaa_a050385_wa_xdpf(struct dpaa_priv *priv,
> new_xdpf->headroom = priv->tx_headroom;
> new_xdpf->frame_sz = DPAA_BP_RAW_SIZE;
> new_xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
> + new_xdpf->queue_index = xdpf->queue_index;
>
> /* Release the initial buffer */
> xdp_return_frame_rx_napi(xdpf);
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index aa742f413c35..6db10e6a8864 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -297,10 +297,11 @@ struct xdp_frame {
> u32 headroom;
> u32 metasize; /* uses lower 8-bits */
> /* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
> - * while mem_type is valid on remote CPU.
> + * while mem_type and queue_index are valid on remote CPU.
> */
> enum xdp_mem_type mem_type:32;
> struct net_device *dev_rx; /* used by cpumap */
> + u32 queue_index; /* used by cpumap */
> u32 frame_sz;
> u32 flags; /* supported values defined in xdp_buff_flags */
> };
> @@ -441,6 +442,7 @@ struct xdp_frame *xdp_convert_buff_to_frame(struct xdp_buff *xdp)
>
> /* rxq only valid until napi_schedule ends, convert to xdp_mem_type */
> xdp_frame->mem_type = xdp->rxq->mem.type;
> + xdp_frame->queue_index = xdp->rxq->queue_index;
>
> return xdp_frame;
> }
> diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
> index 5e59ab896f05..448da572de9a 100644
> --- a/kernel/bpf/cpumap.c
> +++ b/kernel/bpf/cpumap.c
> @@ -197,7 +197,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu,
>
> rxq.dev = xdpf->dev_rx;
> rxq.mem.type = xdpf->mem_type;
> - /* TODO: report queue_index to xdp_rxq_info */
> + rxq.queue_index = xdpf->queue_index;
This is like 5th time people attempt to address this TODO.
Just remove that comment. Don't send broken patches.
pw-bot: cr
^ permalink raw reply
* Re: [RFC PATCH] bpf: cpumap: report queue_index to xdp_rxq_info
From: bot+bpf-ci @ 2026-04-11 18:30 UTC (permalink / raw)
To: azpijr, bpf
Cc: madalin.bucur, andrew+netdev, davem, edumazet, kuba, pabeni, ast,
daniel, hawk, john.fastabend, sdf, horms, andrii, martin.lau,
eddyz87, memxor, song, yonghong.song, jolsa, netdev, linux-kernel,
ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260411175134.771552-1-azpijr@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -297,10 +297,11 @@ struct xdp_frame {
> u32 headroom;
> u32 metasize; /* uses lower 8-bits */
> /* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
> - * while mem_type is valid on remote CPU.
> + * while mem_type and queue_index are valid on remote CPU.
> */
> enum xdp_mem_type mem_type:32;
> struct net_device *dev_rx; /* used by cpumap */
> + u32 queue_index; /* used by cpumap */
> u32 frame_sz;
> u32 flags; /* supported values defined in xdp_buff_flags */
> };
Is the updated comment accurate for all paths?
xdp_convert_buff_to_frame() has an early return for the zero-copy
path:
if (xdp->rxq->mem.type == MEM_TYPE_XSK_BUFF_POOL)
return xdp_convert_zc_to_xdp_frame(xdp);
xdp_convert_zc_to_xdp_frame() zeroes the frame with memset and
explicitly sets mem_type but never sets queue_index:
net/core/xdp.c:xdp_convert_zc_to_xdp_frame() {
...
memset(xdpf, 0, sizeof(*xdpf));
...
xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
/* queue_index is not set -- remains 0 from memset */
...
}
The comment says queue_index is "valid on remote CPU" but for
zero-copy converted frames it will always be 0 regardless of which
hardware queue originated the packet.
> @@ -441,6 +442,7 @@ struct xdp_frame *xdp_convert_buff_to_frame(struct xdp_buff *xdp)
>
> /* rxq only valid until napi_schedule ends, convert to xdp_mem_type */
> xdp_frame->mem_type = xdp->rxq->mem.type;
> + xdp_frame->queue_index = xdp->rxq->queue_index;
>
> return xdp_frame;
This assignment is only reached for the non-ZC path. Should
xdp_convert_zc_to_xdp_frame() also set queue_index from
xdp->rxq->queue_index to match?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24288456014
^ permalink raw reply
* [PATCH] netfilter: nfnl_cthelper: apply per-class values when updating policies
From: David Carlier @ 2026-04-11 18:57 UTC (permalink / raw)
To: pablo
Cc: fw, phil, kadlec, netfilter-devel, coreteam, netdev, linux-kernel,
David Carlier, stable
When a userspace conntrack helper with multiple expectation classes is
updated via nfnetlink, every class ends up with the first class's
max_expected and timeout values.
nfnl_cthelper_update_policy_all() validates each new policy into the
corresponding slot of the temporary new_policy array, but the second
loop that commits the values into the live helper dereferences
new_policy as a pointer instead of indexing it, so every iteration
reads new_policy[0] regardless of i. An update that changes per-class
values is silently collapsed onto class 0's values with no error
returned to userspace.
Index the temporary array by i in the commit loop so each class gets
its own validated values.
Fixes: 2c422257550f ("netfilter: nfnl_cthelper: fix runtime expectation policy updates")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier <devnexen@gmail.com>
---
net/netfilter/nfnetlink_cthelper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nfnetlink_cthelper.c b/net/netfilter/nfnetlink_cthelper.c
index 0d16ad82d70c..34af6840803e 100644
--- a/net/netfilter/nfnetlink_cthelper.c
+++ b/net/netfilter/nfnetlink_cthelper.c
@@ -346,8 +346,8 @@ static int nfnl_cthelper_update_policy_all(struct nlattr *tb[],
for (i = 0; i < helper->expect_class_max + 1; i++) {
policy = (struct nf_conntrack_expect_policy *)
&helper->expect_policy[i];
- policy->max_expected = new_policy->max_expected;
- policy->timeout = new_policy->timeout;
+ policy->max_expected = new_policy[i].max_expected;
+ policy->timeout = new_policy[i].timeout;
}
err:
--
2.53.0
^ permalink raw reply related
* Re: [RFC PATCH] bpf: cpumap: report queue_index to xdp_rxq_info
From: Jose A. Perez de Azpillaga @ 2026-04-11 19:10 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: bpf, Madalin Bucur, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Simon Horman, Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Network Development, LKML
In-Reply-To: <CAADnVQJOKc0zP4=-STEX0szgzUeS7RaxQTtre=P92R0UStug8A@mail.gmail.com>
On Sat, Apr 11, 2026 at 11:09:56AM -0700, Alexei Starovoitov wrote:
> On Sat, Apr 11, 2026 at 10:51 AM Jose A. Perez de Azpillaga
> <azpijr@gmail.com> wrote:
> >
> > When a packet is redirected to a CPU map entry,
> > cpu_map_bpf_prog_run_xdp() reconstructs a minimal xdp_rxq_info from
> > xdp_frame fields (dev_rx and mem_type) before re-running the BPF program
> > on the target CPU. However, queue_index was never preserved across the
> > CPU boundary, so BPF programs running in cpumap context always observe
> > ctx->rx_queue_index == 0, regardless of which hardware queue originally
> > received the packet.
> >
> > Fix this by storing the originating queue_index in struct xdp_frame,
> > following the same pattern already established for dev_rx and mem_type.
> > The field is populated from rxq->queue_index in
> > xdp_convert_buff_to_frame() during NAPI context, when the rxq_info is
> > still valid, and restored into the reconstructed rxq_info in
> > cpu_map_bpf_prog_run_xdp().
> >
> > Also use xdpf->queue_index in __xdp_build_skb_from_frame() to call
> > skb_record_rx_queue(), which was previously listed as missing
> > information in that function's comment.
> >
> > Also propagate queue_index in dpaa_a050385_wa_xdpf(), which manually
> > constructs a new xdp_frame from an uninitialized page. Without this,
> > queue_index would contain stale data from the page allocator.
> >
> > Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> > ---
> > Note: this patch was only compiled, not tested.
> >
> > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 1 +
> > include/net/xdp.h | 4 +++-
> > kernel/bpf/cpumap.c | 2 +-
> > net/core/xdp.c | 2 +-
> > 4 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > index 3edc8d142dd5..00e36b0ac74d 100644
> > --- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > +++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
> > @@ -2281,6 +2281,7 @@ static int dpaa_a050385_wa_xdpf(struct dpaa_priv *priv,
> > new_xdpf->headroom = priv->tx_headroom;
> > new_xdpf->frame_sz = DPAA_BP_RAW_SIZE;
> > new_xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
> > + new_xdpf->queue_index = xdpf->queue_index;
> >
> > /* Release the initial buffer */
> > xdp_return_frame_rx_napi(xdpf);
> > diff --git a/include/net/xdp.h b/include/net/xdp.h
> > index aa742f413c35..6db10e6a8864 100644
> > --- a/include/net/xdp.h
> > +++ b/include/net/xdp.h
> > @@ -297,10 +297,11 @@ struct xdp_frame {
> > u32 headroom;
> > u32 metasize; /* uses lower 8-bits */
> > /* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
> > - * while mem_type is valid on remote CPU.
> > + * while mem_type and queue_index are valid on remote CPU.
> > */
> > enum xdp_mem_type mem_type:32;
> > struct net_device *dev_rx; /* used by cpumap */
> > + u32 queue_index; /* used by cpumap */
> > u32 frame_sz;
> > u32 flags; /* supported values defined in xdp_buff_flags */
> > };
> > @@ -441,6 +442,7 @@ struct xdp_frame *xdp_convert_buff_to_frame(struct xdp_buff *xdp)
> >
> > /* rxq only valid until napi_schedule ends, convert to xdp_mem_type */
> > xdp_frame->mem_type = xdp->rxq->mem.type;
> > + xdp_frame->queue_index = xdp->rxq->queue_index;
> >
> > return xdp_frame;
> > }
> > diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
> > index 5e59ab896f05..448da572de9a 100644
> > --- a/kernel/bpf/cpumap.c
> > +++ b/kernel/bpf/cpumap.c
> > @@ -197,7 +197,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu,
> >
> > rxq.dev = xdpf->dev_rx;
> > rxq.mem.type = xdpf->mem_type;
> > - /* TODO: report queue_index to xdp_rxq_info */
> > + rxq.queue_index = xdpf->queue_index;
>
> This is like 5th time people attempt to address this TODO.
>
> Just remove that comment. Don't send broken patches.
oh... okay. but I have a question, since the bot detected something
I didn't and queue_index should be propagated in
xdp_convert_zc_to_xdp_frame(), or maybe intentional?
is it better to do as you said, removing the comment, or doing what the
bot said with proper test?
--
regards,
jose a. p-a
^ permalink raw reply
* Re: [PATCH v1 net-next] selftest: net: Use port outside of the default ip_local_ports in csum.c.
From: Willem de Bruijn @ 2026-04-11 19:18 UTC (permalink / raw)
To: Kuniyuki Iwashima, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, Willem de Bruijn, Mahesh Bandewar,
Kuniyuki Iwashima, Kuniyuki Iwashima, netdev
In-Reply-To: <20260410215420.1698033-1-kuniyu@google.com>
Kuniyuki Iwashima wrote:
> csum.c binds a socket on a fixed port in init_net to test
> the csum offload feature between two machines.
>
> In our testbed, the test sometimes fails with -EADDRINUSE.
>
> bind r: Address already in use
> bind dgram 6: Address already in use
>
> The fixed ports (33000, 33001, 34000) are all within the default
> ip_local_ports range (32768 ~ 60999), and other processes may
> happen to be using them.
>
> Let's use ports outside of the default ip_local_ports range to
> deflake the test.
>
> # cat /etc/services | grep -E "(13000|13001|13002)" | echo no service
> no service
> # rpm -qf /etc/services
> setup-2.15.0-28.fc44.noarch
>
> We could add an option to specify ports if needed.
>
> Suggested-by: Mahesh Bandewar <maheshb@google.com>
> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
> ---
> tools/testing/selftests/net/lib/csum.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/net/lib/csum.c b/tools/testing/selftests/net/lib/csum.c
> index e28884ce3ab3..4e044689bc37 100644
> --- a/tools/testing/selftests/net/lib/csum.c
> +++ b/tools/testing/selftests/net/lib/csum.c
> @@ -105,9 +105,9 @@ static char *cfg_mac_src;
> static int cfg_proto = IPPROTO_UDP;
> static int cfg_payload_char = 'a';
> static int cfg_payload_len = 100;
> -static uint16_t cfg_port_dst = 34000;
This is paired with wait_port_listen(3400, .. in
tools/testing/selftests/drivers/net/hw/csum.py
It is also used in tools/testing/selftests/drivers/net/hw/tso.py,
which uses rand_port to select a port.
Probably more robust to indeed add an option to specify a port, and
in all callers use rand_port(s).
> -static uint16_t cfg_port_src = 33000;
> -static uint16_t cfg_port_src_encap = 33001;
> +static uint16_t cfg_port_dst = 13000;
> +static uint16_t cfg_port_src = 13001;
> +static uint16_t cfg_port_src_encap = 13002;
> static unsigned int cfg_random_seed;
> static int cfg_rcvbuf = 1 << 22; /* be able to queue large cfg_num_pkt */
> static bool cfg_send_pfpacket;
> --
> 2.53.0.1213.gd9a14994de-goog
>
^ permalink raw reply
* Re: [PATCH net 1/2] netfilter: skip recording stale or retransmitted INIT
From: Florian Westphal @ 2026-04-11 20:16 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, kuba, Eric Dumazet, Paolo Abeni,
Simon Horman, Marcelo Ricardo Leitner, Yi Chen
In-Reply-To: <6e09f9a8d1f13f3ce691c696d3dd7b2a2e6c6184.1775847557.git.lucien.xin@gmail.com>
Xin Long <lucien.xin@gmail.com> wrote:
> diff --git a/net/netfilter/nf_conntrack_proto_sctp.c b/net/netfilter/nf_conntrack_proto_sctp.c
> index 645d2c43ebf7..7e10fa65cbdd 100644
> --- a/net/netfilter/nf_conntrack_proto_sctp.c
> +++ b/net/netfilter/nf_conntrack_proto_sctp.c
> @@ -466,9 +466,13 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
> if (!ih)
> goto out_unlock;
>
> - if (ct->proto.sctp.init[dir] && ct->proto.sctp.init[!dir])
> - ct->proto.sctp.init[!dir] = 0;
> - ct->proto.sctp.init[dir] = 1;
> + /* Do not record INIT matching peer vtag (stale or retransmitted INIT). */
> + if (old_state == SCTP_CONNTRACK_NONE ||
> + ct->proto.sctp.vtag[!dir] != ih->init_tag) {
Should ct->proto.sctp.vtag[!dir] == ih->init_tag case also
set ignore = true?
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Chris Maness @ 2026-04-11 20:33 UTC (permalink / raw)
To: hugh
Cc: Craig, Kuniyuki Iwashima, kuba, davem, edumazet, gregkh, horms,
linux-hams, linux-kernel, netdev, pabeni, stable, workflows,
yizhe
In-Reply-To: <CANnsUMEniMzLnp5h=Gz83=Wcegc-jGz9vqyWyEpWx-OH=Dij1w@mail.gmail.com>
forms of validation on incoming frames
I for one run two BBS’s that use LinFBB. LinFBB uses the kernel code
for its AX.25 stack. This is still excellent software that is
maintained. I also use Linux as a netrom node for said BBS with real
radio ports and internet connectivity to out of town nodes using the
ax25ipd/netromd that both use kernel stacks.
73 de Chris KQ6UP
Thanks,
Chris Maness
Thanks,
Chris Maness
-Sent from my iPhone
On Fri, Apr 10, 2026 at 4:53 PM Chris Maness
<christopher.maness@gmail.com> wrote:
>
> I for one run two BBS’s that use LinFBB. LinFBB uses the kernel code for its AX.25 stack. This is still excellent software that is maintained. I also use Linux as a netrom node for said BBS with real radio ports and internet connectivity to out of town nodes using the ax25ipd/netromd that both use kernel stacks.
>
> 73 de Chris KQ6UP
>
> Thanks,
> Chris Maness
> -Sent from my iPhone
>
>
> On Fri, Apr 10, 2026 at 4:38 PM Hugh Blemings <hugh@blemings.org> wrote:
>>
>>
>> On 11/4/2026 08:51, Craig wrote:
>> >> If the main concern here is ongoing maintenance of these Ham Radio
>> >> related protocols/drivers, can we pause for a moment on anything as
>> >> dramatic as removing from the tree entirely ?
>> >>
>> >> There is a good cohort of capable kernel folks that either are or
>> >> were ham radio operators who I believe, upon realising that things
>> >> have got to this point, will be happy to redouble efforts to ensure
>> >> this code maintained and tested to a satisfactory standard.
>> >>
>> >> Or, alternatively, as a technical community it may be that the Ham
>> >> Radio interested folks conclude that out of tree or user space
>> >> solutions are a better way forward as others have proposed.
>> >>
>> >> Give us a few days, please, for the word to be put around that we
>> >> need to pull ourselves together a bit as a technical group :)
>> >>
>> >
>> > I, for one, really can't imagine pulling an entire network subsytem
>> > out of the kernel without any
>> > knowledge of how/if/when it's used. Like intercontinental radio
>> > networks, global email, ax.25
>> > keyboard-to-keyboard, BBS and other emergency-communication systems
>> > throughout the
>> > world. If you're sure the Internet will never fail, I guess it makes
>> > sense removing all of this
>> > since it's inconvenient to maintain.
>> >
>> > Global AX.25 keyboard-to-keyboard on 14.105Mhz
>> >
>> > https://qsl.net/kb9pvh/105.html
>> >
>> > AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.
>> >
>> > https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d
>> >
>> > Global radio email using AX.25
>> >
>> > https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on
>> > the Earth and Space)
>> >
>> > This is all in operation by Amateur Radio ARES emergency
>> > protocols/technologies. This
>> > will not pass the headline test when it comes to Linux detractors.
>> >
>> > Most of this is running on Raspberry Pi / Linux 24/7.
>> >
>> > If we want to kill all these apps and somehow force them into user space,
>> > it's akin to just switching to Windows - and flounder with the
>> > Microsoft folks
>> > trying to do the same thing.
>>
>> Your email Craig neatly encapsulates just some of the practical and
>> ongoing applications of the kernel code in question - I don't think this
>> is in dispute.
>>
>> What's pertinent is if we as the ham/amatuer radio community can agree
>> on whether in tree, out of tree modules, or a userspace device driver
>> approach make the most sense. If we are to keep code in the kernel in
>> any form, we as a community need to find someone(s) that have the skills
>> and bandwidth to keep the in tree code up to date.
>>
>> I don't think this would be onerous and I have a couple of people in
>> mind to nudge who may be happy to do so if that proves the right way
>> forward. At a pinch I could do it, but that'll mean a lot of catching
>> up. But I think it reasonable that the responsibility here falls to
>> folks that are closer to the code in question than the wider and
>> overworked kernel maintainer community.
>>
>> That said, I think Dan Cross (KZ2X) earlier email makes a pretty strong
>> case for moving out of the kernel while still providing a way to have
>> backward compatibility, perhaps this might be the way forward?
>>
>> In any case, done well, this approach would not kill the apps or force
>> anything like switching to Windows! :) Great projects like digipi would
>> be able to continue with minimal changes.
>>
>> I wonder if a separate thread in linux-hams makes sense to discuss the
>> various longer term approaches to maintaining these capabilities - I'll
>> try make time later today to kick one off - such deliberations will be
>> of less interest to the broader LKML and other lists.
>>
>> Cheers/73
>> Hugh
>>
>>
>>
>> >
>> >
>> > -craig
>> > https://digipi.org/
>> >
>> >
>> --
>> I am slowly moving to hugh@blemings.id.au as my main email address.
>> If you're using hugh@blemings.org please update your address book accordingly.
>> Thank you :)
>>
>>
--
Thanks,
Chris Maness
^ permalink raw reply
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Sam Edwards @ 2026-04-11 20:40 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Maxime Chevallier,
Ovidiu Panait, Vladimir Oltean, Baruch Siach, Serge Semin,
Giuseppe Cavallaro, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <adjrtRSepmac2hpN@shell.armlinux.org.uk>
On Fri, Apr 10, 2026 at 5:23 AM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Apr 02, 2026 at 10:39:32AM -0700, Sam Edwards wrote:
> > On Thu, Apr 2, 2026 at 10:16 AM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > > I've tested this on my Jetson Xavier platform. One of the issues I've
> > > had is that running iperf3 results in the receive side stalling because
> > > it runs out of descriptors. However, despite the receive ring
> > > eventually being re-filled and the hardware appropriately prodded, it
> > > steadfastly refuses to restart, despite the descriptors having been
> > > updated.
> >
> > Hi Russell,
> >
> > Just to make sure I understand correctly: before my patches, you've
> > been observing this problem on Xavier for a while (no interrupts, ring
> > goes dry); with my patches, the ring is refilled, but the dwmac5
> > doesn't resume DMA. (Ah, just saw your follow-up email.)
> >
> > > Any ideas?
> >
> > Off the top of my head, my hypothesis is that dwmac5 has an additional
> > tripwire when the receive DMA is exhausted, and the
> > stmmac_set_rx_tail_ptr()/stmmac_enable_dma_reception() at the end of
> > stmmac_rx_refill() aren't sufficient to wake it back up.
> >
> > I think this is new to dwmac5, because my RK3588 (dwmac4.20 iirc)
> > happily resumes after the same condition.
> >
> > You gave a lot of info; thanks! I'll try to scrape up some
> > documentation on dwmac5 to see if there's something more
> > stmmac_rx_refill() ought to be doing. I think I have a Xavier NX
> > around here somewhere, I'll see if I can repro the problem.
>
> I've added dma_rmb() into dwmac4_wrback_get_tx_status() and
> dwmac4_wrback_get_rx_status(), and with that I've had an iperf3
> instance finally complete... but only once:
Hi Russell,
To me it feels relevant that the T194 doesn't use first-party
ARM/Cortex cores but rather Nvidia's in-house "Carmel" architecture.
Do you suppose the cache there is quirky in such a way that either:
1) We're seeing poor cache hygiene in stmmac where other caches are
more forgiving (more likely)
2) Carmel's cache has a subtle hardware bug triggered by stmmac's
specific access pattern (less likely)?
I'm still trying to get my Xavier NX to boot on net-next. It's running
into eMMC corruption/stalls very early in the boot process (at
slightly different times; feels like a problem in autocalibration)
that I'm not seeing on older kernels. Once I'm done bisecting that
regression I'll take a deeper look at this stmmac mystery. :)
Cheers,
Sam
>
> root@tegra-ubuntu:~# iperf3 -c 192.168.248.1 -R
> Connecting to host 192.168.248.1, port 5201
> Reverse mode, remote host 192.168.248.1 is sending
> [ 5] local 192.168.248.174 port 42232 connected to 192.168.248.1 port 5201
> [ ID] Interval Transfer Bitrate
> [ 5] 0.00-1.00 sec 50.8 MBytes 426 Mbits/sec
> [ 5] 1.00-2.00 sec 54.9 MBytes 460 Mbits/sec
> [ 5] 2.00-3.00 sec 54.0 MBytes 453 Mbits/sec
> [ 5] 3.00-4.00 sec 53.8 MBytes 452 Mbits/sec
> [ 5] 4.00-5.00 sec 52.4 MBytes 438 Mbits/sec
> [ 5] 5.00-6.00 sec 54.3 MBytes 455 Mbits/sec
> [ 5] 6.00-7.00 sec 53.7 MBytes 452 Mbits/sec
> [ 5] 7.00-8.00 sec 52.8 MBytes 443 Mbits/sec
> [ 5] 8.00-9.00 sec 53.7 MBytes 451 Mbits/sec
> [ 5] 9.00-10.00 sec 54.3 MBytes 455 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.01 sec 537 MBytes 450 Mbits/sec 13 sender
> [ 5] 0.00-10.00 sec 535 MBytes 448 Mbits/sec receiver
>
> iperf Done.
>
> So, it seems better, but not completely solved.
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> index 2994df41ec2c..119f31c94b61 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
> @@ -17,10 +17,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
> struct dma_desc *p,
> void __iomem *ioaddr)
> {
> - u32 tdes3 = le32_to_cpu(p->des3);
> + u32 tdes3;
> int ret = tx_done;
>
> /* Get tx owner first */
> + dma_rmb();
> + tdes3 = le32_to_cpu(p->des3);
> if (unlikely(tdes3 & TDES3_OWN))
> return tx_dma_own;
>
> @@ -70,12 +72,12 @@ static int dwmac4_wrback_get_tx_status(struct stmmac_extra_stats *x,
> static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
> struct dma_desc *p)
> {
> - u32 rdes1 = le32_to_cpu(p->des1);
> - u32 rdes2 = le32_to_cpu(p->des2);
> - u32 rdes3 = le32_to_cpu(p->des3);
> + u32 rdes1, rdes2, rdes3;
> int message_type;
> int ret = good_frame;
>
> + dma_rmb();
> + rdes3 = le32_to_cpu(p->des3);
> if (unlikely(rdes3 & RDES3_OWN))
> return dma_own;
>
> @@ -107,6 +109,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
>
> message_type = FIELD_GET(RDES1_PTP_MSG_TYPE_MASK, rdes1);
>
> + rdes1 = le32_to_cpu(p->des1);
> if (rdes1 & RDES1_IP_HDR_ERROR) {
> x->ip_hdr_err++;
> ret |= csum_none;
> @@ -152,6 +155,7 @@ static int dwmac4_wrback_get_rx_status(struct stmmac_extra_stats *x,
> if (rdes1 & RDES1_TIMESTAMP_DROPPED)
> x->timestamp_dropped++;
>
> + rdes2 = le32_to_cpu(p->des2);
> if (unlikely(rdes2 & RDES2_SA_FILTER_FAIL)) {
> x->sa_rx_filter_fail++;
> ret = discard_frame;
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH next-next] net: phy: mscc: Drop redundant phydev->lock
From: Andrew Lunn @ 2026-04-11 20:44 UTC (permalink / raw)
To: Biju
Cc: Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Biju Das, Russell King, Lad Prabhakar,
Horatiu Vultur, Vladimir Oltean, netdev, linux-kernel,
Geert Uytterhoeven, linux-renesas-soc
In-Reply-To: <20260411154959.200091-1-biju.das.jz@bp.renesas.com>
On Sat, Apr 11, 2026 at 04:49:56PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Remove manual mutex_lock/unlock(&phydev->lock) calls from several
> functions in the MSCC PHY driver, as the PHY core already holds this lock
> when invoking these callbacks.
>
> The affected functions are:
>
> vsc85xx_edge_rate_cntl_set() — lock/unlock around phy_modify_paged()
> vsc85xx_mac_if_set() — lock/unlock with a goto out_unlock error path
> vsc8531_pre_init_seq_set() — lock/unlock around phy_select/restore_page()
> vsc85xx_eee_init_seq_set() — lock/unlock around phy_select/restore_page()
>
> Along with dropping the locks, error-path labels are renamed from
> out_unlock to err or restore_oldpage to better reflect their purpose now
> that no unlocking is performed. In vsc8531_pre_init_seq_set() and
> vsc85xx_eee_init_seq_set(), the redundant intermediate assignment of
> oldpage before returning is also eliminated.
>
> No functional change intended.
This patch needs to be sent as part of the patchset with your other
change. The order they get merged matters, otherwise a git bisect
could land on a deadlock.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] net: phy: qcom: at803x: Use the correct bit to disable extended next page
From: Andrew Lunn @ 2026-04-11 20:49 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, thomas.petazzoni, netdev, linux-kernel,
linux-arm-msm
In-Reply-To: <c37f182e-cbb4-4f0b-817a-759d39940212@bootlin.com>
> > Should we keep ADVERTISE_RESV?
> >
> > 45.2.7.6 AN advertisement register
> >
> > If the Auto-Negotiation advertisement register (register 4) is
> > present, (see 28.2.4.1.3), then this register is a copy of the
> > Auto-Negotiation advertisement register (register 4). In this case,
> > reads to the AN advertisement register (7.16) report the value of
> > the Auto-Negotiation advertisement register (register 4); writes to
> > the AN advertisement register (7.16) cause a write to occur to the
> > Auto-Negotiation advertisement register.
> >
> > So MDIO_MMD_AN:MDIO_AN_ADVERTISE is a straight copy of MII_ADVERTISE.
> >
> > ef4_mdio_write(efx, MDIO_MMD_AN, MDIO_AN_ADVERTISE, reg);
> > ret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE, adv);
> >
> > So ADVERTISE_XNP is just as valid in the other two drivers using
> > ADVERTISE_RESV. I think we should change those as well to
> > ADVERTISE_XNP and remove ADVERTISE_RESV?
> >
> > Andrew
>
> I agree with that yes and I've considered converting these drivers once
> we have net merged into net-next should this patch be applied :)
Ah, sorry, missed the patch was targeting net. Please do submit a
cleanup for net-next later on.
> That said, ADVERTISE_RESV is in uapi, is it even possible to remove it ?
Good point. It probably does have to stay.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mxl862xx: add ethtool statistics support
From: Andrew Lunn @ 2026-04-11 22:41 UTC (permalink / raw)
To: Daniel Golle
Cc: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King, netdev, linux-kernel, Frank Wunderlich,
Chad Monroe, Cezary Wilmanski, Liang Xu, Benny (Ying-Tsan) Weng,
Jose Maria Verdu Munoz, Avinash Jayaraman, John Crispin
In-Reply-To: <127b374aba1fb8eb4ad9215e0c0826dd4545fc58.1775865049.git.daniel@makrotopia.org>
> +static int mxl862xx_read_rmon(struct dsa_switch *ds, int port,
> + struct mxl862xx_rmon_port_cnt *cnt)
> +{
> + memset(cnt, 0, sizeof(*cnt));
> + cnt->port_type = cpu_to_le32(MXL862XX_CTP_PORT);
> + cnt->port_id = cpu_to_le16(port);
> +
> + return MXL862XX_API_READ(ds->priv, MXL862XX_RMON_PORT_GET, *cnt);
> +}
> +
> +static void mxl862xx_get_ethtool_stats(struct dsa_switch *ds, int port,
> + u64 *data)
> +{
> + const struct mxl862xx_mib_desc *mib;
> + struct mxl862xx_rmon_port_cnt cnt;
> + int ret, i;
> + void *field;
> +
> + ret = mxl862xx_read_rmon(ds, port, &cnt);
> + if (ret) {
> + dev_err(ds->dev, "failed to read RMON stats on port %d\n", port);
> + return;
> + }
RMON statistics should be returned via the .get_rmon_stats in
dsa_switch_ops. Please only return statistics here which don't fit any
of the other statistics functions in dsa_switch_ops.
Andrew
---
pw-bot: cr
^ permalink raw reply
* [PATCH net-next v2 0/2] net: dsa: mxl862xx: add statistics support
From: Daniel Golle @ 2026-04-12 0:01 UTC (permalink / raw)
To: Daniel Golle, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Russell King, netdev,
linux-kernel
Cc: Frank Wunderlich, Chad Monroe, Cezary Wilmanski, Liang Xu,
Benny (Ying-Tsan) Weng, Jose Maria Verdu Munoz, Avinash Jayaraman,
John Crispin
Add per-port RMON statistics support for the MxL862xx DSA driver,
covering hardware-specific ethtool -S counters, standard IEEE 802.3
MAC/ctrl/pause statistics, and rtnl_link_stats64 via polled 64-bit
accumulation.
Changes since v1:
* trim mxl862xx_mib[] to counters not covered elsewhere only
* remove histogram counters (moved to .get_rmon_stats)
* remove RMON error counters (moved to .get_rmon_stats)
* remove counters already in .get_eth_mac_stats
* remove counters already in .get_stats64
* add mxl862xx_rmon_ranges[] and mxl862xx_get_rmon_stats()
Daniel Golle (2):
net: dsa: mxl862xx: add ethtool statistics support
net: dsa: mxl862xx: implement .get_stats64
drivers/net/dsa/mxl862xx/mxl862xx-api.h | 142 +++++++++
drivers/net/dsa/mxl862xx/mxl862xx-cmd.h | 3 +
drivers/net/dsa/mxl862xx/mxl862xx-host.c | 8 +-
drivers/net/dsa/mxl862xx/mxl862xx.c | 348 +++++++++++++++++++++++
drivers/net/dsa/mxl862xx/mxl862xx.h | 94 +++++-
5 files changed, 588 insertions(+), 7 deletions(-)
--
2.53.0
^ 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