* [PATCH iproute2-next] utils: add fflush_monitor() helper
From: Eric Dumazet @ 2026-04-24 17:11 UTC (permalink / raw)
To: David Ahern, Stephen Hemminger
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Kuniyuki Iwashima,
netdev, eric.dumazet, Eric Dumazet
Some fflush() calls only make sense for monitor programs.
For other cases, forcing a flush is expensive.
After this patch, ip, tc and ss are correctly buffering their
output when redirected to a file.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/utils.h | 7 +++++++
ip/ipaddress.c | 12 +++++++-----
ip/iplink.c | 4 ++--
ip/ipmonitor.c | 1 +
ip/iproute.c | 4 ++--
lib/utils.c | 1 +
misc/ss.c | 3 ++-
tc/tc_class.c | 2 +-
tc/tc_filter.c | 2 +-
tc/tc_monitor.c | 1 +
tc/tc_qdisc.c | 2 +-
11 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/include/utils.h b/include/utils.h
index b68d6bc4edcf9ca335148f731cd240871b6c809b..9099a78b1593738c5ba181274d784d0a1913407a 100644
--- a/include/utils.h
+++ b/include/utils.h
@@ -38,6 +38,7 @@ extern int numeric;
extern bool do_all;
extern int echo_request;
extern int use_iec;
+extern int monitor_mode;
#define SPRINT_BSIZE 64
#define SPRINT_BUF(x) char x[SPRINT_BSIZE]
@@ -399,4 +400,10 @@ FILE *generic_proc_open(const char *env, const char *name);
int open_fds_add(int fd);
void open_fds_close(void);
+static inline void fflush_monitor(FILE *fp)
+{
+ if (monitor_mode)
+ fflush_monitor(fp);
+}
+
#endif /* __UTILS_H__ */
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 4d93a04a8555e141ae30a4aaeb42ac607a181c9b..14aa98e77452c9681c9d3660f6a882df56b44f1c 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -894,7 +894,7 @@ static int print_linkinfo_brief(FILE *fp, const char *name,
print_string(PRINT_FP, NULL, "%s", "\n");
}
- fflush(fp);
+ fflush_monitor(fp);
return 0;
}
@@ -1346,10 +1346,12 @@ int print_linkinfo(struct nlmsghdr *n, void *arg)
}
print_string(PRINT_FP, NULL, "%s", "\n");
- fflush(fp);
+ fflush_monitor(fp);
/* prettier here if stderr and stdout go to the same place */
- if (truncated_vfs)
+ if (truncated_vfs) {
+ fflush(fp);
fprintf(stderr, "Truncated VF list: %s\n", name);
+ }
return 1;
}
@@ -1732,7 +1734,7 @@ int print_addrinfo(struct nlmsghdr *n, void *arg)
}
print_string(PRINT_FP, NULL, "%s", "\n");
brief_exit:
- fflush(fp);
+ fflush_monitor(fp);
return 0;
}
@@ -1768,7 +1770,7 @@ static int print_selected_addrinfo(struct ifinfomsg *ifi,
if (brief) {
print_string(PRINT_FP, NULL, "%s", "\n");
- fflush(fp);
+ fflush_monitor(fp);
}
return 0;
}
diff --git a/ip/iplink.c b/ip/iplink.c
index fce6631d2d821a8739d28805e13d98f6804bda30..806f86987ed7c8af5ddd40f04a44fb8ce8debfaf 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -1296,7 +1296,7 @@ static void print_mpls_stats(FILE *fp, struct rtattr *attr)
print_nl();
print_mpls_link_stats(fp, stats, " ");
print_string(PRINT_FP, NULL, "%s", "\n");
- fflush(fp);
+ fflush_monitor(fp);
}
static void print_af_stats_attr(FILE *fp, int ifindex, struct rtattr *attr)
@@ -1359,7 +1359,7 @@ static int print_af_stats(struct nlmsghdr *n, void *arg)
if (tb[IFLA_STATS_AF_SPEC])
print_af_stats_attr(fp, ifsm->ifindex, tb[IFLA_STATS_AF_SPEC]);
- fflush(fp);
+ fflush_monitor(fp);
return 0;
}
diff --git a/ip/ipmonitor.c b/ip/ipmonitor.c
index 1f4e860f8d6726edffcf9bf81636c6555757dd09..23bd667a2f7a27e620d0f6dd13a16476c1ac0d08 100644
--- a/ip/ipmonitor.c
+++ b/ip/ipmonitor.c
@@ -324,6 +324,7 @@ int do_ipmonitor(int argc, char **argv)
return err;
}
+ monitor_mode = 1;
if (rtnl_open(&rth, groups) < 0)
exit(1);
diff --git a/ip/iproute.c b/ip/iproute.c
index c2538894da633b56f5b926ecafda4960a48e9fbd..c6a6ba9dd37076acfceb9b259874a50e7cd3c3d0 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -1012,7 +1012,7 @@ int print_route(struct nlmsghdr *n, void *arg)
print_string(PRINT_FP, NULL, "\n", NULL);
close_json_object();
- fflush(fp);
+ fflush_monitor(fp);
return 0;
}
@@ -2035,7 +2035,7 @@ static int iproute_list_flush_or_save(int argc, char **argv, int action)
}
delete_json_obj();
- fflush(stdout);
+ fflush_monitor(stdout);
return 0;
}
diff --git a/lib/utils.c b/lib/utils.c
index 1215fe31cb3f63c0fa768fef60da77a641c51581..7017b0e6afacd8e770fb9f8b26aa5a319c1279e7 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -41,6 +41,7 @@ int timestamp_short;
int pretty;
int use_iec;
int human_readable;
+int monitor_mode;
const char *_SL_ = "\n";
static int open_fds[5];
diff --git a/misc/ss.c b/misc/ss.c
index 14e9f27a75321556240a5f290b8bcf51c605a4c2..0f9b37177d375ddf70cb34674992723b5c4883be 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -5544,7 +5544,7 @@ static int generic_show_sock(struct nlmsghdr *nlh, void *arg)
render();
- fflush(stdout);
+ fflush_monitor(stdout);
return ret;
}
@@ -5580,6 +5580,7 @@ static int handle_follow_request(struct filter *f)
f->rth_for_killing = &rth2;
}
+ monitor_mode = 1;
if (rtnl_dump_filter(&rth, generic_show_sock, f))
ret = -1;
diff --git a/tc/tc_class.c b/tc/tc_class.c
index 6d707d8c924f4b5e90201d4de8e9779f82ce17f3..8197566281fad47d4efcf4768ed406ab809dd08a 100644
--- a/tc/tc_class.c
+++ b/tc/tc_class.c
@@ -380,7 +380,7 @@ int print_class(struct nlmsghdr *n, void *arg)
close_json_object();
}
close_json_object();
- fflush(fp);
+ fflush_monitor(fp);
return 0;
}
diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index 7db850bda11a3408ec66b457c9fc590f3a734f65..633f027d79865d98ba1ccba48af71d247dfc7a48 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@@ -374,7 +374,7 @@ int print_filter(struct nlmsghdr *n, void *arg)
print_ext_msg(tb);
close_json_object();
- fflush(fp);
+ fflush_monitor(fp);
return 0;
}
diff --git a/tc/tc_monitor.c b/tc/tc_monitor.c
index 5b9bccbed4140241a4d7a5cffc50865106224867..49bd4b6a460fbfe41a35e06f92f07dbe56a6be2d 100644
--- a/tc/tc_monitor.c
+++ b/tc/tc_monitor.c
@@ -100,6 +100,7 @@ int do_tcmonitor(int argc, char **argv)
return ret;
}
+ monitor_mode = 1;
if (rtnl_open(&rth, groups) < 0)
exit(1);
diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c
index 7eb9a31baa31fb91a8141c9eca1135e76a52fa8b..a8ef8fc9f70d91609d6ed61c2a46b29120512fd2 100644
--- a/tc/tc_qdisc.c
+++ b/tc/tc_qdisc.c
@@ -344,7 +344,7 @@ int print_qdisc(struct nlmsghdr *n, void *arg)
print_ext_msg(tb);
close_json_object();
- fflush(fp);
+ fflush_monitor(fp);
return 0;
}
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [PATCH 0/9] bitfield: add FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-24 17:10 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, David Lechner,
Nuno Sá, Andy Shevchenko, Ping-Ke Shih, Richard Cochran,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alexandre Belloni, Yury Norov, Rasmus Villemoes,
Hans de Goede, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <aeuRMiws8zCdkGXX@yury>
On Fri, Apr 24, 2026 at 11:50:10AM -0400, Yury Norov wrote:
> On Fri, Apr 24, 2026 at 01:09:27PM +0100, Jonathan Cameron wrote:
> > On Fri, 17 Apr 2026 13:36:11 -0400
> > Yury Norov <ynorov@nvidia.com> wrote:
> >
> > > The bitfields are designed in assumption that fields contain unsigned
> > > integer values, thus extracting the values from the field implies
> > > zero-extending.
> > >
> > > Some drivers need to sign-extend their fields, and currently do it like:
> > >
> > > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> > >
> > > It's error-prone because it relies on user to provide the correct
> > > index of the most significant bit.
> > >
> > > This series adds a signed version of FIELD_GET(), which is the more
> > > convenient and compiles (on x86_64) to just a couple instructions:
> > > shl and sar.
> > >
> > > Patch #1 adds FIELD_GET_SIGNED(), and the rest of the series applies it
> > > tree-wide.
> > >
> >
> > Just a quick heads up that I'm beginning to assume that this series
> > will land in some form. If it does can we do it as an immutable branch
> > as I'm suggesting it gets used in some other patches in that should land
> > in the new cycle.
>
> I'm going to submit v2 soon, as seemingly the discussion is boiled
> down, and then will likely merge it with my tree. I'll create an
> immutable branch for you before the end of day.
Here it is:
https://github.com/norov/linux/pull/new/fgsv2
It builds well for me, but I'll wait for a while for robots feedback
before making it 'officially' immutable.
Thanks,
Yury
^ permalink raw reply
* Re: [syzbot] [net?] general protection fault in kernel_sock_shutdown (4)
From: Arjan van de Ven @ 2026-04-24 16:47 UTC (permalink / raw)
To: netdev
Cc: syzbot+d8f76778263ab65c2b21, davem, dsahern, edumazet, horms,
kuba, linux-kernel, pabeni, syzkaller-bugs
In-Reply-To: <69ea344f.a00a0220.17a17.0040.GAE@google.com>
This report was analysed with the help of an automated kernel crash
analysis assistant. The analysis below is tentative and should be
reviewed by a human before any action is taken.
Decoded Backtrace
-----------------
1. kernel_sock_shutdown -- crash site (net/socket.c:3785)
3783 int kernel_sock_shutdown(struct socket *sock, enum sock_shutdown_cmd how)
3784 {
3785 return READ_ONCE(sock->ops)->shutdown(sock, how);
/* CRASH: sock->ops is NULL (R12 = 0x0); KASAN traps
null-ptr-deref at offset 0x68 = offsetof(proto_ops, shutdown) */
3786 }
Register context at crash:
RBX = 0xffff888058587240 (struct socket *sock)
R12 = 0x0000000000000000 (sock->ops, loaded from RBX+0x20 -- NULL)
RDI = 0x0000000000000068 (= NULL + 0x68, address of shutdown fn ptr)
RBP = 0x0000000000000002 (how = SHUT_RDWR)
2. udp_tunnel_sock_release (net/ipv4/udp_tunnel_core.c:196-202)
196 void udp_tunnel_sock_release(struct socket *sock)
197 {
198 rcu_assign_sk_user_data(sock->sk, NULL);
199 synchronize_rcu();
200 kernel_sock_shutdown(sock, SHUT_RDWR); /* <- calls crash site */
201 sock_release(sock);
202 }
3. rxe_release_udp_tunnel inlined (drivers/infiniband/sw/rxe/rxe_net.c:290-293)
290 static void rxe_release_udp_tunnel(struct socket *sk)
291 {
292 if (sk)
293 udp_tunnel_sock_release(sk);
294 }
4. rxe_sock_put (drivers/infiniband/sw/rxe/rxe_net.c:632-643)
632 static void rxe_sock_put(struct sock *sk,
633 void (*set_sk)(struct net *, struct sock *),
634 struct net *net)
635 {
636 if (refcount_read(&sk->sk_refcnt) > SK_REF_FOR_TUNNEL) {
637 __sock_put(sk);
638 } else {
639 rxe_release_udp_tunnel(sk->sk_socket); /* <- release BEFORE clear */
640 sk = NULL;
641 set_sk(net, sk); /* <- clear AFTER (too late) */
642 }
643 }
Caller: rxe_net_del (rxe_net.c:644-666), triggered via:
nldev_dellink -> rxe_dellink -> rxe_net_del -> rxe_sock_put
Tentative Analysis
------------------
sock->ops is set to NULL by sock_release() (net/socket.c:726) after
calling ops->release(sock). The crash in kernel_sock_shutdown() means
the socket was already passed to sock_release() before this call.
Two independent code paths can release the same UDP tunnel socket stored
in the per-network-namespace rxe_ns_sock structure:
Path 1 -- namespace teardown (rxe_ns.c, rxe_ns_exit()):
rcu_assign_pointer(ns_sk->rxe_sk4, NULL); /* clears pointer FIRST */
udp_tunnel_sock_release(sk->sk_socket); /* then releases */
Path 2 -- RDMA link delete (rxe_net.c, rxe_net_del() -> rxe_sock_put()):
sk = rxe_ns_pernet_sk4(net); /* reads pointer (no ownership) */
rxe_release_udp_tunnel(sk->sk_socket); /* releases FIRST */
set_sk(net, NULL); /* clears AFTER */
The following TOCTOU (time-of-check time-of-use) race is possible when
namespace teardown and RDMA link deletion occur concurrently:
Thread A (rxe_net_del):
rxe_ns_pernet_sk4() -> sk = X (non-NULL)
Thread B (rxe_ns_exit):
rcu_assign_pointer(sk4, NULL)
udp_tunnel_sock_release(X->sk_socket)
sock_release(X->sk_socket)
X->sk_socket->ops = NULL <- clears ops
Thread A (rxe_net_del) continues:
rxe_sock_put(sk=X, ...)
rxe_release_udp_tunnel(X->sk_socket)
kernel_sock_shutdown(X->sk_socket, SHUT_RDWR)
READ_ONCE(sock->ops)->shutdown(...)
<- CRASH: sock->ops == NULL
The bug was introduced by two commits in March 2026 that added
per-network-namespace support to the Soft RoCE (RXE) driver:
13f2a53c2a71e RDMA/rxe: Add net namespace support for IPv4/IPv6 sockets
f1327abd6abed RDMA/rxe: Support RDMA link creation and destruction per
net namespace
Neither commit provides synchronisation between the two teardown paths.
Potential Solution
------------------
Replace rxe_ns_pernet_sk4() calls in rxe_net_del() (and rxe_notify())
with an atomic exchange that simultaneously reads and clears the pernet
pointer, so only one of the two teardown paths can ever obtain a
non-NULL socket pointer:
struct sock *rxe_ns_pernet_take_sk4(struct net *net)
{
struct rxe_ns_sock *ns_sk = net_generic(net, rxe_pernet_id);
return unrcu_pointer(xchg(&ns_sk->rxe_sk4, RCU_INITIALIZER(NULL)));
}
Whichever path (rxe_ns_exit or rxe_net_del) wins the xchg gets the
socket and releases it; the loser gets NULL and skips the release.
More information
----------------
Oops-Analysis: https://lore.kernel.org/r/69ea344f.a00a0220.17a17.0040.GAE@google.com
Assisted-by: linux-kernel-oops-x86 skill (Claude Sonnet 4.6)
^ permalink raw reply
* Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-24 16:35 UTC (permalink / raw)
To: Johannes Berg
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Ping-Ke Shih,
Richard Cochran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexandre Belloni, Yury Norov,
Rasmus Villemoes, Hans de Goede, Linus Walleij, Sakari Ailus,
Salah Triki, Achim Gratz, Ben Collins, linux-kernel, linux-iio,
linux-wireless, netdev, linux-rtc
In-Reply-To: <6170788fcab2ec835597e3d7411928d36850c20a.camel@sipsolutions.net>
On Mon, Apr 20, 2026 at 10:43:08AM +0200, Johannes Berg wrote:
> On Fri, 2026-04-17 at 13:36 -0400, Yury Norov wrote:
> > The bitfields are designed in assumption that fields contain unsigned
> > integer values, thus extracting the values from the field implies
> > zero-extending.
> >
> > Some drivers need to sign-extend their fields, and currently do it like:
> >
> > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
>
> That's indeed pretty awful...
>
>
> > +#define FIELD_GET_SIGNED(mask, reg) \
> >
>
> [...]
>
> I (personally) tend to prefer the "__MAKE_OP" versions (*_get_bits()
> etc.), in particular because WiFi and firmware interfaces deal a lot
> with fixed endian fields.
I don't like that __MAKE_OP magic because whatever it generates is not
greppable. And because we disable strict type checks for kernel, but
this API claims to typecheck the parameters for the user. So, the
following compiles well:
u64 val = 0;
ret = le16_get_bits(val, GENMASK(15, 10));
I don't like autogeneration in general. We generate, for example,
be32_get_bits(), but never use it. We don't even know the level of
the bloat.
> Any chance it'd be simple to generate u32_get_bits_signed() etc.? Could
> be especially useful for le32_get_bits_signed() for example, to have the
> endian conversion built-in unlike FIELD_GET_SIGNED().
Maybe this:
FIELD_GET_SIGNED(mask, le32_to_cpu(reg))
Thanks,
Yury
^ permalink raw reply
* [PATCH v3] ibmveth: Disable GSO for packets with small MSS
From: Mingming Cao @ 2026-04-24 16:29 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, edumazet, pabeni, horms, bjking1, maddy, mpe,
linuxppc-dev, stable, Mingming Cao, Shaik Abdulla, Naveed Ahmed
Some physical adapters on Power systems do not support segmentation
offload when the MSS is less than 224 bytes. Attempting to send such
packets causes the adapter to freeze, stopping all traffic until
manually reset.
Implement ndo_features_check to disable GSO for packets with small MSS
values. The network stack will perform software segmentation instead.
The 224-byte minimum matches ibmvnic
commit <f10b09ef687f> ("ibmvnic: Enforce stronger sanity checks
on GSO packets")
which uses the same physical adapters in SEA configurations.
The issue occurs specifically when the hardware attempts to perform
segmentation (gso_segs > 1) with a small MSS. Single-segment GSO packets
(gso_segs == 1) do not trigger the problematic LSO code path and are
transmitted normally without segmentation.
Add an ndo_features_check callback to disable GSO when MSS < 224 bytes.
Also call vlan_features_check() to ensure proper handling of VLAN packets,
particularly QinQ (802.1ad) configurations where the hardware parser may
not support certain offload features.
Validated using iptables to force small MSS values. Without the fix,
the adapter freezes. With the fix, packets are segmented in software
and transmission succeeds. Comprehensive regression testing completedd
(MSS tests, performance, stability).
Fixes: 8641dd85799f ("ibmveth: Add support for TSO")
Cc: stable@vger.kernel.org
Reviewed-by: Brian King <bjking1@linux.ibm.com>
Tested-by: Shaik Abdulla <shaik.abdulla1@ibm.com>
Tested-by: Naveed Ahmed <naveedaus@in.ibm.com>
Signed-off-by: Mingming Cao <mmc@linux.ibm.com>
---
Changes in v3:
- Call vlan_features_check() to handle VLAN packets correctly
- Clarified that gso_segs == 1 check is not needed for ibmveth
(unlike ibmvnic, single-segment packets don't enter LSO path)
- Updated commit message to explain the difference
Changes in v2:
- Add Fixes tag as requested by automated checks
---
drivers/net/ethernet/ibm/ibmveth.c | 22 ++++++++++++++++++++++
drivers/net/ethernet/ibm/ibmveth.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
index 58cc3147afe2..73e051d26b9d 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -1756,6 +1756,27 @@ static int ibmveth_set_mac_addr(struct net_device *dev, void *p)
return 0;
}
+static netdev_features_t ibmveth_features_check(struct sk_buff *skb,
+ struct net_device *dev,
+ netdev_features_t features)
+{
+ /* Some physical adapters do not support segmentation offload with
+ * MSS < 224. Disable GSO for such packets to avoid adapter freeze.
+ * Note: Single-segment packets (gso_segs == 1) don't need this check
+ * as they bypass the LSO path and are transmitted without segmentation.
+ */
+ if (skb_is_gso(skb)) {
+ if (skb_shinfo(skb)->gso_size < IBMVETH_MIN_LSO_MSS) {
+ netdev_warn_once(dev,
+ "MSS %u too small for LSO, disabling GSO\n",
+ skb_shinfo(skb)->gso_size);
+ features &= ~NETIF_F_GSO_MASK;
+ }
+ }
+
+ return vlan_features_check(skb, features);
+}
+
static const struct net_device_ops ibmveth_netdev_ops = {
.ndo_open = ibmveth_open,
.ndo_stop = ibmveth_close,
@@ -1767,6 +1788,7 @@ static const struct net_device_ops ibmveth_netdev_ops = {
.ndo_set_features = ibmveth_set_features,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_mac_address = ibmveth_set_mac_addr,
+ .ndo_features_check = ibmveth_features_check,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = ibmveth_poll_controller,
#endif
diff --git a/drivers/net/ethernet/ibm/ibmveth.h b/drivers/net/ethernet/ibm/ibmveth.h
index 068f99df133e..d87713668ed3 100644
--- a/drivers/net/ethernet/ibm/ibmveth.h
+++ b/drivers/net/ethernet/ibm/ibmveth.h
@@ -37,6 +37,7 @@
#define IBMVETH_ILLAN_IPV4_TCP_CSUM 0x0000000000000002UL
#define IBMVETH_ILLAN_ACTIVE_TRUNK 0x0000000000000001UL
+#define IBMVETH_MIN_LSO_MSS 224 /* Minimum MSS for LSO */
/* hcall macros */
#define h_register_logical_lan(ua, buflst, rxq, fltlst, mac) \
plpar_hcall_norets(H_REGISTER_LOGICAL_LAN, ua, buflst, rxq, fltlst, mac)
--
2.39.3 (Apple Git-146)
^ permalink raw reply related
* Re: [PATCH net-next v6 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: David Wei @ 2026-04-24 16:24 UTC (permalink / raw)
To: Dipayaan Roy, Jakub Kicinski
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, leitao, kees, john.fastabend,
hawk, bpf, daniel, ast, sdf, dipayanroy
In-Reply-To: <aeoVC27mIzoKytqA@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On 2026-04-23 05:48, Dipayaan Roy wrote:
> On Thu, Apr 16, 2026 at 08:31:46AM -0700, Jakub Kicinski wrote:
>> On Tue, 14 Apr 2026 09:00:56 -0700 Dipayaan Roy wrote:
>>> I still see roughly a 5% overhead from the atomic refcount operation
>>> itself, but on that platform there is no throughput drop when using
>>> page fragments versus full-page mode.
>>
>> That seems to contradict your claim that it's a problem with a specific
>> platform.. Since we're in the merge window I asked David Wei to try to
>> experiment with disabling page fragmentation on the ARM64 platforms we
>> have at Meta. If it repros we should use the generic rx-buf-len
>> ringparam because more NICs may want to implement this strategy.
>
> Hi Jakub,
>
> Thanks. I think I was not precise enough in my previous reply.
>
> What I meant is that the atomic refcount cost itself does not appear to
> be unique to the affected platform. I see a similar ~5% overhead on
> another ARM64 platformi (different vendor) as well. However, on that platform
> there is no throughput delta between fragment mode and full-page mode; both reach
> line rate.
>
> On the affected platform, fragment mode shows an additional ~15%
> throughput drop versus full-page mode. So the current data suggests that
> the atomic overhead is common, but the throughput regression is not
> explained by that overhead alone and likely depends on an additional
> platform-specific factor.
>
> Separately, the hardware team collected PCIe traces on the affected
> platform and reported stalls in the fragment-mode case that are not seen
> in full-page mode. They are still investigating the root cause, but
> their current hypothesis is that this is related to that platform’s
> PCIe/root-port microarchitecture rather than to page_pool refcounting
> alone.
>
> That said, I agree the right direction depends on whether this
> reproduces on other ARM64 platforms. If David is able to reproduce the
> same behavior, then using the generic rx-buf-len ringparam sounds like
> the better direction.
>
> Please let me know what David finds, and I can rework the patch
> accordingly.
Hi Dipayaan. Can you please share more details on your testing setup?
* What are you using as the test client/server? iperf3 or something
else?
* What do you mean specifically by "5% overhead from the atomic refcount
operation"? Some specific function?
* What are you using to measure? perf?
* How many queues, what is the napi softirq affinity?
* How many NUMA nodes? Does the problem only appear when crossing?
Thanks,
David
>
>
> Regards
> Dipayaan Roy
^ permalink raw reply
* Re: [PATCH bpf-next v3 1/9] bpf: Unify dynptr handling in the verifier
From: Andrii Nakryiko @ 2026-04-24 16:22 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <CAMB2axMw7mOs8kTFZG8Z1wn8fX4D0Si3Ge4F58DXKkBBQwrjyw@mail.gmail.com>
On Thu, Apr 23, 2026 at 10:34 PM Amery Hung <ameryhung@gmail.com> wrote:
>
> On Thu, Apr 23, 2026 at 5:04 PM Andrii Nakryiko
> <andrii.nakryiko@gmail.com> wrote:
> >
> > On Tue, Apr 21, 2026 at 3:10 PM Amery Hung <ameryhung@gmail.com> wrote:
> > >
> > > Simplify dynptr checking for helper and kfunc by unifying it. Remember
> > > the initialized dynptr (i.e.,g !(arg_type |= MEM_UNINIT)) pass to a
> > > dynptr kfunc during process_dynptr_func() so that we can easily
> > > retrieve the information for verification later. By saving it in
> > > meta->dynptr, there is no need to call dynptr helpers such as
> > > dynptr_id(), dynptr_ref_obj_id() and dynptr_type() in check_func_arg().
> > >
> > > Remove and open code the helpers in process_dynptr_func() when
> > > saving id, ref_obj_id, and type. It is okay to drop spi < 0 check as
> > > is_dynptr_reg_valid_init() has made sure the dynptr is valid.
> > >
> > > Besides, since dynptr ref_obj_id information is now pass around in
> > > meta->bpf_dynptr_desc, drop the check in helper_multiple_ref_obj_use.
> > >
> > > Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> > > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > > ---
> > > include/linux/bpf_verifier.h | 12 ++-
> > > kernel/bpf/verifier.c | 178 +++++++----------------------------
> > > 2 files changed, 41 insertions(+), 149 deletions(-)
> > >
> >
> > [...]
> >
> > > @@ -7433,7 +7426,8 @@ static int process_kptr_func(struct bpf_verifier_env *env, int regno,
> > > * and checked dynamically during runtime.
> > > */
> > > static int process_dynptr_func(struct bpf_verifier_env *env, int regno, int insn_idx,
> > > - enum bpf_arg_type arg_type, int clone_ref_obj_id)
> > > + enum bpf_arg_type arg_type, int clone_ref_obj_id,
> > > + struct bpf_dynptr_desc *dynptr)
> > > {
> > > struct bpf_reg_state *reg = reg_state(env, regno);
> > > int err;
> > > @@ -7499,6 +7493,20 @@ static int process_dynptr_func(struct bpf_verifier_env *env, int regno, int insn
> > > }
> > >
> > > err = mark_dynptr_read(env, reg);
> >
> > if mark_dynptr_read() fails, should we exit instead of proceeding to
> > fill out dynptr info?.. even if mark_dynptr_read() cannot fail because
> > of is_dynptr_reg_valid_init(), it still looks wrong and error-prone
>
> I think I will change mark_dynptr_read() to receive spi from the
> caller and make the function return void (It is technically nofail
> after liveness tracking code is removed). Then, move dynptr_get_spi()
> before it and don't error out. A comment seems to be enough.
yep, makes sense
>
> /* Cannot fail as we already make sure reg is valid dynptr */
> spi = dynptr_get_spi(env, reg);
>
> mark_dynptr_read(env, reg, spi);
>
> >
> > > +
> > > + if (dynptr) {
> > > + struct bpf_func_state *state = bpf_func(env, reg);
> > > + int spi;
> > > +
> > > + if (reg->type != CONST_PTR_TO_DYNPTR) {
> > > + spi = dynptr_get_spi(env, reg);
>
> ^ move this up
>
> > > + reg = &state->stack[spi].spilled_ptr;
> > > + }
> > > +
> > > + dynptr->id = reg->id;
> > > + dynptr->type = reg->dynptr.type;
> > > + dynptr->ref_obj_id = reg->ref_obj_id;
> > > + }
> > > }
> > > return err;
> > > }
> >
> > [...]
^ permalink raw reply
* Re: [PATCH] NFC: trf7970a: Ignore antenna noise when checking for RF field
From: Mark Greer @ 2026-04-24 16:20 UTC (permalink / raw)
To: Paul Geurts, sameo, linux-wireless, netdev, linux-kernel; +Cc: martijn.de.gouw
In-Reply-To: <20260422100930.581237-1-paul.geurts@prodrive-technologies.com>
On 4/22/26 3:09 AM, Paul Geurts wrote:
> The main channel Received Signal Strength Indicator (RSSI) measurement
> is used to determine whether an RF field is present or not. RSSI != 0
> is interpreted as an RF Field is present. This does not take RF noise
> and measurement inaccuracy into account, and results in false positives
> in the field.
>
> Define a noise level and make sure the RF field is only interpreted as
> present when the RSSI is above the noise level.
>
> Fixes: 851ee3cbf850 ("NFC: trf7970a: Don't turn on RF if there is already an RF field")
> Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
> ---
> drivers/nfc/trf7970a.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index d17c701c7888..08c27bb438b5 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -317,6 +317,7 @@
> #define TRF7970A_RSSI_OSC_STATUS_RSSI_MASK (BIT(2) | BIT(1) | BIT(0))
> #define TRF7970A_RSSI_OSC_STATUS_RSSI_X_MASK (BIT(5) | BIT(4) | BIT(3))
> #define TRF7970A_RSSI_OSC_STATUS_RSSI_OSC_OK BIT(6)
> +#define TRF7970A_RSSI_OSC_STATUS_RSSI_NOISE_LEVEL 1
>
> #define TRF7970A_SPECIAL_FCN_REG1_COL_7_6 BIT(0)
> #define TRF7970A_SPECIAL_FCN_REG1_14_ANTICOLL BIT(1)
> @@ -1300,7 +1301,7 @@ static int trf7970a_is_rf_field(struct trf7970a *trf, bool *is_rf_field)
> if (ret)
> return ret;
>
> - if (rssi & TRF7970A_RSSI_OSC_STATUS_RSSI_MASK)
> + if ((rssi & TRF7970A_RSSI_OSC_STATUS_RSSI_MASK) > TRF7970A_RSSI_OSC_STATUS_RSSI_NOISE_LEVEL)
> *is_rf_field = true;
> else
> *is_rf_field = false;
Given that false positives are happening in the field and assuming that
a value of 1 is enough to filter out those false positives, this seems
like a reasonable solution.
Reviewed-by: Mark Greer <mgreer@animalcreek.com>
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/9] Refactor verifier object relationship tracking
From: Amery Hung @ 2026-04-24 16:19 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Amery Hung, bpf, netdev, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <DI1FPX3685EI.3QPD29NY965FO@gmail.com>
On Fri, Apr 24, 2026 at 7:03 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu Apr 23, 2026 at 10:44 PM PDT, Amery Hung wrote:
> > On Thu, Apr 23, 2026 at 5:55 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> >>
> >> On Tue Apr 21, 2026 at 3:10 PM PDT, Amery Hung wrote:
> >> >
> >> > (3) Referenced dynptr with referenced parent:
> >> >
> >> > file (1,1,0)
> >> > ^ ^
> >> > bpf_dynptr_from_file | +-------------------------------+
> >> > | bpf_dynptr_clone(A, C) |
> >> > dynptr A (2,3,1) dynptr C (4,3,1)
> >> > ^ ^
> >> > | |
> >> > dynptr A and C have the same lifetime
> >>
> >> If I understand the proposal correctly above should be:
> >>
> >> file (1,0,0)
> >> ^
> >> bpf_dynptr_from_file +-------------------------------+
> >>
> >> ref_obj_id will be inited bpf_dynptr_clone() as 3 into A and C.
> >> but original file->ref_obj_id will be zero.
> >>
> >> ?
> >
> > This is the existing behavior. bpf_get_task_exe_file() is tagged with
> > (KF_ACQUIRE | KF_RET_NULL). Therefore, file will have id and
> > ref_obj_id both initialized to the same value. Here is the
> > corresponding verifier code:
> >
> > if (is_kfunc_acquire(&meta)) {
> > int id = acquire_reference(env, insn_idx);
> >
> > if (id < 0)
> > return id;
> > if (is_kfunc_ret_null(&meta))
> > regs[BPF_REG_0].id = id;
> > regs[BPF_REG_0].ref_obj_id = id;
>
> ok, but the arrow should still point to first '1', since that's
> what parent_id inherits?
Ohh yes. I totally missed the error. Thanks for pointing out.
^ permalink raw reply
* Re: [GIT PULL] Networking deletions for 7.1
From: Linus Torvalds @ 2026-04-24 16:17 UTC (permalink / raw)
To: Daniel Palmer; +Cc: Jakub Kicinski, davem, netdev, linux-kernel, pabeni
In-Reply-To: <CAFr9PXnNVL4mUEu19jMu2sPkOucGK7Q32iB-7FY8eUpKZY_XJA@mail.gmail.com>
On Fri, 24 Apr 2026 at 04:15, Daniel Palmer <daniel@0x0f.com> wrote:
>
> For the drivers I really don't think enough time was given for people
> to come out of the woodwork and say they are using one of them and if
> they'd be willing to maintain it or not.
I don't think we'd ever have that.
> If this does get merged and someone wants to put one of them back will
> it be as simple as sending a revert?
I think we can easily resurrect individual drivers if there are actual users.
I'm looking at that 3c509 one and have memories of it being a good
card. But Christ, those memories are from three decades ago and using
BNC connectors. I can't actually imagine anybody *using* them any
more, except in museum setups.
Linus
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next] libie: log more info when virtchnl fails
From: Loktionov, Aleksandr @ 2026-04-24 16:07 UTC (permalink / raw)
To: Li Li, Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller,
Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
David Decotigny, Singhai, Anjali, Samudrala, Sridhar,
Brian Vazquez, Tantilov, Emil S
In-Reply-To: <20260424031545.3777023-1-boolli@google.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Li Li via Intel-wired-lan
> Sent: Friday, April 24, 2026 5:16 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; David S. Miller
> <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Eric Dumazet
> <edumazet@google.com>; intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David
> Decotigny <decot@google.com>; Singhai, Anjali
> <anjali.singhai@intel.com>; Samudrala, Sridhar
> <sridhar.samudrala@intel.com>; Brian Vazquez <brianvv@google.com>; Li
> Li <boolli@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next] libie: log more info when
> virtchnl fails
>
> Virtchnl failures can be hard to debug without logs. Logging the
> details of virtchnl transactions can be useful for debugging virtchnl-
> related issues.
>
> Tested: Built and booted on a test machine.
>
> Signed-off-by: Li Li <boolli@google.com>
> ---
> drivers/net/ethernet/intel/libie/controlq.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/libie/controlq.c
> b/drivers/net/ethernet/intel/libie/controlq.c
> index ebc05355e39d..7eaa77413621 100644
> --- a/drivers/net/ethernet/intel/libie/controlq.c
> +++ b/drivers/net/ethernet/intel/libie/controlq.c
> @@ -762,6 +762,16 @@ libie_ctlq_xn_process_recv(struct
> libie_ctlq_xn_recv_params *params,
> status = ctlq_msg->chnl_retval ? -EFAULT : 0;
>
> xn = &xnm->ring[xn_index];
> +
> + if (ctlq_msg->chnl_retval) {
> + dev_err_ratelimited(
> + params->ctlq->dev,
> + "Non-zero virtchnl ret val (msg op: %u, ret val:
> %u, msg_cookie: %u, data_len: %u); xn op: %u, id: %u, cookie: %u\n",
> + ctlq_msg->chnl_opcode, ctlq_msg->chnl_retval,
> + msg_cookie, ctlq_msg->data_len, xn-
> >virtchnl_opcode,
> + xn->index, xn->cookie);
> + }
> +
> if (ctlq_msg->chnl_opcode != xn->virtchnl_opcode ||
> msg_cookie != xn->cookie)
> return false;
> @@ -1011,6 +1021,11 @@ int libie_ctlq_xn_send(struct
> libie_ctlq_xn_send_params *params)
> params->recv_mem = xn->recv_mem;
> break;
> default:
> + dev_notice_ratelimited(
> + params->ctlq->dev,
> + "Transaction failed (op %u, xn state: %d, id: %u,
> cookie: %u, size: %zu)\n",
> + params->chnl_opcode, xn->state, xn->index, xn-
> >cookie,
> + xn->recv_mem.iov_len);
For me dev_notice_ratelimited() level is low for a failure messages.
Why not dev_warn_ratelimited() instead?
> ret = -EBADMSG;
> break;
> }
> --
> 2.54.0.rc2.544.gc7ae2d5bb8-goog
^ permalink raw reply
* RE: [PATCH net v4 4/4] ice: skip unnecessary VF reset when setting trust
From: Loktionov, Aleksandr @ 2026-04-24 16:05 UTC (permalink / raw)
To: Loktionov, Aleksandr, Jose Ignacio Tornos Martinez,
netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org, Kitszel, Przemyslaw,
Keller, Jacob E, horms@kernel.org, jesse.brandeburg@intel.com,
Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
In-Reply-To: <IA3PR11MB89862412A9F682D59474841DE52A2@IA3PR11MB8986.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Loktionov, Aleksandr
> Sent: Thursday, April 23, 2026 3:17 PM
> To: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>;
> netdev@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; horms@kernel.org;
> jesse.brandeburg@intel.com; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> edumazet@google.com; kuba@kernel.org; pabeni@redhat.com
> Subject: Re: [Intel-wired-lan] [PATCH net v4 4/4] ice: skip
> unnecessary VF reset when setting trust
>
>
>
> > -----Original Message-----
> > From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> > Sent: Thursday, April 23, 2026 3:04 PM
> > To: netdev@vger.kernel.org
> > Cc: intel-wired-lan@lists.osuosl.org; Kitszel, Przemyslaw
> > <przemyslaw.kitszel@intel.com>; Loktionov, Aleksandr
> > <aleksandr.loktionov@intel.com>; Keller, Jacob E
> > <jacob.e.keller@intel.com>; horms@kernel.org;
> > jesse.brandeburg@intel.com; Nguyen, Anthony L
> > <anthony.l.nguyen@intel.com>; davem@davemloft.net;
> > edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; Jose
> Ignacio
> > Tornos Martinez <jtornosm@redhat.com>
> > Subject: [PATCH net v4 4/4] ice: skip unnecessary VF reset when
> > setting trust
> >
> > Similar to the i40e fix, ice_set_vf_trust() unconditionally calls
> > ice_reset_vf() when the trust setting changes. While the delay is
> > smaller than i40e this reset is still unnecessary in most cases.
> >
> > Additionally, the original code has a race condition: it deletes MAC
> > LLDP filters BEFORE resetting the VF. During this deletion, the VF
> is
> > still ACTIVE and can add new MAC LLDP filters concurrently,
> > potentially corrupting the filter list.
> >
> > When granting trust, no reset is needed - we can just set the
> > capability flag to allow privileged operations.
> >
> > When revoking trust, we need to:
> > 1. Clear the capability flag to block privileged operations 2.
> Disable
> > promiscuous mode if it was enabled (trusted VFs can enable it) 3.
> Only
> > reset if MAC LLDP filters exist (to clean them up)
> >
> > When we do reset (MAC LLDP case), we fix the race condition by
> > resetting first to clear VF state (which blocks new MAC LLDP filter
> > additions), then delete existing filters safely. During cleanup, vf-
> > >trusted remains true so
> > ice_vf_is_lldp_ena() works properly. Only after cleanup do we set
> > vf->trusted = false.
> >
> > When we don't reset, we manually handle capability flag and
> > promiscuous mode via helper function.
> >
> > The ice driver already has logic to clean up MAC LLDP filters when
> > removing trust. After this cleanup, the VF reset is only necessary
> if
> > there were actually filters to remove (num_mac_lldp was non-zero).
> >
> > This saves time and eliminates unnecessary service disruption when
> > changing VF trust settings in most cases, while properly handling
> > filter cleanup.
> >
> > Fixes: 2296345416b0 ("ice: receive LLDP on trusted VFs")
> For me it looks like cc: stable@vger.kernel.org must be added
>
> > Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> > ---
> > v4:
> > - Address AI review (sashiko.dev) from Simon Horman:
> > vf->trusted ordering bug
> > - Fix upstream race condition when comparing with i40e code
> > - Apply capability flag and promiscuous mode fixes from i40e AI
> > review
> > - Add helper function ice_setup_vf_trust() for non-reset path
> > - Export ice_vf_clear_all_promisc_modes() for code reuse
> > v3: https://lore.kernel.org/all/20260414110006.124286-5-
> > jtornosm@redhat.com/
> >
> > drivers/net/ethernet/intel/ice/ice_sriov.c | 41
> +++++++++++++++++++-
> > - drivers/net/ethernet/intel/ice/ice_vf_lib.c | 2 +-
> > drivers/net/ethernet/intel/ice/ice_vf_lib.h | 1 +
> > 3 files changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> > b/drivers/net/ethernet/intel/ice/ice_sriov.c
> > index 7e00e091756d..d0da7f6adc23 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
> > @@ -1364,6 +1364,34 @@ int ice_set_vf_mac(struct net_device *netdev,
> > int vf_id, u8 *mac)
> > return __ice_set_vf_mac(ice_netdev_to_pf(netdev), vf_id, mac);
> }
> >
> > +/**
> > + * ice_setup_vf_trust - Enable/disable VF trust mode without reset
> > + * @vf: VF to configure
> > + * @setting: trust setting
> > + *
> > + * Manually handle capability flag and promiscuous mode when
> changing
> > +trust
> > + * without performing a VF reset.
> > + * When reset is performed, this is not necessary as the reset
> > +procedure
> > + * already handles this.
> > + **/
One more nit, kdoc should end with '*/' not '**/'
With the best regards
Alex
> > +static void ice_setup_vf_trust(struct ice_vf *vf, bool setting) {
> > + struct ice_vsi *vsi;
> > +
> > + if (setting) {
> > + set_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> > + } else {
> > + clear_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
> > +
> > + if (test_bit(ICE_VF_STATE_UC_PROMISC, vf->vf_states) ||
> > + test_bit(ICE_VF_STATE_MC_PROMISC, vf->vf_states)) {
> > + vsi = ice_get_vf_vsi(vf);
> > + if (vsi)
> > + ice_vf_clear_all_promisc_modes(vf, vsi);
> You declare ice_vf_clear_all_promisc_modes() returning int, but ignore
> the return value.
> Looks suspicious isn't it?
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>
> > + }
> > + }
> > +}
> > +
> > /**
> > * ice_set_vf_trust
> > * @netdev: network interface device structure @@ -1399,11 +1427,16
> > @@ int ice_set_vf_trust(struct net_device *netdev, int vf_id, bool
> > trusted)
> >
> > mutex_lock(&vf->cfg_lock);
> >
> > - while (!trusted && vf->num_mac_lldp)
> > - ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf),
> > false);
> > -
> > + /* Reset only if revoking trust with MAC LLDP filters */
> > + if (!trusted && vf->num_mac_lldp) {
> > + ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> > + while (vf->num_mac_lldp)
> > + ice_vf_update_mac_lldp_num(vf,
> > ice_get_vf_vsi(vf), false);
> > + } else {
> > + ice_setup_vf_trust(vf, trusted);
> > + }
> > vf->trusted = trusted;
> > - ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> > +
> > dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n",
> > vf_id, trusted ? "" : "un");
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> > b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> > index c8bc952f05cd..81bbf30e5c29 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> > @@ -623,7 +623,7 @@ ice_vf_get_promisc_masks(struct ice_vf *vf,
> struct
> > ice_vsi *vsi,
> > *
> > * Clear all promiscuous/allmulticast filters for a VF
> > */
> > -static int
> > +int
> > ice_vf_clear_all_promisc_modes(struct ice_vf *vf, struct ice_vsi
> > *vsi) {
> > struct ice_pf *pf = vf->pf;
> > diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> > b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> > index 7a9c75d1d07c..a3501bd92311 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> > +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
> > @@ -310,6 +310,7 @@ bool ice_is_any_vf_in_unicast_promisc(struct
> > ice_pf *pf); void ice_vf_get_promisc_masks(struct ice_vf *vf,
> struct
> > ice_vsi *vsi,
> > u8 *ucast_m, u8 *mcast_m);
> > +int ice_vf_clear_all_promisc_modes(struct ice_vf *vf, struct
> ice_vsi
> > +*vsi);
> > int
> > ice_vf_set_vsi_promisc(struct ice_vf *vf, struct ice_vsi *vsi, u8
> > promisc_m); int
> > --
> > 2.53.0
^ permalink raw reply
* Re: [PATCH v3] net: phy: air_en8811h: add AN8811HB MCU assert/deassert support
From: Lucien.Jheng @ 2026-04-24 15:59 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew, hkallweit1, linux, davem, edumazet, pabeni, netdev,
linux-kernel, bjorn, ericwouds, frank-w, daniel, lucien.jheng,
albert-al.lee
In-Reply-To: <20260423102102.0192b7de@kernel.org>
Jakub Kicinski 於 2026/4/24 上午 01:21 寫道:
> Since you need to repost to fix the fixes tag, plaese also improve the
> error handling
>
> On Mon, 20 Apr 2026 21:45:06 +0800 Lucien.Jheng wrote:
>> static int an8811hb_probe(struct phy_device *phydev)
>> {
>> + struct mdio_device *mdiodev;
>> struct en8811h_priv *priv;
>> int ret;
>>
>> @@ -1175,10 +1281,22 @@ static int an8811hb_probe(struct phy_device *phydev)
>> return -ENOMEM;
>> phydev->priv = priv;
>>
>> + mdiodev = mdio_device_create(phydev->mdio.bus,
>> + phydev->mdio.addr + EN8811H_PBUS_ADDR_OFFS);
>> + if (IS_ERR(mdiodev))
>> + return PTR_ERR(mdiodev);
>> +
>> + ret = mdio_device_register(mdiodev);
>> + if (ret) {
> goto err_dev_free;
>
>> + mdio_device_free(mdiodev);
>> + return ret;
>> + }
>> + priv->pbusdev = mdiodev;
>> +
>> ret = an8811hb_load_firmware(phydev);
>> if (ret < 0) {
>> phydev_err(phydev, "Load firmware failed: %d\n", ret);
>> - return ret;
>> + goto error;
> goto err_dev_create;
>
>> }
>>
>> en8811h_print_fw_version(phydev);
>> @@ -1191,22 +1309,27 @@ static int an8811hb_probe(struct phy_device *phydev)
>>
>> ret = en8811h_leds_setup(phydev);
>> if (ret < 0)
>> - return ret;
>> + goto error;
>>
>> priv->phydev = phydev;
>> /* Co-Clock Output */
>> ret = an8811hb_clk_provider_setup(&phydev->mdio.dev, &priv->hw);
>> if (ret)
>> - return ret;
>> + goto error;
>>
>> /* Configure led gpio pins as output */
>> ret = air_buckpbus_reg_modify(phydev, AN8811HB_GPIO_OUTPUT,
>> AN8811HB_GPIO_OUTPUT_345,
>> AN8811HB_GPIO_OUTPUT_345);
>> if (ret < 0)
>> - return ret;
>> + goto error;
>>
>> return 0;
>> +
>> +error:
> err_dev_free:
>
>> + mdio_device_remove(priv->pbusdev);
> err_dev_create:
>
>> + mdio_device_free(priv->pbusdev);
>> + return ret;
I will include this in the next patch.
^ permalink raw reply
* Re: [PATCH v3] net: phy: air_en8811h: add AN8811HB MCU assert/deassert support
From: Lucien.Jheng @ 2026-04-24 15:57 UTC (permalink / raw)
To: Andrew Lunn, Paolo Abeni
Cc: hkallweit1, linux, davem, edumazet, kuba, netdev, linux-kernel,
bjorn, ericwouds, frank-w, daniel, lucien.jheng, albert-al.lee
In-Reply-To: <18d653c9-e8fe-48ed-9524-869f79a63121@lunn.ch>
Andrew Lunn 於 2026/4/23 下午 07:58 寫道:
>>> @@ -1175,10 +1281,22 @@ static int an8811hb_probe(struct phy_device *phydev)
>>> return -ENOMEM;
>>> phydev->priv = priv;
>>>
>>> + mdiodev = mdio_device_create(phydev->mdio.bus,
>>> + phydev->mdio.addr + EN8811H_PBUS_ADDR_OFFS);
>> Sashiko says:
>>
>> Can this create an out-of-bounds array access if the base PHY address is
>> high?
>> The mdio_map array in struct mii_bus has a fixed size of PHY_MAX_ADDR (32).
>> If phydev->mdio.addr is 24 or higher, adding EN8811H_PBUS_ADDR_OFFS (8)
>> will result in an address of 32 or more.
>> Neither mdio_device_create() nor mdio_device_register() validate that
>> the address is within PHY_MAX_ADDR. When mdiobus_register_device()
>> executes mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev, could this
>> write past the end of the array and corrupt adjacent memory?
> This has been discussed once, but Sashiko has a shorter memory than a
> goldfish. It is guaranteed by hardware design that + 8 will work.
Got it
Thanks
>
> Andrew
^ permalink raw reply
* Re: [PATCH 03/23] tick/nohz: Make nohz_full parameter optional
From: Frederic Weisbecker @ 2026-04-24 15:57 UTC (permalink / raw)
To: Waiman Long
Cc: Thomas Gleixner, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Paul E. McKenney, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Boqun Feng, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Anna-Maria Behnsen,
Ingo Molnar, Chen Ridong, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Ben Segall, Mel Gorman,
Valentin Schneider, K Prateek Nayak, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, cgroups,
linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan
In-Reply-To: <3b796360-81e4-4f90-9b19-8a9f21cbac07@redhat.com>
Le Tue, Apr 21, 2026 at 10:14:09AM -0400, Waiman Long a écrit :
11;rgb:2e2e/3434/3636> On 4/21/26 4:32 AM, Thomas Gleixner wrote:
> > On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> > > To provide nohz_full tick support, there is a set of tick dependency
> > > masks that need to be evaluated on every IRQ and context switch.
> > s/IRQ/interrupt/
> >
> > This is a changelog and not a SMS service.
> > > Switching on nohz_full tick support at runtime will be problematic
> > > as some of the tick dependency masks may not be properly set causing
> > > problem down the road.
> > That's useless blurb with zero content.
> >
> > > Allow nohz_full boot option to be specified without any
> > > parameter to force enable nohz_full tick support without any
> > > CPU in the tick_nohz_full_mask yet. The context_tracking_key and
> > > tick_nohz_full_running flag will be enabled in this case to make
> > > tick_nohz_full_enabled() return true.
> > I kinda can crystal-ball what you are trying to say here, but that does
> > not make it qualified as a proper change log.
> >
> > > There is still a small performance overhead by force enable nohz_full
> > > this way. So it should only be used if there is a chance that some
> > > CPUs may become isolated later via the cpuset isolated partition
> > > functionality and better CPU isolation closed to nohz_full is desired.
> > Why has this key to be enabled on boot if there are no CPUs in the
> > isolated mask?
> >
> > If you want to manage this dynamically at runtime then enable the key
> > once CPUs are isolated. Yes, it's more work, but that avoids the "should
> > only be used" nonsense and makes this more robust down the road.
>
> OK, I will try to make it fully dynamic. Of course, it will be more work.
Since the target CPUs will be offline, it should be fine to just enable/disable
the static key and masks on runtime. The only issue I see right now is posix
CPU timers because the tick dependency is per task/process group. And those
tasks could migrate to nohz_full CPUs by careless users (even though that's
nonsense) once the target become online. So the per task/process tick dependency
must be set up unconditionally. I don't think this should bring much noticeable
overhead though.
Oh and the other way to go, that is removing TICK_DEP_BIT_POSIX_TIMER and forbid to
run posix cpu timers on nohz_full CPUs, would be even more painful to implement
so I don't have a better idea.
Thanks.
--
Frederic Weisbecker
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3] net: phy: air_en8811h: add AN8811HB MCU assert/deassert support
From: Lucien.Jheng @ 2026-04-24 15:56 UTC (permalink / raw)
To: Paolo Abeni, andrew, hkallweit1, linux, davem, edumazet, kuba,
netdev, linux-kernel, bjorn
Cc: ericwouds, frank-w, daniel, lucien.jheng, albert-al.lee
In-Reply-To: <2f6fd850-e187-4e63-9a32-6b4b72c09905@redhat.com>
Paolo Abeni 於 2026/4/23 下午 07:19 寫道:
> On 4/20/26 3:45 PM, Lucien.Jheng wrote:
>> AN8811HB needs a MCU soft-reset cycle before firmware loading begins.
>> Assert the MCU (hold it in reset) and immediately deassert (release)
>> via a dedicated PBUS register pair (0x5cf9f8 / 0x5cf9fc), accessed
>> through a registered mdio_device at PHY-addr+8.
>>
>> Add __air_pbus_reg_write() as a low-level helper taking a struct
>> mdio_device *, create and register the PBUS mdio_device in
>> an8811hb_probe() and store it in priv->pbusdev, then implement
>> an8811hb_mcu_assert() / _deassert() on top of it. Add
>> an8811hb_remove() to unregister the PBUS device on teardown. Wire
>> both calls into an8811hb_load_firmware() and en8811h_restart_mcu()
>> so every firmware load or MCU restart on AN8811HB correctly sequences
>> the reset control registers.
>>
>> Fixes: 0a55766b7711 ("net: phy: air_en8811h: add Airoha AN8811HB support")
> The hash is incorrect, should be 5afda1d734ed
I will fix it in the next patch.
>
> [...]
>> @@ -254,6 +267,31 @@ static int air_phy_write_page(struct phy_device *phydev, int page)
>> return __phy_write(phydev, AIR_EXT_PAGE_ACCESS, page);
>> }
>>
>> +static int __air_pbus_reg_write(struct mdio_device *mdiodev,
>> + u32 pbus_reg, u32 pbus_data)
>> +{
>> + int ret;
>> +
>> + ret = __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_EXT_PAGE_ACCESS,
>> + upper_16_bits(pbus_reg));
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_PBUS_ADDR_HIGH,
>> + (pbus_reg & GENMASK(15, 6)) >> 6);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = __mdiobus_write(mdiodev->bus, mdiodev->addr,
>> + (pbus_reg & GENMASK(5, 2)) >> 2,
>> + lower_16_bits(pbus_data));
>> + if (ret < 0)
>> + return ret;
>> +
>> + return __mdiobus_write(mdiodev->bus, mdiodev->addr, AIR_PBUS_DATA_HIGH,
>> + upper_16_bits(pbus_data));
> Sashiko says:
>
> Will writing the lower 16 bits before the upper 16 bits cause the
> hardware transaction to fire with stale upper data?
> The __air_buckpbus_reg_write() helper triggers the 32-bit transaction
> using the lower 16 bits as the execution trigger. If this hardware
> behaves similarly, should AIR_PBUS_DATA_HIGH be populated before writing
> the lower 16 bits?
This is an8811hb pbus sequence. Therefore, it doesn't need to be modified.
> [...]
>> @@ -1175,10 +1281,22 @@ static int an8811hb_probe(struct phy_device *phydev)
>> return -ENOMEM;
>> phydev->priv = priv;
>>
>> + mdiodev = mdio_device_create(phydev->mdio.bus,
>> + phydev->mdio.addr + EN8811H_PBUS_ADDR_OFFS);
> Sashiko says:
>
> Can this create an out-of-bounds array access if the base PHY address is
> high?
> The mdio_map array in struct mii_bus has a fixed size of PHY_MAX_ADDR (32).
> If phydev->mdio.addr is 24 or higher, adding EN8811H_PBUS_ADDR_OFFS (8)
> will result in an address of 32 or more.
> Neither mdio_device_create() nor mdio_device_register() validate that
> the address is within PHY_MAX_ADDR. When mdiobus_register_device()
> executes mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev, could this
> write past the end of the array and corrupt adjacent memory?
>
> /P
>
^ permalink raw reply
* Re: [PATCH 0/9] bitfield: add FIELD_GET_SIGNED()
From: Yury Norov @ 2026-04-24 15:50 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, David Lechner,
Nuno Sá, Andy Shevchenko, Ping-Ke Shih, Richard Cochran,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Alexandre Belloni, Yury Norov, Rasmus Villemoes,
Hans de Goede, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260424130927.349ad3ae@jic23-huawei>
On Fri, Apr 24, 2026 at 01:09:27PM +0100, Jonathan Cameron wrote:
> On Fri, 17 Apr 2026 13:36:11 -0400
> Yury Norov <ynorov@nvidia.com> wrote:
>
> > The bitfields are designed in assumption that fields contain unsigned
> > integer values, thus extracting the values from the field implies
> > zero-extending.
> >
> > Some drivers need to sign-extend their fields, and currently do it like:
> >
> > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> >
> > It's error-prone because it relies on user to provide the correct
> > index of the most significant bit.
> >
> > This series adds a signed version of FIELD_GET(), which is the more
> > convenient and compiles (on x86_64) to just a couple instructions:
> > shl and sar.
> >
> > Patch #1 adds FIELD_GET_SIGNED(), and the rest of the series applies it
> > tree-wide.
> >
>
> Just a quick heads up that I'm beginning to assume that this series
> will land in some form. If it does can we do it as an immutable branch
> as I'm suggesting it gets used in some other patches in that should land
> in the new cycle.
I'm going to submit v2 soon, as seemingly the discussion is boiled
down, and then will likely merge it with my tree. I'll create an
immutable branch for you before the end of day.
Thanks,
Yury
^ permalink raw reply
* Re: Re: Re: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
From: 王明煜 @ 2026-04-24 15:40 UTC (permalink / raw)
To: Bezdeka, Florian
Cc: willemdebruijn.kernel@gmail.com,
syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com,
davem@davemloft.net, dsahern@kernel.org, sd@queasysnail.net,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
horms@kernel.org, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
In-Reply-To: <68628d54304821fe8410e756ce3f92c60da10e1d.camel@siemens.com>
Hi Florian and Sabrina,
I checked the stable branches for a potential backport. It turns out no backport is needed because the stable trees are not affected by this specific leak path.
Looking closely at `ip6_setup_cork()` in the stable trees, `cork->base.dst = &rt->dst;` is assigned at the very beginning of the function.
If a subsequent memory allocation fails (e.g., `kzalloc` failing due to failslab), it returns `-ENOBUFS`, but the `dst` reference is already linked to the cork. When `ip6_make_skb()` catches this error, it calls `ip6_cork_release(cork, &v6_cork)`, which successfully frees the `dst`.
As Sabrina correctly pointed out regarding my v1, adding an explicit `dst_release()` here would actually cause a double free.
The original syzbot memory leak report under `failslab` seems to be a false positive or related to a different object entirely. The `dst_entry` handling in this error path is already robust.
This issue can be closed without any patches. Thanks for the discussion.
Best regards,
Mingyu Wang
> -----原始邮件-----
> 发件人: "Bezdeka, Florian" <florian.bezdeka@siemens.com>
> 发送时间:2026-04-24 14:56:35 (星期五)
> 收件人: "willemdebruijn.kernel@gmail.com" <willemdebruijn.kernel@gmail.com>, "25181214217@stu.xidian.edu.cn" <25181214217@stu.xidian.edu.cn>
> 抄送: "syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com" <syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com>, "davem@davemloft.net" <davem@davemloft.net>, "dsahern@kernel.org" <dsahern@kernel.org>, "sd@queasysnail.net" <sd@queasysnail.net>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "horms@kernel.org" <horms@kernel.org>, "edumazet@google.com" <edumazet@google.com>, "kuba@kernel.org" <kuba@kernel.org>, "pabeni@redhat.com" <pabeni@redhat.com>
> 主题: Re: Re: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
>
> On Fri, 2026-04-24 at 11:26 +0800, 王明煜 wrote:
> > Hi Sabrina and Jakub,
> >
> > Before sending out the v3 patch, I synced my tree to the latest mainline and checked the current state of `ip6_make_skb()`.
> >
> > It turns out that the missing `ip6_cork_release(cork)` in the error path was already naturally resolved by Eric Dumazet's recent refactoring commit:
> > b409a7f7176b ("ipv6: colocate inet6_cork in inet_cork_full")
> >
> > With Eric's changes, the error handling now correctly calls `ip6_cork_release(cork)` if `ip6_setup_cork()` fails, meaning the memory leak is no longer present in the latest tree.
>
> Fine, so mainline is correct now. What about the stable trees? Did you
> check them already?
>
> Florian
>
> >
> > Please disregard my v1 and v2 patches. I am also telling syzbot to close this report based on Eric's commit.
> >
> > Thank you all again for your time, the deep code review, and for guiding me to find the true root cause. I learned a huge amount from this discussion!
> >
> > #syz fix: ipv6: colocate inet6_cork in inet_cork_full
> >
> > Best regards,
> > Mingyu Wang
> >
> > 2026-04-24 11:16:30 "王明煜" <25181214217@stu.xidian.edu.cn> 写道：
> > > Hi,
> > >
> > > Thank you so much for the review and for pointing me to the correct Fixes tag!
> > >
> > > You hit the nail on the head regarding `__ip6_append_data()`. After re-evaluating the code path based on your question, I realize my assumption in v2 was incorrect. `__ip6_append_data()` does indeed guarantee that an skb is queued upon success, making the `skb == NULL` path dead code in this context.
> > >
> > > I traced the `failslab` memory leak back to its true origin: the lockless fast path wrapper `ip6_make_skb()`.
> > >
> > > Sabrina previously noted that `ip6_setup_cork()` failures correctly release the dst. That is absolutely true for the slow path, where `udp_v6_flush_pending_frames()` eventually handles the cleanup.
> > >
> > > However, in the fast path, `ip6_make_skb()` calls `ip6_setup_cork()`. Inside `ip6_setup_cork()`, `cork->base.dst` is assigned early. If a subsequent memory allocation fails (e.g., `v6_cork->opt = kzalloc(...)` failing due to failslab), it returns an error. `ip6_make_skb()` then directly returns `ERR_PTR(err)` WITHOUT calling `ip6_cork_release(cork)`.
> > >
> > > Since `udpv6_sendmsg()` assumes the `dst` reference is stolen by `ip6_make_skb()` and unconditionally jumps to `out_no_dst`, the `dst` is completely leaked.
> > >
> > > The fix is simply to add `ip6_cork_release(cork)` in the `ip6_setup_cork()` error path inside `ip6_make_skb()`.
> > >
> > > I will submit a v3 patch shortly addressing this true root cause and using your suggested Fixes tag. Thank you again for steering me in the exact right direction!
> > >
> > > Best regards,
> > > Mingyu Wang
> > >
> > >
> > > > -----原始邮件-----
> > > > 发件人: "Willem de Bruijn" <willemdebruijn.kernel@gmail.com>
> > > > 发送时间:2026-04-23 22:59:45 (星期四)
> > > > 收件人: "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, willemdebruijn.kernel@gmail.com, davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
> > > > 抄送: sd@queasysnail.net, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
> > > > 主题: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
> > > >
> > > > Mingyu Wang wrote:
> > > > > During fuzzing with failslab enabled, a memory leak was observed in the
> > > > > IPv6 UDP send path.
> > > > >
> > > > > The root cause resides in __ip6_make_skb(). In extremely rare cases
> > > > > (such as fault injection or specific empty payload conditions),
> > > >
> > > > Can you elaborate on this? Which fault injection lets
> > > > __ip6_append_data succeed without writing data?
> > > >
> > > > > __ip6_append_data() may succeed but leave the socket's write queue
> > > > > empty.
> > > > >
> > > > > When __ip6_make_skb() is subsequently called, __skb_dequeue(queue)
> > > > > returns NULL. The previous logic handled this by executing a 'goto out;',
> > > > > which completely bypassed the call to ip6_cork_release(cork).
> > > > >
> > > > > Since the 'cork' structure actively holds a reference to the routing
> > > > > entry (dst_entry) and potentially other allocated options, skipping
> > > > > the release cleanly leaks these resources.
> > > > >
> > > > > Fix this by introducing an 'out_cork_release' label and jumping to it
> > > > > when skb is NULL, ensuring the cork state is always properly cleaned up.
> > > > > The now-unused 'out' label is also removed to prevent compiler warnings.
> > > > >
> > > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > >
> > > > I think this is
> > > >
> > > > Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
> > > >
> > > > > Reported-by: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
> > > > > Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
^ permalink raw reply
* Re: Re: Re: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
From: syzbot @ 2026-04-24 15:40 UTC (permalink / raw)
To: 25181214217
Cc: 25181214217, davem, dsahern, edumazet, florian.bezdeka, horms,
kuba, linux-kernel, netdev, pabeni, sd, willemdebruijn.kernel
In-Reply-To: <378c89ac.7c26.19dc0263038.Coremail.25181214217@stu.xidian.edu.cn>
> Hi Florian and Sabrina,
>
> I checked the stable branches for a potential backport. It turns out no backport is needed because the stable trees are not affected by this specific leak path.
>
> Looking closely at `ip6_setup_cork()` in the stable trees, `cork->base.dst = &rt->dst;` is assigned at the very beginning of the function.
>
> If a subsequent memory allocation fails (e.g., `kzalloc` failing due to failslab), it returns `-ENOBUFS`, but the `dst` reference is already linked to the cork. When `ip6_make_skb()` catches this error, it calls `ip6_cork_release(cork, &v6_cork)`, which successfully frees the `dst`.
>
> As Sabrina correctly pointed out regarding my v1, adding an explicit `dst_release()` here would actually cause a double free.
>
> The original syzbot memory leak report under `failslab` seems to be a false positive or related to a different object entirely. The `dst_entry` handling in this error path is already robust.
>
> This issue can be closed without any patches. Thanks for the discussion.
>
> Best regards,
> Mingyu Wang
>
>
>> -----原始邮件-----
>> 发件人: "Bezdeka, Florian" <florian.bezdeka@siemens.com>
>> 发送时间:2026-04-24 14:56:35 (星期五)
>> 收件人: "willemdebruijn.kernel@gmail.com" <willemdebruijn.kernel@gmail.com>, "25181214217@stu.xidian.edu.cn" <25181214217@stu.xidian.edu.cn>
>> 抄送: "syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com" <syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com>, "davem@davemloft.net" <davem@davemloft.net>, "dsahern@kernel.org" <dsahern@kernel.org>, "sd@queasysnail.net" <sd@queasysnail.net>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "horms@kernel.org" <horms@kernel.org>, "edumazet@google.com" <edumazet@google.com>, "kuba@kernel.org" <kuba@kernel.org>, "pabeni@redhat.com" <pabeni@redhat.com>
>> 主题: Re: Re: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
>>
>> On Fri, 2026-04-24 at 11:26 +0800, 王明煜 wrote:
>> > Hi Sabrina and Jakub,
>> >
>> > Before sending out the v3 patch, I synced my tree to the latest mainline and checked the current state of `ip6_make_skb()`.
>> >
>> > It turns out that the missing `ip6_cork_release(cork)` in the error path was already naturally resolved by Eric Dumazet's recent refactoring commit:
>> > b409a7f7176b ("ipv6: colocate inet6_cork in inet_cork_full")
>> >
>> > With Eric's changes, the error handling now correctly calls `ip6_cork_release(cork)` if `ip6_setup_cork()` fails, meaning the memory leak is no longer present in the latest tree.
>>
>> Fine, so mainline is correct now. What about the stable trees? Did you
>> check them already?
>>
>> Florian
>>
>> >
>> > Please disregard my v1 and v2 patches. I am also telling syzbot to close this report based on Eric's commit.
>> >
>> > Thank you all again for your time, the deep code review, and for guiding me to find the true root cause. I learned a huge amount from this discussion!
>> >
>> > #syz fix: ipv6: colocate inet6_cork in inet_cork_full
>> >
>> > Best regards,
>> > Mingyu Wang
>> >
>> > 2026-04-24 11:16:30 "王明煜" <25181214217@stu.xidian.edu.cn> 写道：
>> > > Hi,
>> > >
>> > > Thank you so much for the review and for pointing me to the correct Fixes tag!
>> > >
>> > > You hit the nail on the head regarding `__ip6_append_data()`. After re-evaluating the code path based on your question, I realize my assumption in v2 was incorrect. `__ip6_append_data()` does indeed guarantee that an skb is queued upon success, making the `skb == NULL` path dead code in this context.
>> > >
>> > > I traced the `failslab` memory leak back to its true origin: the lockless fast path wrapper `ip6_make_skb()`.
>> > >
>> > > Sabrina previously noted that `ip6_setup_cork()` failures correctly release the dst. That is absolutely true for the slow path, where `udp_v6_flush_pending_frames()` eventually handles the cleanup.
>> > >
>> > > However, in the fast path, `ip6_make_skb()` calls `ip6_setup_cork()`. Inside `ip6_setup_cork()`, `cork->base.dst` is assigned early. If a subsequent memory allocation fails (e.g., `v6_cork->opt = kzalloc(...)` failing due to failslab), it returns an error. `ip6_make_skb()` then directly returns `ERR_PTR(err)` WITHOUT calling `ip6_cork_release(cork)`.
>> > >
>> > > Since `udpv6_sendmsg()` assumes the `dst` reference is stolen by `ip6_make_skb()` and unconditionally jumps to `out_no_dst`, the `dst` is completely leaked.
>> > >
>> > > The fix is simply to add `ip6_cork_release(cork)` in the `ip6_setup_cork()` error path inside `ip6_make_skb()`.
>> > >
>> > > I will submit a v3 patch shortly addressing this true root cause and using your suggested Fixes tag. Thank you again for steering me in the exact right direction!
>> > >
>> > > Best regards,
>> > > Mingyu Wang
>> > >
>> > >
>> > > > -----原始邮件-----
>> > > > 发件人: "Willem de Bruijn" <willemdebruijn.kernel@gmail.com>
>> > > > 发送时间:2026-04-23 22:59:45 (星期四)
>> > > > 收件人: "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, willemdebruijn.kernel@gmail.com, davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
>> > > > 抄送: sd@queasysnail.net, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
>> > > > 主题: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
>> > > >
>> > > > Mingyu Wang wrote:
>> > > > > During fuzzing with failslab enabled, a memory leak was observed in the
>> > > > > IPv6 UDP send path.
>> > > > >
>> > > > > The root cause resides in __ip6_make_skb(). In extremely rare cases
>> > > > > (such as fault injection or specific empty payload conditions),
>> > > >
>> > > > Can you elaborate on this? Which fault injection lets
>> > > > __ip6_append_data succeed without writing data?
>> > > >
>> > > > > __ip6_append_data() may succeed but leave the socket's write queue
>> > > > > empty.
>> > > > >
>> > > > > When __ip6_make_skb() is subsequently called, __skb_dequeue(queue)
>> > > > > returns NULL. The previous logic handled this by executing a 'goto out;',
>> > > > > which completely bypassed the call to ip6_cork_release(cork).
>> > > > >
>> > > > > Since the 'cork' structure actively holds a reference to the routing
>> > > > > entry (dst_entry) and potentially other allocated options, skipping
>> > > > > the release cleanly leaks these resources.
>> > > > >
>> > > > > Fix this by introducing an 'out_cork_release' label and jumping to it
>> > > > > when skb is NULL, ensuring the cork state is always properly cleaned up.
>> > > > > The now-unused 'out' label is also removed to prevent compiler warnings.
>> > > > >
>> > > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> > > >
>> > > > I think this is
>> > > >
>> > > > Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
>> > > >
>> > > > > Reported-by: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
>> > > > > Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
I see the command but can't find the corresponding bug.
The email is sent to syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.
^ permalink raw reply
* [bug report] Potential order bug in 'net/xfrm/xfrm_state.c', primarily in 'xfrm_state_walk_done()'
From: Ginger @ 2026-04-24 15:38 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev, linux-kernel
Dear Linux kernel maintainers,
My research-based static analyzer found a potential orderbug within
the 'net/xfrm' subsystem, more specifically, in
'net/xfrm/xfrm_state.c'.
Kernel version: long-term kernel v6.18.9
Potential concurrent triggering executions:
T0:
xfrm_state_walk_done
--> kfree(walk->filter); [t0]
--> list_del(&walk->all); [t3]
T1:
xfrm_state_walk
--> list_for_each_entry_from(x, &net->xfrm.state_all, all) [t1]
--> __xfrm_state_filter_match(state, walk->filter) [t2]
In T0, 'walk->filter' is free before the parent 'walk' gets removed
from the global list. Thus, it is possible for T1 to still get the
same 'walk' by iterating through the list linked via 'walk->all' and
access the 'filter' field, which has already been freed.
The concurrent buggy order is t0 -> t1 -> t2 -> t3.
Thank you for your time and consideration.
Sincerely,
Ginger
^ permalink raw reply
* [PATCH] netpoll: fix IPv6 local-address corruption
From: Breno Leitao @ 2026-04-24 15:31 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Cong Wang
Cc: netdev, linux-kernel, clm, gustavold, kernel-team, Breno Leitao
netpoll_setup() decides whether to auto-populate the local source
address by testing np->local_ip.ip, which only inspects the first 4
bytes of the union inet_addr storage.
For an IPv6 netpoll whose caller-supplied local address has a zero
high-32 bits (::1, ::<suffix>, IPv4-mapped ::ffff:a.b.c.d, etc.), this
misdetects the address as unset (which they are not, but the first
4 bytes are empty), calls netpoll_take_ipv6() and overwrites it with
whatever matching link-local/global address the device happens to expose
first.
Introduce a helper netpoll_local_ip_unset() that picks the correct
family-aware test (ipv6_addr_any() for IPv6, !.ip for IPv4) and use it
from netpoll_setup().
Reproducer is something like:
echo "::2" > local_ip
echo 1 > enabled
cat local_ip
# before this fix: 2001:db8::1 (caller-supplied ::2 was clobbered)
# after this fix: ::2
Fixes: b7394d2429c1 ("netpoll: prepare for ipv6")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
I've found this problem while using Chris' new AI toy (kres - Kernel
code RESearch agent), against netpoll code.
https://github.com/masoncl/kres
---
net/core/netpoll.c | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index cd74beffd209c..4381e0fc25bf4 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -704,6 +704,23 @@ static int netpoll_take_ipv4(struct netpoll *np, struct net_device *ndev)
return 0;
}
+/*
+ * Test whether the caller left np->local_ip unset, so that
+ * netpoll_setup() should auto-populate it from the egress device.
+ *
+ * np->local_ip is a union of __be32 (IPv4) and struct in6_addr (IPv6),
+ * so an IPv6 address whose first 4 bytes are zero (e.g. ::1, ::2,
+ * IPv4-mapped ::ffff:a.b.c.d) must not be tested via the IPv4 arm —
+ * doing so would misclassify a caller-supplied address as unset and
+ * silently overwrite it with whatever address the device exposes.
+ */
+static bool netpoll_local_ip_unset(const struct netpoll *np)
+{
+ if (np->ipv6)
+ return ipv6_addr_any(&np->local_ip.in6);
+ return !np->local_ip.ip;
+}
+
int netpoll_setup(struct netpoll *np)
{
struct net *net = current->nsproxy->net_ns;
@@ -747,7 +764,7 @@ int netpoll_setup(struct netpoll *np)
rtnl_lock();
}
- if (!np->local_ip.ip) {
+ if (netpoll_local_ip_unset(np)) {
if (!np->ipv6) {
err = netpoll_take_ipv4(np, ndev);
if (err)
---
base-commit: e728258debd553c95d2e70f9cd97c9fde27c7130
change-id: 20260424-netpoll_fix-88842a798663
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH v2] ice: wait for reset completion in ice_resume()
From: Loktionov, Aleksandr @ 2026-04-24 15:28 UTC (permalink / raw)
To: Aaron Ma, Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Akeem G Abodunrin, Jesse Brandeburg,
intel-wired-lan@lists.osuosl.org, Kohei Enju
In-Reply-To: <20260424030345.1140665-1-aaron.ma@canonical.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Aaron Ma via Intel-wired-lan
> Sent: Friday, April 24, 2026 5:04 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>; Jesse Brandeburg
> <jesse.brandeburg@intel.com>; intel-wired-lan@lists.osuosl.org; Kohei
> Enju <kohei@enjuk.jp>
> Subject: [Intel-wired-lan] [PATCH v2] ice: wait for reset completion
> in ice_resume()
>
> ice_resume() schedules an asynchronous PF reset and returns
> immediately. The reset runs later in ice_service_task(). If userspace
> tries to bring up the net device before the reset finishes, ice_open()
> fails with -EBUSY:
>
> ice_resume()
> ice_schedule_reset() # sets ICE_PFR_REQ, returns
> ...
> ice_open()
> ice_is_reset_in_progress() # ICE_PFR_REQ still set, -EBUSY
> ...
> ice_service_task()
> ice_do_reset()
> ice_rebuild() # clears ICE_PFR_REQ, too late
>
> Reproduced on E800 series NICs during suspend/resume with irdma
> enabled, where the aux device probe widens the race window.
>
> Wait for the reset to complete before returning from ice_resume().
>
> Fixes: 769c500dcc1e ("ice: Add advanced power mgmt for WoL")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> ---
> v2: reword comment to clarify best-effort semantics (Kohei Enju)
>
> drivers/net/ethernet/intel/ice/ice_main.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
> b/drivers/net/ethernet/intel/ice/ice_main.c
> index 5f92377d4dfc2..a81eb21ea87c1 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5635,6 +5635,15 @@ static int ice_resume(struct device *dev)
> /* Restart the service task */
> mod_timer(&pf->serv_tmr, round_jiffies(jiffies + pf-
> >serv_tmr_period));
>
> + /* Best-effort wait for the scheduled reset to finish so that
> the
> + * device is operational before returning. Without this,
> userspace
> + * (e.g. NetworkManager) may try to open the net device while
> the
> + * asynchronous reset is still in progress, hitting -EBUSY.
> + */
> + ret = ice_wait_for_reset(pf, 10 * HZ);
> + if (ret)
> + dev_err(dev, "Wait for reset failed during resume:
> %d\n", ret);
> +
> return 0;
> }
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 1/1] igc: skip RX timestamp header for frame preemption verification
From: Loktionov, Aleksandr @ 2026-04-24 15:27 UTC (permalink / raw)
To: KhaiWenTan, Nguyen, Anthony L, Kitszel, Przemyslaw,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, Choong, Chwee Lin,
vladimir.oltean@nxp.com, Gomes, Vinicius
Cc: faizal.abdul.rahim@linux.intel.com,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Tan, Khai Wen, Looi, Hong Aun,
Abdul Rahim, Faizal
In-Reply-To: <20260424075907.310456-1-khai.wen.tan@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of KhaiWenTan
> Sent: Friday, April 24, 2026 9:59 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; Choong, Chwee Lin <chwee.lin.choong@intel.com>;
> vladimir.oltean@nxp.com; Gomes, Vinicius <vinicius.gomes@intel.com>
> Cc: faizal.abdul.rahim@linux.intel.com; intel-wired-
> lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; Tan, Khai Wen <khai.wen.tan@intel.com>; Looi,
> Hong Aun <hong.aun.looi@intel.com>; Abdul Rahim, Faizal
> <faizal.abdul.rahim@intel.com>; KhaiWenTan
> <khai.wen.tan@linux.intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 1/1] igc: skip RX timestamp
> header for frame preemption verification
>
> When RX hardware timestamping is enabled, a 16-byte inline timestamp
> header is added to the start of the packet buffer, causing FPE
> handshake verification to fail.
>
> Because an incorrect packet buffer is passed to
> igc_fpe_handle_mpacket(), the mem_is_zero() check inspects the
> timestamp metadata instead of the actual mPacket payload. As a result,
> valid Verify/Response mPackets can be missed when inline RX timestamps
> are present.
>
> Pass pktbuf + pkt_offset to igc_fpe_handle_mpacket() so it inspects
> the actual mPacket payload instead of the timestamp header.
>
> Fixes: 5422570c0010 ("igc: add support for frame preemption
> verification")
> Co-developed-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
> Signed-off-by: KhaiWenTan <khai.wen.tan@linux.intel.com>
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
> b/drivers/net/ethernet/intel/igc/igc_main.c
> index 8ac16808023c..c470d2354ce8 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -2649,7 +2649,7 @@ static int igc_clean_rx_irq(struct igc_q_vector
> *q_vector, const int budget)
> }
>
> if (igc_fpe_is_pmac_enabled(adapter) &&
> - igc_fpe_handle_mpacket(adapter, rx_desc, size,
> pktbuf)) {
> + igc_fpe_handle_mpacket(adapter, rx_desc, size,
> pktbuf +
> +pkt_offset)) {
> /* Advance the ring next-to-clean */
> igc_is_non_eop(rx_ring, rx_desc);
> cleaned_count++;
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net v8 4/6] net/sched: netem: validate slot configuration
From: Stephen Hemminger @ 2026-04-24 15:07 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Paolo Abeni, netdev, jiri, David S. Miller, Eric Dumazet,
Jakub Kicinski, Dave Taht, open list, Simon Horman
In-Reply-To: <CAM0EoMmnHfUiKP1PO19sHJZpeGN5tdL7ds=_8Nma7Y-4XoSczg@mail.gmail.com>
On Thu, 23 Apr 2026 17:12:15 -0400
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> > > This is intended and explicitly explained in the cover letter.
> > Jamal, given the uAPI implication, could you please double check that
> > the change is fine?
> >
>
> It should be fine; at least iproute2 will never allow the kernel to
> receive a negative number.
> Stephen brought up the fact that strtod() could return a -ve number
> (but at least iproute2 makes sure negative numbers are not carried
> forward to the kernel).
>
> cheers,
> jamal
Iproute2 blocks negative values kind of by accident.
The NEXT_IS_NUMBER() macro looks for digit at start of arg.
To hit this you need to either use raw netlink or change NEXT_IS_NUMBER()
to NEXT_IS_SIGNED_NUMBER() where slot values are parsed.
^ permalink raw reply
* [PATCH] vsock/virtio: fix memory leak in virtio_transport_recv_listen()
From: Deepanshu Kartikey @ 2026-04-24 15:03 UTC (permalink / raw)
To: mst, jasowang, xuanzhuo, eperezma, stefanha, sgarzare, davem,
edumazet, kuba, pabeni, horms
Cc: virtualization, kvm, netdev, linux-kernel, Deepanshu Kartikey,
syzbot+1b2c9c4a0f8708082678
Two bugs exist in virtio_transport_recv_listen():
1. On the transport assignment error path, sk_acceptq_added() is called
but sk_acceptq_removed() is never called when vsock_assign_transport()
fails or assigns a different transport than expected. This causes the
parent listener's accept backlog counter to be permanently inflated,
eventually causing sk_acceptq_is_full() to reject legitimate incoming
connections.
2. There is a race between __vsock_release() and vsock_enqueue_accept().
__vsock_release() sets sk->sk_shutdown to SHUTDOWN_MASK and flushes
the accept queue under the parent socket lock. However,
virtio_transport_recv_listen() checks sk_shutdown and subsequently
calls vsock_enqueue_accept() without holding the parent socket lock.
This means a child socket can be enqueued after __vsock_release() has
already flushed the queue, causing the child socket and its associated
resources to leak
permanently. The existing comment in the code hints at this race but
the fix was never implemented.
Fix both issues: add sk_acceptq_removed() on the transport error path,
and re-check sk->sk_shutdown under the parent socket lock before calling
vsock_enqueue_accept() to close the race window. The child socket lock
is released before acquiring the parent socket lock to maintain correct
lock ordering (parent before child).
Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
Tested-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
net/vmw_vsock/virtio_transport_common.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 416d533f493d..fad5fa4a4296 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -1578,6 +1578,7 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
*/
if (ret || vchild->transport != &t->transport) {
release_sock(child);
+ sk_acceptq_removed(sk);
virtio_transport_reset_no_sock(t, skb, sock_net(sk));
sock_put(child);
return ret;
@@ -1588,11 +1589,19 @@ virtio_transport_recv_listen(struct sock *sk, struct sk_buff *skb,
child->sk_write_space(child);
vsock_insert_connected(vchild);
+ release_sock(child);
+ lock_sock(sk);
+ if (sk->sk_shutdown == SHUTDOWN_MASK) {
+ release_sock(sk);
+ sk_acceptq_removed(sk);
+ virtio_transport_reset_no_sock(t, skb, sock_net(sk));
+ sock_put(child);
+ return -ESHUTDOWN;
+ }
vsock_enqueue_accept(sk, child);
+ release_sock(sk);
virtio_transport_send_response(vchild, skb);
- release_sock(child);
-
sk->sk_data_ready(sk);
return 0;
}
--
2.43.0
^ permalink raw reply related
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