* Re: [PATCH net-next v19 00/15] Begin upstreaming Homa transport protocol
From: John Ousterhout @ 2026-04-30 16:24 UTC (permalink / raw)
To: netdev; +Cc: pabeni, edumazet, horms, kuba
In-Reply-To: <20260428231520.1857-1-ouster@cs.stanford.edu>
The sashiki-gemini review has found a bunch of issues, which look
super-helpful (and a little sobering at how many there are :-(). I
will of course address all of these, but I'm wondering if there is a
recommended way for me to respond to these "on the record" (analogous
to responding to emails sent by humans)? In particular, there are a
couple that are false alarms, so I'd like to do something to keep
these from reappearing in future AI reviews. Any suggestions?
-John-
^ permalink raw reply
* [PATCH net v2] bridge: mcast: Fix a false positive lockdep splat
From: Ido Schimmel @ 2026-04-30 16:26 UTC (permalink / raw)
To: netdev, bridge
Cc: davem, kuba, pabeni, edumazet, razor, horms, herbert,
linus.luessing, petrm, Ido Schimmel
Connecting two bridges on the same system [1] can result in a lockdep
splat [2].
The report is a false positive. Multicast queries are built and
transmitted under the bridge multicast lock. When the outgoing port of
one bridge is configured on top of another bridge, the transmit path
re-enters bridge code and acquires the other bridge's multicast lock in
order to snoop the query. Both lock instances share a single lockdep
class, so lockdep flags the nested acquisition as an AA deadlock.
Giving each bridge its own lock class will not solve the problem: the
reverse topology would produce an ABBA splat with the same pair of
classes. It also consumes a lockdep key per bridge.
Instead, fix the problem by deferring the transmission of the queries to
a workqueue. Build the skb and update querier state under the lock as
before, then enqueue the skb on a per multicast context queue and
schedule the work.
Flush the work when the multicast context is de-initialized. At this
stage the work cannot be requeued. There is no need to take a reference
on skb->dev since the work cannot outlive the bridge or the bridge port.
Use the high priority workqueue to reduce the delay between the enqueue
time and the transmission time. With default settings (i.e., querier
interval - 255 seconds, query interval - 125 seconds) the extra delay
should not be a problem.
Avoid the unlikely case of the queue growing endlessly by limiting it to
1,000 skbs. Use this number for the simple reason that this is the
default Tx queue length.
[1]
ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1
ip link add name br0 up type bridge mcast_snooping 1 mcast_querier 1
ip link add link br0 name br0.10 up master br1 type vlan id 10
[2]
WARNING: possible recursive locking detected
7.0.0-virtme-gb50c64a58a90 #1 Not tainted
[...]
ip/339 is trying to acquire lock:
ffff888104f0b480 (&br->multicast_lock){+.-.}-{3:3}, at: br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
but task is already holding lock:
ffff888104f03480 (&br->multicast_lock){+.-.}-{3:3}, at: br_multicast_port_query_expired (net/bridge/br_multicast.c:1904)
[...]
Call Trace:
[...]
br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
br_multicast_ipv6_rcv (net/bridge/br_multicast.c:3988)
br_dev_xmit (net/bridge/br_device.c:98 (discriminator 1))
dev_hard_start_xmit (./include/linux/netdevice.h:5343 ./include/linux/netdevice.h:5352 net/core/dev.c:3888 net/core/dev.c:3904)
__dev_queue_xmit (./include/linux/netdevice.h:3619 net/core/dev.c:4871)
vlan_dev_hard_start_xmit (net/8021q/vlan_dev.c:131 (discriminator 1))
dev_hard_start_xmit (./include/linux/netdevice.h:5343 ./include/linux/netdevice.h:5352 net/core/dev.c:3888 net/core/dev.c:3904)
__dev_queue_xmit (./include/linux/netdevice.h:3619 net/core/dev.c:4871)
br_dev_queue_push_xmit (net/bridge/br_forward.c:60)
__br_multicast_send_query (net/bridge/br_multicast.c:1811 (discriminator 1))
br_multicast_send_query (net/bridge/br_multicast.c:1889)
br_multicast_port_query_expired (./include/linux/spinlock.h:390 net/bridge/br_multicast.c:1914)
call_timer_fn (./arch/x86/include/asm/jump_label.h:37 ./include/trace/events/timer.h:127 kernel/time/timer.c:1749)
[...]
Fixes: eb1d16414339 ("bridge: Add core IGMP snooping support")
Reported-by: syzbot+d7b7f1412c02134efa6d@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/000000000000c4c9d405f2643e01@google.com/
Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
v2:
- Limit the queue to 1,000 skbs.
- Edit the trace to avoid checkpatch errors.
v1: https://lore.kernel.org/netdev/20260426133435.207006-1-idosch@nvidia.com/
---
net/bridge/br_multicast.c | 47 +++++++++++++++++++++++++++++++++++----
net/bridge/br_private.h | 4 ++++
2 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 881d866d687a..e9f5fe01ff95 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1776,6 +1776,30 @@ static void br_multicast_select_own_querier(struct net_bridge_mcast *brmctx,
#endif
}
+static void br_multicast_port_query_queue_work(struct work_struct *work)
+{
+ struct net_bridge_mcast_port *pmctx;
+ struct sk_buff *skb;
+
+ pmctx = container_of(work, struct net_bridge_mcast_port,
+ query_queue_work);
+ while ((skb = skb_dequeue(&pmctx->query_queue)))
+ NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT, dev_net(skb->dev),
+ NULL, skb, NULL, skb->dev, br_dev_queue_push_xmit);
+}
+
+static void br_multicast_query_queue_work(struct work_struct *work)
+{
+ struct net_bridge_mcast *brmctx;
+ struct sk_buff *skb;
+
+ brmctx = container_of(work, struct net_bridge_mcast, query_queue_work);
+ while ((skb = skb_dequeue(&brmctx->query_queue)))
+ netif_rx(skb);
+}
+
+#define BR_MULTICAST_QUERY_QUEUE_LEN_MAX 1000
+
static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
struct net_bridge_mcast_port *pmctx,
struct net_bridge_port_group *pg,
@@ -1785,6 +1809,7 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
u8 sflag,
bool *need_rexmit)
{
+ struct sk_buff_head *queue;
bool over_lmqt = !!sflag;
struct sk_buff *skb;
u8 igmp_type;
@@ -1793,7 +1818,12 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
!br_multicast_ctx_matches_vlan_snooping(brmctx))
return;
+ queue = pmctx ? &pmctx->query_queue : &brmctx->query_queue;
+
again_under_lmqt:
+ if (skb_queue_len_lockless(queue) >= BR_MULTICAST_QUERY_QUEUE_LEN_MAX)
+ return;
+
skb = br_multicast_alloc_query(brmctx, pmctx, pg, ip_dst, group,
with_srcs, over_lmqt, sflag, &igmp_type,
need_rexmit);
@@ -1804,9 +1834,8 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
skb->dev = pmctx->port->dev;
br_multicast_count(brmctx->br, pmctx->port, skb, igmp_type,
BR_MCAST_DIR_TX);
- NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT,
- dev_net(pmctx->port->dev), NULL, skb, NULL, skb->dev,
- br_dev_queue_push_xmit);
+ skb_queue_tail(queue, skb);
+ queue_work(system_highpri_wq, &pmctx->query_queue_work);
if (over_lmqt && with_srcs && sflag) {
over_lmqt = false;
@@ -1816,7 +1845,8 @@ static void __br_multicast_send_query(struct net_bridge_mcast *brmctx,
br_multicast_select_own_querier(brmctx, group, skb);
br_multicast_count(brmctx->br, NULL, skb, igmp_type,
BR_MCAST_DIR_RX);
- netif_rx(skb);
+ skb_queue_tail(queue, skb);
+ queue_work(system_highpri_wq, &brmctx->query_queue_work);
}
}
@@ -1999,6 +2029,10 @@ void br_multicast_port_ctx_init(struct net_bridge_port *port,
pmctx->port = port;
pmctx->vlan = vlan;
pmctx->multicast_router = MDB_RTR_TYPE_TEMP_QUERY;
+
+ skb_queue_head_init(&pmctx->query_queue);
+ INIT_WORK(&pmctx->query_queue_work, br_multicast_port_query_queue_work);
+
timer_setup(&pmctx->ip4_mc_router_timer,
br_ip4_multicast_router_expired, 0);
timer_setup(&pmctx->ip4_own_query.timer,
@@ -2038,6 +2072,7 @@ void br_multicast_port_ctx_deinit(struct net_bridge_mcast_port *pmctx)
del |= br_ip4_multicast_rport_del(pmctx);
br_multicast_rport_del_notify(pmctx, del);
spin_unlock_bh(&br->multicast_lock);
+ flush_work(&pmctx->query_queue_work);
}
int br_multicast_add_port(struct net_bridge_port *port)
@@ -4111,6 +4146,9 @@ void br_multicast_ctx_init(struct net_bridge *br,
seqcount_spinlock_init(&brmctx->ip6_querier.seq, &br->multicast_lock);
#endif
+ skb_queue_head_init(&brmctx->query_queue);
+ INIT_WORK(&brmctx->query_queue_work, br_multicast_query_queue_work);
+
timer_setup(&brmctx->ip4_mc_router_timer,
br_ip4_multicast_local_router_expired, 0);
timer_setup(&brmctx->ip4_other_query.timer,
@@ -4134,6 +4172,7 @@ void br_multicast_ctx_init(struct net_bridge *br,
void br_multicast_ctx_deinit(struct net_bridge_mcast *brmctx)
{
__br_multicast_stop(brmctx);
+ flush_work(&brmctx->query_queue_work);
}
void br_multicast_init(struct net_bridge *br)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index bed1b1d9b282..31e317a3529c 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -131,6 +131,8 @@ struct net_bridge_mcast_port {
unsigned char multicast_router;
u32 mdb_n_entries;
u32 mdb_max_entries;
+ struct sk_buff_head query_queue;
+ struct work_struct query_queue_work;
#endif /* CONFIG_BRIDGE_IGMP_SNOOPING */
};
@@ -167,6 +169,8 @@ struct net_bridge_mcast {
struct bridge_mcast_own_query ip6_own_query;
struct bridge_mcast_querier ip6_querier;
#endif /* IS_ENABLED(CONFIG_IPV6) */
+ struct sk_buff_head query_queue;
+ struct work_struct query_queue_work;
#endif /* CONFIG_BRIDGE_IGMP_SNOOPING */
};
--
2.53.0
^ permalink raw reply related
* Re: [GIT PULL] wireless-2026-04-30
From: Jakub Kicinski @ 2026-04-30 16:27 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <027691e6472079e06f816462a8049308a1bea908.camel@sipsolutions.net>
On Thu, 30 Apr 2026 17:51:15 +0200 Johannes Berg wrote:
> On Thu, 2026-04-30 at 07:12 -0700, Jakub Kicinski wrote:
> > On Thu, 30 Apr 2026 13:17:52 +0200 Johannes Berg wrote:
> > > So the LLM floodgates are starting to open ;-) But I'm somewhat
> > > happy that so far we haven't gotten any really critical reports.
> > > Here's a couple of first fixes though.
> > >
> > > Please pull and let us know if there's any problem.
> >
> > Looks like this breaks kunit:
> >
> > ok 70 mac80211-tpe
> > KTAP version 1
> > # Subtest: mac80211-mlme-chan-mode
> > # module: mac80211_tests
> > 1..1
> > KTAP version 1
> > # Subtest: test_determine_chan_mode
> > ok 1 Normal case, EHT is working
> > ok 2 Requiring EHT support is fine
> > ok 3 Lowering the mode limits us
> > kunit: required basic rate or BSS membership selectors not supported or disabled, rejecting connection
> > ok 4 Requesting a basic rate/selector that we do not support
> > ok 5 As before, but userspace says it is taking care of it
> > # test_determine_chan_mode: ASSERTION FAILED at net/mac80211/tests/chan-mode.c:258
> > Expected conn.mode == params->expected_mode, but
> > conn.mode == 5 (0x5)
> > params->expected_mode == 1 (0x1)
> > not ok 6 Masking out a supported rate in HT capabilities
> >
>
> D'oh. Yeah, that's the AP workaround, we'll need to adjust the test. I'm
> on my way out right now, so I guess that'll have to wait for next week.
SG, Paolo already submitted our PR so from Linus tree's perspective
later today or early next week doesn't matter..
^ permalink raw reply
* Re: [GIT PULL] Networking for v7.1-rc2
From: pr-tracker-bot @ 2026-04-30 16:33 UTC (permalink / raw)
To: Paolo Abeni; +Cc: torvalds, kuba, davem, netdev, linux-kernel
In-Reply-To: <20260430135922.238723-1-pabeni@redhat.com>
The pull request you sent on Thu, 30 Apr 2026 15:59:22 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git net-7.1-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/08d0d3466664000ba0670e0ef0d447f23459e0d4
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH iwl-net] idpf: fix RSS LUT memcpy size
From: Jacob Keller @ 2026-04-30 16:38 UTC (permalink / raw)
To: Larysa Zaremba, intel-wired-lan
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Joshua Hay, Willem de Bruijn,
Alice Michael, netdev, linux-kernel, Aleksandr Loktionov,
Tony Nguyen
In-Reply-To: <20260429074232.180528-1-larysa.zaremba@intel.com>
On 4/29/2026 12:42 AM, Larysa Zaremba wrote:
> Based on the following feedback from Sashiko (received for iXD phase 1
> patchset, but valid for the net tree):
>
> "Is the bounds check xn_params.recv_mem.iov_len < lut_buf_size sufficient?
> Since lut_buf_size only represents the size of the array elements, should
> this check instead verify that the payload is at least
> sizeof(struct virtchnl2_rss_lut) + lut_buf_size?
>
> [...]
>
> Does memcpy copy the correct amount of data here? rss_lut_size stores the
> number of 32-bit entries, not the size in bytes. Should it use
> lut_buf_size or rss_data->rss_lut_size * sizeof(u32) instead?"
>
> After inspecting the code, it was concluded that RSS memcpy size is in fact
> 4 times smaller than it has to be, since a single array entry in a u32, and
> rss_data->rss_lut_size is clearly used as an array size. Required Rx buffer
> size is also too small, but this is a common issue in the idpf code.
>
> Use a full buffer size (lut_buf_size) instead of the array length
> (rss_data->rss_lut_size) when doing memcpy of RSS lookup table.
> While at it, increase required Rx buffer size to a whole flex-array
> containing structure instead of just the array.
>
> Link: https://sashiko.dev/#/patchset/20260323174052.5355-1-larysa.zaremba%40intel.com?part=8
> Fixes: 95af467d9a4e ("idpf: configure resources for RX queues")
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> index be66f9b2e101..a97d2e9b54d4 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> @@ -2916,7 +2916,7 @@ int idpf_send_get_set_rss_lut_msg(struct idpf_adapter *adapter,
> return -EIO;
>
> lut_buf_size = le16_to_cpu(recv_rl->lut_entries) * sizeof(u32);
> - if (reply_sz < lut_buf_size)
> + if (reply_sz < lut_buf_size + sizeof(struct virtchnl2_rss_lut))
This feels like it should be using struct_size or flex_array_size...
> return -EIO;
>
> /* size didn't change, we can reuse existing lut buf */
> @@ -2933,7 +2933,7 @@ int idpf_send_get_set_rss_lut_msg(struct idpf_adapter *adapter,
> }
>
> do_memcpy:
> - memcpy(rss_data->rss_lut, recv_rl->lut, rss_data->rss_lut_size);
> + memcpy(rss_data->rss_lut, recv_rl->lut, lut_buf_size);
>
> return 0;
> }
^ permalink raw reply
* [syzbot] [net?] KCSAN: data-race in igmp_rcv / igmp_rcv (2)
From: syzbot @ 2026-04-30 16:42 UTC (permalink / raw)
To: davem, dsahern, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 2d1373e4246d Merge tag 'for-7.0-rc4-tag' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1184a8da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3a78dd265deac3a9
dashboard link: https://syzkaller.appspot.com/bug?extid=ae9a171f239b14485310
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b2aee7aa6da1/disk-2d1373e4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/6cbfa1602880/vmlinux-2d1373e4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/52fe8db03e03/bzImage-2d1373e4.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ae9a171f239b14485310@syzkaller.appspotmail.com
==================================================================
BUG: KCSAN: data-race in igmp_rcv / igmp_rcv
read to 0xffff88810a66f058 of 8 bytes by task 5213 on cpu 1:
igmp_heard_query net/ipv4/igmp.c:1025 [inline]
igmp_rcv+0x10af/0x1200 net/ipv4/igmp.c:1103
ip_protocol_deliver_rcu+0x421/0x790 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x1fc/0x2f0 net/ipv4/ip_input.c:241
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_local_deliver+0xe8/0x1e0 net/ipv4/ip_input.c:262
dst_input include/net/dst.h:480 [inline]
ip_rcv_finish+0x188/0x1a0 net/ipv4/ip_input.c:453
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_rcv+0x62/0x160 net/ipv4/ip_input.c:573
__netif_receive_skb_one_core net/core/dev.c:6164 [inline]
__netif_receive_skb net/core/dev.c:6277 [inline]
netif_receive_skb_internal net/core/dev.c:6363 [inline]
netif_receive_skb+0x137/0x530 net/core/dev.c:6422
tun_rx_batched+0x106/0x440 drivers/net/tun.c:1485
tun_get_user+0x2011/0x27c0 drivers/net/tun.c:1953
tun_chr_write_iter+0x15e/0x210 drivers/net/tun.c:1999
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x5a6/0x9f0 fs/read_write.c:688
ksys_write+0xdc/0x1a0 fs/read_write.c:740
__do_sys_write fs/read_write.c:751 [inline]
__se_sys_write fs/read_write.c:748 [inline]
__x64_sys_write+0x40/0x50 fs/read_write.c:748
x64_sys_call+0x27e1/0x3020 arch/x86/include/generated/asm/syscalls_64.h:2
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
write to 0xffff88810a66f058 of 8 bytes by task 5212 on cpu 0:
igmp_heard_query net/ipv4/igmp.c:1026 [inline]
igmp_rcv+0x10eb/0x1200 net/ipv4/igmp.c:1103
ip_protocol_deliver_rcu+0x421/0x790 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x1fc/0x2f0 net/ipv4/ip_input.c:241
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_local_deliver+0xe8/0x1e0 net/ipv4/ip_input.c:262
dst_input include/net/dst.h:480 [inline]
ip_rcv_finish+0x188/0x1a0 net/ipv4/ip_input.c:453
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_rcv+0x62/0x160 net/ipv4/ip_input.c:573
__netif_receive_skb_one_core net/core/dev.c:6164 [inline]
__netif_receive_skb net/core/dev.c:6277 [inline]
netif_receive_skb_internal net/core/dev.c:6363 [inline]
netif_receive_skb+0x137/0x530 net/core/dev.c:6422
tun_rx_batched+0x106/0x440 drivers/net/tun.c:1485
tun_get_user+0x2011/0x27c0 drivers/net/tun.c:1953
tun_chr_write_iter+0x15e/0x210 drivers/net/tun.c:1999
new_sync_write fs/read_write.c:595 [inline]
vfs_write+0x5a6/0x9f0 fs/read_write.c:688
ksys_write+0xdc/0x1a0 fs/read_write.c:740
__do_sys_write fs/read_write.c:751 [inline]
__se_sys_write fs/read_write.c:748 [inline]
__x64_sys_write+0x40/0x50 fs/read_write.c:748
x64_sys_call+0x27e1/0x3020 arch/x86/include/generated/asm/syscalls_64.h:2
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000000000003e8 -> 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 5212 Comm: syz.1.463 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [BUG?] bluetooth LE ISO sockets never get freed because of SOCK_DEAD confusion?
From: Jann Horn @ 2026-04-30 16:47 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
Cc: kernel list, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Network Development
I can't figure out how to release a bluetooth LE ISO socket such that
it gets freed.
ISO sockets are placed on the iso_sk_list, which holds references to
its entries. The only place in which an ISO socket can be removed from
this list is iso_sock_kill(), which calls bt_sock_unlink(&iso_sk_list,
sk).
But iso_sock_kill() bails out immediately if either sk->sk_socket is
still set, or SOCK_DEAD is set. This means that if anything other than
iso_sock_kill() sets SOCK_DEAD, the socket can never be freed.
When I call close() on an ISO socket returned by accept(), the
behavior I observe is:
sock_close
__sock_release
iso_sock_release
iso_sock_close
iso_sock_kill
[bails out because sk->sk_socket is still non-NULL]
sock_orphan
sk_set_flag(sk, SOCK_DEAD)
sk_set_socket(sk, NULL)
iso_sock_kill
[bails out because SOCK_DEAD is now set]
Am I missing something, or can ISO sockets (once they have been
accepted) never be freed?
^ permalink raw reply
* [PATCH net] ipv4: igmp: annotate data-races in igmp_heard_query()
From: Eric Dumazet @ 2026-04-30 16:48 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Ido Schimmel, David Ahern, netdev, eric.dumazet,
Eric Dumazet, syzbot+ae9a171f239b14485310
Multiple cpus can run igmp_heard_query() concurrently.
Add missing READ_ONCE()/WRITE_ONCE() over following in_dev fields.
- mr_qrv
- mr_qi
- mr_qri
- mr_v1_seen
- mr_v2_seen
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+ae9a171f239b14485310@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/69f38675.050a0220.3cbe47.0002.GAE@google.com
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/igmp.c | 58 ++++++++++++++++++++++++++++++-------------------
1 file changed, 36 insertions(+), 22 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index a674fb44ec25baf963dbaf9e72ccc45980b858b6..a9ad39064f3bb7fcfaace52448473f0425b2fa07 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -122,16 +122,29 @@
* contradict to specs provided this delay is small enough.
*/
-#define IGMP_V1_SEEN(in_dev) \
- (IPV4_DEVCONF_ALL_RO(dev_net(in_dev->dev), FORCE_IGMP_VERSION) == 1 || \
- IN_DEV_CONF_GET((in_dev), FORCE_IGMP_VERSION) == 1 || \
- ((in_dev)->mr_v1_seen && \
- time_before(jiffies, (in_dev)->mr_v1_seen)))
-#define IGMP_V2_SEEN(in_dev) \
- (IPV4_DEVCONF_ALL_RO(dev_net(in_dev->dev), FORCE_IGMP_VERSION) == 2 || \
- IN_DEV_CONF_GET((in_dev), FORCE_IGMP_VERSION) == 2 || \
- ((in_dev)->mr_v2_seen && \
- time_before(jiffies, (in_dev)->mr_v2_seen)))
+static bool IGMP_V1_SEEN(const struct in_device *in_dev)
+{
+ unsigned long seen;
+
+ if (IPV4_DEVCONF_ALL_RO(dev_net(in_dev->dev), FORCE_IGMP_VERSION) == 1)
+ return true;
+ if (IN_DEV_CONF_GET((in_dev), FORCE_IGMP_VERSION) == 1)
+ return true;
+ seen = READ_ONCE(in_dev->mr_v1_seen);
+ return seen && time_before(jiffies, seen);
+}
+
+static bool IGMP_V2_SEEN(const struct in_device *in_dev)
+{
+ unsigned long seen;
+
+ if (IPV4_DEVCONF_ALL_RO(dev_net(in_dev->dev), FORCE_IGMP_VERSION) == 2)
+ return true;
+ if (IN_DEV_CONF_GET((in_dev), FORCE_IGMP_VERSION) == 2)
+ return true;
+ seen = READ_ONCE(in_dev->mr_v2_seen);
+ return seen && time_before(jiffies, seen);
+}
static int unsolicited_report_interval(struct in_device *in_dev)
{
@@ -954,23 +967,21 @@ static bool igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
int max_delay;
int mark = 0;
struct net *net = dev_net(in_dev->dev);
-
+ unsigned long seen;
if (len == 8) {
+ seen = jiffies + READ_ONCE(in_dev->mr_qrv) * READ_ONCE(in_dev->mr_qi) +
+ READ_ONCE(in_dev->mr_qri);
if (ih->code == 0) {
/* Alas, old v1 router presents here. */
max_delay = IGMP_QUERY_RESPONSE_INTERVAL;
- in_dev->mr_v1_seen = jiffies +
- (in_dev->mr_qrv * in_dev->mr_qi) +
- in_dev->mr_qri;
+ WRITE_ONCE(in_dev->mr_v1_seen, seen);
group = 0;
} else {
/* v2 router present */
max_delay = ih->code*(HZ/IGMP_TIMER_SCALE);
- in_dev->mr_v2_seen = jiffies +
- (in_dev->mr_qrv * in_dev->mr_qi) +
- in_dev->mr_qri;
+ WRITE_ONCE(in_dev->mr_v2_seen, seen);
}
/* cancel the interface change timer */
WRITE_ONCE(in_dev->mr_ifc_count, 0);
@@ -995,6 +1006,8 @@ static bool igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
if (!max_delay)
max_delay = 1; /* can't mod w/ 0 */
} else { /* v3 */
+ unsigned long mr_qi;
+
if (!pskb_may_pull(skb, sizeof(struct igmpv3_query)))
return true;
@@ -1015,15 +1028,16 @@ static bool igmp_heard_query(struct in_device *in_dev, struct sk_buff *skb,
* received value was zero, use the default or statically
* configured value.
*/
- in_dev->mr_qrv = ih3->qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);
- in_dev->mr_qi = IGMPV3_QQIC(ih3->qqic)*HZ ?: IGMP_QUERY_INTERVAL;
-
+ WRITE_ONCE(in_dev->mr_qrv,
+ ih3->qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv));
+ mr_qi = IGMPV3_QQIC(ih3->qqic)*HZ ?: IGMP_QUERY_INTERVAL;
+ WRITE_ONCE(in_dev->mr_qi, mr_qi);
/* RFC3376, 8.3. Query Response Interval:
* The number of seconds represented by the [Query Response
* Interval] must be less than the [Query Interval].
*/
- if (in_dev->mr_qri >= in_dev->mr_qi)
- in_dev->mr_qri = (in_dev->mr_qi/HZ - 1)*HZ;
+ if (READ_ONCE(in_dev->mr_qri) >= mr_qi)
+ WRITE_ONCE(in_dev->mr_qri, (mr_qi/HZ - 1) * HZ);
if (!group) { /* general query */
if (ih3->nsrcs)
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [RFC Patch net-next] r8169: add phylink support
From: Andrew Lunn @ 2026-04-30 16:49 UTC (permalink / raw)
To: javen
Cc: hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel
In-Reply-To: <20260430083244.703-1-javen_xu@realsil.com.cn>
> And one more question, when the driver initializes RTL8116af,
> r8169_mdio_register() will still be called. So tp->phydev =
> mdiobus_get_phy(new_bus, 0) will still be executed. This feels redundant
> since we are now using phylink. However, if I bypass this assignment,
> it breaks several existing functions which are strongly rely on
> tp->phydev. Is it acceptable to keep this tp->phydev for now, or is
> there a preferred way to handle this problem?
You probably want to do some refactoring, before swapping to phylink.
rtl_link_chg_patch() needs to know the link speed, so looks at
phydev->speed. The rtl_mac_link_up() call gets passed the speed. So i
would refactor rtl_link_chg_patch() to be passed the speed. And then
when you swap to phylink, and r8169_phylink_handler() disappears you
can call rtl_link_chg_patch() from mac_link_up.
rtl_coalesce_info() i would refactor to put the current speed in tp,
set is when rtl_mac_link_up() is called, and back to -1 when
rtl_mac_link_down is called. This can be another refactor patch, have
r8169_phylink_handler() set the speed.
Same change for r8169_get_tx_lpi_timer_us().
EEE is quite different for phylink, so rtl8169_get_eee() and
rtl8169_set_eee() will change and should not need to reference phydev.
The same is true for rtl8169_get_pauseparam() and
rtl8169_set_pauseparam().
rtl8169_set_link_ksettings() is broken! It should not be touching
phydev members like this. That also mostly disappears with the swap to
phylink.
r8169_apply_firmware() is interesting. Is this putting firmware in the
MAC or the PHY? Or both? If it was only PHY, i would move this into
the PHY driver.
I would try to move the code in r8169_phy_config.c into the PHY
driver. The tricky part is knowing what MAC version is being used.
/* Chip doesn't support pause in jumbo mode */ should be done
differently. We have helpers phy_support_sym_pause() and
phy_support_asym_pause(). A new helper should be added
phy_support_no_pause(). Both advertising and supported should be
cleared. And these should be an else clause for when jumbo is
disabled, and pause can be used again. phylink however does this in a
different way. It might be you need to call phylink_stop() &
phylink_start() and ensure the mac_get_caps() returns the correct
capabilities.
Try to remove as many references to phydev as you can.
I would also suggest lots of small patches when doing this
refactoring. When you break something, it will make it easier to
figure out what broke it.
Andrew
^ permalink raw reply
* Re: [PATCH] kcov: refactor common handle ID into kcov_common_handle_id
From: Greg KH @ 2026-04-30 16:49 UTC (permalink / raw)
To: Jann Horn
Cc: Dmitry Vyukov, Andrey Konovalov, kasan-dev, Andrew Morton,
Alexander Potapenko, Valentina Manea, Shuah Khan, Shuah Khan,
Hongren Zheng, linux-usb, Michael S. Tsirkin, Jason Wang,
Eugenio Pérez, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20260430-kcov-refactor-common-handle-v1-1-23a0c7a0ba38@google.com>
On Thu, Apr 30, 2026 at 04:15:33PM +0200, Jann Horn wrote:
> Store common handle IDs in "struct kcov_common_handle_id", which consumes
> no space in non-KCOV builds.
> This cleanup removes #ifdef boilerplate code from subsystems that
> integrate with KCOV (in particular in usbip_common.h and skbuff.h, see the
> diffstat).
> This should also make it easier to add KCOV remote coverage to more
> subsystems in the future.
>
> Signed-off-by: Jann Horn <jannh@google.com>
> ---
> drivers/usb/usbip/usbip_common.h | 29 +----------------------------
> drivers/usb/usbip/vhci_rx.c | 4 ++--
> drivers/usb/usbip/vhci_sysfs.c | 2 +-
> drivers/vhost/vhost.h | 2 +-
> include/linux/kcov.h | 12 ++++++------
> include/linux/skbuff.h | 14 +++-----------
> include/linux/types.h | 6 ++++++
> kernel/kcov.c | 6 +++---
> 8 files changed, 23 insertions(+), 52 deletions(-)
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH net-next] selftests: drv-net: Enable ntuple-filters if supported
From: Dimitri Daskalakis @ 2026-04-30 16:52 UTC (permalink / raw)
To: David S . Miller
Cc: Andrew Lunn, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Shuah Khan, Dimitri Daskalakis, David Wei, Joe Damato,
Dragos Tatulea, Vishwanath Seshagiri, Pavel Begunkov,
Simon Horman, Pavan Chebbi, Michael Chan, Gal Pressman,
linux-kselftest, netdev
From: Dimitri Daskalakis <daskald@meta.com>
Certain devices which support ntuple-filters do not enable the feature
by default. The existing tests will skip (if they check for the feature),
or fail if they blindly attempt to install rules. Therefore, attempt to turn
on ntuple-filters if the device supports them.
Signed-off-by: Dimitri Daskalakis <daskald@meta.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
tools/testing/selftests/drivers/net/gro.py | 10 ++++++++++
tools/testing/selftests/drivers/net/hw/gro_hw.py | 10 ++++++++++
tools/testing/selftests/drivers/net/hw/iou-zcrx.py | 12 ++++++++++++
tools/testing/selftests/drivers/net/hw/ntuple.py | 5 ++++-
| 7 ++++---
5 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/gro.py b/tools/testing/selftests/drivers/net/gro.py
index 221f27e57147..5ffaa7bdbff4 100755
--- a/tools/testing/selftests/drivers/net/gro.py
+++ b/tools/testing/selftests/drivers/net/gro.py
@@ -132,11 +132,21 @@ def _get_queue_stats(cfg, queue_id):
return {}
+def _require_ntuple(cfg):
+ features = ethtool(f"-k {cfg.ifname}", json=True)[0]
+ if not features["ntuple-filters"]["active"]:
+ if features["ntuple-filters"]["fixed"]:
+ raise KsftXfailEx("Device does not support ntuple-filters")
+ ethtool(f"-K {cfg.ifname} ntuple-filters on")
+ defer(ethtool, f"-K {cfg.ifname} ntuple-filters off")
+
+
def _setup_isolated_queue(cfg):
"""Set up an isolated queue for testing using ntuple filter.
Remove queue 1 from the default RSS context and steer test traffic to it.
"""
+ _require_ntuple(cfg)
test_queue = 1
qcnt = len(glob.glob(f"/sys/class/net/{cfg.ifname}/queues/rx-*"))
diff --git a/tools/testing/selftests/drivers/net/hw/gro_hw.py b/tools/testing/selftests/drivers/net/hw/gro_hw.py
index 10e08b22ee0e..70e76e3888bd 100755
--- a/tools/testing/selftests/drivers/net/hw/gro_hw.py
+++ b/tools/testing/selftests/drivers/net/hw/gro_hw.py
@@ -51,11 +51,21 @@ def _resolve_dmac(cfg, ipver):
return getattr(cfg, attr)
+def _require_ntuple(cfg):
+ features = ethtool(f"-k {cfg.ifname}", json=True)[0]
+ if not features["ntuple-filters"]["active"]:
+ if features["ntuple-filters"]["fixed"]:
+ raise KsftSkipEx("Device does not support ntuple-filters")
+ ethtool(f"-K {cfg.ifname} ntuple-filters on")
+ defer(ethtool, f"-K {cfg.ifname} ntuple-filters off")
+
+
def _setup_isolated_queue(cfg):
"""Set up an isolated queue for testing using ntuple filter.
Remove queue 1 from the default RSS context and steer test traffic to it.
"""
+ _require_ntuple(cfg)
test_queue = 1
qcnt = len(glob.glob(f"/sys/class/net/{cfg.ifname}/queues/rx-*"))
diff --git a/tools/testing/selftests/drivers/net/hw/iou-zcrx.py b/tools/testing/selftests/drivers/net/hw/iou-zcrx.py
index e81724cb5542..d72b76ba0835 100755
--- a/tools/testing/selftests/drivers/net/hw/iou-zcrx.py
+++ b/tools/testing/selftests/drivers/net/hw/iou-zcrx.py
@@ -100,12 +100,22 @@ def rss(cfg):
defer(ethtool, f"-N {cfg.ifname} delete {flow_rule_id}")
+def _require_ntuple(cfg):
+ features = ethtool(f"-k {cfg.ifname}", json=True)[0]
+ if not features["ntuple-filters"]["active"]:
+ if features["ntuple-filters"]["fixed"]:
+ raise KsftSkipEx("Device does not support ntuple-filters")
+ ethtool(f"-K {cfg.ifname} ntuple-filters on")
+ defer(ethtool, f"-K {cfg.ifname} ntuple-filters off")
+
+
@ksft_variants([
KsftNamedVariant("single", single),
KsftNamedVariant("rss", rss),
])
def test_zcrx(cfg, setup) -> None:
cfg.require_ipver('6')
+ _require_ntuple(cfg)
setup(cfg)
rx_cmd = f"{cfg.bin_local} -s -p {cfg.port} -i {cfg.ifname} -q {cfg.target}"
@@ -121,6 +131,7 @@ def test_zcrx(cfg, setup) -> None:
])
def test_zcrx_oneshot(cfg, setup) -> None:
cfg.require_ipver('6')
+ _require_ntuple(cfg)
setup(cfg)
rx_cmd = f"{cfg.bin_local} -s -p {cfg.port} -i {cfg.ifname} -q {cfg.target} -o 4"
@@ -134,6 +145,7 @@ def test_zcrx_large_chunks(cfg) -> None:
"""Test zcrx with large buffer chunks."""
cfg.require_ipver('6')
+ _require_ntuple(cfg)
hp_file = "/proc/sys/vm/nr_hugepages"
with open(hp_file, 'r+', encoding='utf-8') as f:
diff --git a/tools/testing/selftests/drivers/net/hw/ntuple.py b/tools/testing/selftests/drivers/net/hw/ntuple.py
index 232733142c02..ef4604bfa8ef 100755
--- a/tools/testing/selftests/drivers/net/hw/ntuple.py
+++ b/tools/testing/selftests/drivers/net/hw/ntuple.py
@@ -22,7 +22,10 @@ class NtupleField(Enum):
def _require_ntuple(cfg):
features = ethtool(f"-k {cfg.ifname}", json=True)[0]
if not features["ntuple-filters"]["active"]:
- raise KsftSkipEx("Ntuple filters not enabled on the device: " + str(features["ntuple-filters"]))
+ if features["ntuple-filters"]["fixed"]:
+ raise KsftSkipEx("Device does not support ntuple-filters")
+ ethtool(f"-K {cfg.ifname} ntuple-filters on")
+ defer(ethtool, f"-K {cfg.ifname} ntuple-filters off")
def _get_rx_cnts(cfg, prev=None):
--git a/tools/testing/selftests/drivers/net/hw/rss_ctx.py b/tools/testing/selftests/drivers/net/hw/rss_ctx.py
index 1243fe426d35..f36f76d6ca59 100755
--- a/tools/testing/selftests/drivers/net/hw/rss_ctx.py
+++ b/tools/testing/selftests/drivers/net/hw/rss_ctx.py
@@ -57,9 +57,10 @@ def ethtool_create(cfg, act, opts):
def require_ntuple(cfg):
features = ethtool(f"-k {cfg.ifname}", json=True)[0]
if not features["ntuple-filters"]["active"]:
- # ntuple is more of a capability than a config knob, don't bother
- # trying to enable it (until some driver actually needs it).
- raise KsftSkipEx("Ntuple filters not enabled on the device: " + str(features["ntuple-filters"]))
+ if features["ntuple-filters"]["fixed"]:
+ raise KsftSkipEx("Device does not support ntuple-filters")
+ ethtool(f"-K {cfg.ifname} ntuple-filters on")
+ defer(ethtool, f"-K {cfg.ifname} ntuple-filters off")
def require_context_cnt(cfg, need_cnt):
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net v5] ipv6: Implement limits on extension header parsing
From: Justin Iurman @ 2026-04-30 16:53 UTC (permalink / raw)
To: Daniel Borkmann, kuba
Cc: edumazet, dsahern, tom, willemdebruijn.kernel, idosch, pabeni,
netdev
In-Reply-To: <20260429154648.809751-1-daniel@iogearbox.net>
On 4/29/26 17:46, Daniel Borkmann wrote:
> ipv6_{skip_exthdr,find_hdr}() and ip6_{tnl_parse_tlv_enc_lim,
> protocol_deliver_rcu}() iterate over IPv6 extension headers until they
> find a non-extension-header protocol or run out of packet data. The
> loops have no iteration counter, relying solely on the packet length
> to bound them. For a crafted packet with 8-byte extension headers
> filling a 64KB jumbogram, this means a worst case of up to ~8k
> iterations with a skb_header_pointer call each. ipv6_skip_exthdr(),
> for example, is used where it parses the inner quoted packet inside
> an incoming ICMPv6 error:
>
> - icmpv6_rcv
> - checksum validation
> - case ICMPV6_DEST_UNREACH
> - icmpv6_notify
> - pskb_may_pull() <- pull inner IPv6 header
> - ipv6_skip_exthdr() <- iterates here
> - pskb_may_pull()
> - ipprot->err_handler() <- sk lookup
>
> The per-iteration cost of ipv6_skip_exthdr itself is generally
> light, but skb_header_pointer becomes more costly on reassembled
> packets: the first ~1232 bytes of the inner packet are in the skb's
> linear area, but the remaining ~63KB are in the frag_list where
> skb_copy_bits is needed to read data.
>
> Initially, the idea was to add a configurable limit via a new
> sysctl knob with default 8, in line with knobs from commit
> 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination
> options"), but two reasons eventually argued against it:
>
> - It adds to UAPI that needs to be maintained forever, and
> upcoming work is restricting extension header ordering anyway,
> leaving little reason for another sysctl knob
> - exthdrs_core.c is always built-in even when CONFIG_IPV6=n,
> where struct net has no .ipv6 member, so the read site would
> need an ifdef'd fallback to a constant anyway
>
> Therefore, just use a constant (IP6_MAX_EXT_HDRS_CNT). All four
> extension header walking functions are now bound by this limit.
>
> Note that the check in ip6_protocol_deliver_rcu() happens right
> before the goto resubmit, such that we don't have to have a test
> for ipv6_ext_hdr() in the fast-path.
>
> There's an ongoing IETF draft-iurman-6man-eh-occurrences to enforce
> IPv6 extension headers ordering and occurrence. The latter also
> discusses security implications. As per RFC8200 section 4.1, the
> occurrence rules for extension headers provide a practical upper
> bound which is 8. In order to be conservative, let's define
> IP6_MAX_EXT_HDRS_CNT as 12 to leave enough room for quirky setups.
> In the unlikely event that this is still not enough, then we might
> need to reconsider a sysctl.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Thanks for your patience, Daniel!
Cheers,
Justin
^ permalink raw reply
* Re: [PATCH iwl-net] idpf: fix RSS LUT memcpy size
From: Simon Horman @ 2026-04-30 16:58 UTC (permalink / raw)
To: Larysa Zaremba
Cc: intel-wired-lan, Jacob Keller, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Joshua Hay, Willem de Bruijn, Alice Michael, netdev, linux-kernel,
Aleksandr Loktionov, Tony Nguyen
In-Reply-To: <20260429074232.180528-1-larysa.zaremba@intel.com>
On Wed, Apr 29, 2026 at 09:42:30AM +0200, Larysa Zaremba wrote:
> Based on the following feedback from Sashiko (received for iXD phase 1
> patchset, but valid for the net tree):
>
> "Is the bounds check xn_params.recv_mem.iov_len < lut_buf_size sufficient?
> Since lut_buf_size only represents the size of the array elements, should
> this check instead verify that the payload is at least
> sizeof(struct virtchnl2_rss_lut) + lut_buf_size?
>
> [...]
>
> Does memcpy copy the correct amount of data here? rss_lut_size stores the
> number of 32-bit entries, not the size in bytes. Should it use
> lut_buf_size or rss_data->rss_lut_size * sizeof(u32) instead?"
>
> After inspecting the code, it was concluded that RSS memcpy size is in fact
> 4 times smaller than it has to be, since a single array entry in a u32, and
> rss_data->rss_lut_size is clearly used as an array size. Required Rx buffer
> size is also too small, but this is a common issue in the idpf code.
>
> Use a full buffer size (lut_buf_size) instead of the array length
> (rss_data->rss_lut_size) when doing memcpy of RSS lookup table.
> While at it, increase required Rx buffer size to a whole flex-array
> containing structure instead of just the array.
>
> Link: https://sashiko.dev/#/patchset/20260323174052.5355-1-larysa.zaremba%40intel.com?part=8
> Fixes: 95af467d9a4e ("idpf: configure resources for RX queues")
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
There is an AI generated review of this patch available on sashiko.dev.
It seems to me that the issues raised there do warrant further investigation.
But that they are pre-existing problems that and don't need to
block progress of this patch.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
From: Dmitry Safonov @ 2026-04-30 17:01 UTC (permalink / raw)
To: Paolo Abeni
Cc: Jakub Kicinski, Eric Biggers, netdev, linux-crypto, linux-kernel,
Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima, David S . Miller,
David Ahern, Simon Horman, Ard Biesheuvel, Jason A . Donenfeld,
Herbert Xu, Dmitry Safonov
In-Reply-To: <a642b858-eea0-4b7a-aeb2-aa67c6cf0f64@redhat.com>
On Thu, 30 Apr 2026 at 08:38, Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 4/28/26 2:00 AM, Dmitry Safonov wrote:
[..]
> > Yeah, that's not what I meant. I see value in Eric's contribution, and
> > I like getting rid of tcp-sigpool. So, anything but "nack" is not "no"
> > :-)
>
> I read the above as: "If there isn't any additional feedback soon,
> please apply".
Thanks, Paolo, that's exactly what I meant.
I think we addressed both concerns I had with the new RFC and BIRD
daemon, and Eric did a good job optimising the crypto layer here, so
we are better with his patches than with my sentimental attachment to
extendability that so far is not really required by BGP. And if we
need to extend the list of algorithms, we will be able to do it on top
later.
Thanks again,
Dmitry
^ permalink raw reply
* Re: [PATCH v3 net] net: enetc: fix VSI mailbox timeout handling and DMA lifecycle
From: Simon Horman @ 2026-04-30 17:09 UTC (permalink / raw)
To: wei.fang
Cc: 'Simon Horman', claudiu.manoil, vladimir.oltean,
xiaoning.wang, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, imx
In-Reply-To: <20260429081930.3259824-1-wei.fang@nxp.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
Subject: net: enetc: fix VSI mailbox timeout handling and DMA lifecycle
This commit attempts to fix a use-after-free issue in the VSI mailbox
send path by deferring the freeing of the DMA buffer if the hardware is
still processing the message. The DMA buffer information is stored in the
si structure and freed on the next send or when the driver is removed.
[ ... ]
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_vf.c b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> --- a/drivers/net/ethernet/freescale/enetc/enetc_vf.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_vf.c
[ ... ]
> @@ -259,6 +282,7 @@ static void enetc_vf_remove(struct pci_dev *pdev)
> {
> struct enetc_si *si = pci_get_drvdata(pdev);
> struct enetc_ndev_priv *priv;
> + struct enetc_msg_swbd msg;
>
> priv = netdev_priv(si->ndev);
> unregister_netdev(si->ndev);
> @@ -270,7 +294,9 @@ static void enetc_vf_remove(struct pci_dev *pdev)
>
> free_netdev(si->ndev);
>
> + msg = si->msg;
> enetc_pci_remove(pdev);
> + enetc_msg_dma_free(&pdev->dev, &msg);
Is it possible for the mailbox to still be busy here?
The commit addresses the use-after-free in the send path by checking the
mailbox busy status before freeing the previous buffer. However, during
driver teardown, enetc_msg_dma_free() is called unconditionally.
If a prior message sent via enetc_msg_vsi_send() times out and the hardware
is still accessing the buffer, and then the driver is unbound, could this
cause the hardware to read from freed DMA memory?
Should the teardown path wait for the mailbox to become idle or ensure the
hardware is safely reset before freeing the buffer?
> }
^ permalink raw reply
* Re: [PATCH net v2] bridge: mcast: Fix a false positive lockdep splat
From: Eric Dumazet @ 2026-04-30 17:10 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, bridge, davem, kuba, pabeni, razor, horms, herbert,
linus.luessing, petrm
In-Reply-To: <20260430162604.1043756-1-idosch@nvidia.com>
On Thu, Apr 30, 2026 at 9:27 AM Ido Schimmel <idosch@nvidia.com> wrote:
>
> Connecting two bridges on the same system [1] can result in a lockdep
> splat [2].
>
> The report is a false positive. Multicast queries are built and
> transmitted under the bridge multicast lock. When the outgoing port of
> one bridge is configured on top of another bridge, the transmit path
> re-enters bridge code and acquires the other bridge's multicast lock in
> order to snoop the query. Both lock instances share a single lockdep
> class, so lockdep flags the nested acquisition as an AA deadlock.
>
> Giving each bridge its own lock class will not solve the problem: the
> reverse topology would produce an ABBA splat with the same pair of
> classes. It also consumes a lockdep key per bridge.
>
> Instead, fix the problem by deferring the transmission of the queries to
> a workqueue. Build the skb and update querier state under the lock as
> before, then enqueue the skb on a per multicast context queue and
> schedule the work.
>
> Flush the work when the multicast context is de-initialized. At this
> stage the work cannot be requeued. There is no need to take a reference
> on skb->dev since the work cannot outlive the bridge or the bridge port.
>
> Use the high priority workqueue to reduce the delay between the enqueue
> time and the transmission time. With default settings (i.e., querier
> interval - 255 seconds, query interval - 125 seconds) the extra delay
> should not be a problem.
>
> Avoid the unlikely case of the queue growing endlessly by limiting it to
> 1,000 skbs. Use this number for the simple reason that this is the
> default Tx queue length.
>
> [1]
> ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1
> ip link add name br0 up type bridge mcast_snooping 1 mcast_querier 1
> ip link add link br0 name br0.10 up master br1 type vlan id 10
>
> [2]
> WARNING: possible recursive locking detected
> 7.0.0-virtme-gb50c64a58a90 #1 Not tainted
> [...]
> ip/339 is trying to acquire lock:
> ffff888104f0b480 (&br->multicast_lock){+.-.}-{3:3}, at: br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
>
> but task is already holding lock:
> ffff888104f03480 (&br->multicast_lock){+.-.}-{3:3}, at: br_multicast_port_query_expired (net/bridge/br_multicast.c:1904)
>
> [...]
>
> Call Trace:
> [...]
> br_ip6_multicast_query (net/bridge/br_multicast.c:3584)
> br_multicast_ipv6_rcv (net/bridge/br_multicast.c:3988)
> br_dev_xmit (net/bridge/br_device.c:98 (discriminator 1))
> dev_hard_start_xmit (./include/linux/netdevice.h:5343 ./include/linux/netdevice.h:5352 net/core/dev.c:3888 net/core/dev.c:3904)
> __dev_queue_xmit (./include/linux/netdevice.h:3619 net/core/dev.c:4871)
> vlan_dev_hard_start_xmit (net/8021q/vlan_dev.c:131 (discriminator 1))
> dev_hard_start_xmit (./include/linux/netdevice.h:5343 ./include/linux/netdevice.h:5352 net/core/dev.c:3888 net/core/dev.c:3904)
> __dev_queue_xmit (./include/linux/netdevice.h:3619 net/core/dev.c:4871)
> br_dev_queue_push_xmit (net/bridge/br_forward.c:60)
> __br_multicast_send_query (net/bridge/br_multicast.c:1811 (discriminator 1))
> br_multicast_send_query (net/bridge/br_multicast.c:1889)
> br_multicast_port_query_expired (./include/linux/spinlock.h:390 net/bridge/br_multicast.c:1914)
> call_timer_fn (./arch/x86/include/asm/jump_label.h:37 ./include/trace/events/timer.h:127 kernel/time/timer.c:1749)
> [...]
>
> Fixes: eb1d16414339 ("bridge: Add core IGMP snooping support")
> Reported-by: syzbot+d7b7f1412c02134efa6d@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/000000000000c4c9d405f2643e01@google.com/
> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
> Reviewed-by: Petr Machata <petrm@nvidia.com>
> Signed-off-by: Ido Schimmel <idosch@nvidia.com>
> ---
> v2:
> - Limit the queue to 1,000 skbs.
> - Edit the trace to avoid checkpatch errors.
> v1: https://lore.kernel.org/netdev/20260426133435.207006-1-idosch@nvidia.com/
> ---
> net/bridge/br_multicast.c | 47 +++++++++++++++++++++++++++++++++++----
> net/bridge/br_private.h | 4 ++++
> 2 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 881d866d687a..e9f5fe01ff95 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1776,6 +1776,30 @@ static void br_multicast_select_own_querier(struct net_bridge_mcast *brmctx,
> #endif
> }
>
> +static void br_multicast_port_query_queue_work(struct work_struct *work)
> +{
> + struct net_bridge_mcast_port *pmctx;
> + struct sk_buff *skb;
> +
> + pmctx = container_of(work, struct net_bridge_mcast_port,
> + query_queue_work);
> + while ((skb = skb_dequeue(&pmctx->query_queue)))
> + NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT, dev_net(skb->dev),
> + NULL, skb, NULL, skb->dev, br_dev_queue_push_xmit);
> +}
> +
> +static void br_multicast_query_queue_work(struct work_struct *work)
> +{
> + struct net_bridge_mcast *brmctx;
> + struct sk_buff *skb;
> +
> + brmctx = container_of(work, struct net_bridge_mcast, query_queue_work);
> + while ((skb = skb_dequeue(&brmctx->query_queue)))
> + netif_rx(skb);
> +}
These two functions could loop forever under flood.
Perhaps use skb_queue_splice_init() to limit each round to the ~1,000
limit you have mentioned in the changelog.
And return after the spliced list has been processed.
Bonus: no more spinlock acquisition for each skb_dequeue()
^ permalink raw reply
* Re: [PATCH net 0/2] net: mctp: test: minor kunit test fixes
From: Simon Horman @ 2026-04-30 17:15 UTC (permalink / raw)
To: Jeremy Kerr
Cc: Matt Johnston, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev, kernel test robot
In-Reply-To: <20260429-dev-mctp-test-fixes-v1-0-1127b7425809@codeconstruct.com.au>
On Wed, Apr 29, 2026 at 04:21:40PM +0800, Jeremy Kerr wrote:
> This series provides two fixes in the MCTP kunit tests - one exposed by
> ktr, and one found while debugging the former on different VM configs.
>
> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
> ---
> Jeremy Kerr (2):
> net: mctp: test: use a zeroed struct sockaddr_mctp
> net: mctp: test: Use dev_direct_xmit for TX to our test device
>
> net/mctp/test/route-test.c | 2 +-
> net/mctp/test/utils.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
For the series:
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next] net: mctp: test: remove skb dumps from test output
From: Simon Horman @ 2026-04-30 17:18 UTC (permalink / raw)
To: Jeremy Kerr
Cc: Matt Johnston, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev
In-Reply-To: <20260429-dev-mctp-test-skb-dump-v1-1-13fd5789ef71@codeconstruct.com.au>
On Wed, Apr 29, 2026 at 04:27:31PM +0800, Jeremy Kerr wrote:
> We're currently dumping skb info in our fragment input test, which makes
> interpreting the TAP test output a bit awkward.
>
> Remove the skb dumps.
>
> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init
From: Paul Menzel @ 2026-04-30 17:20 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260430142153.249062-1-aleksandr.loktionov@intel.com>
Dear Aleksandr,
Thank you for your patch.
Am 30.04.26 um 16:21 schrieb Aleksandr Loktionov:
> set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
> ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
> providing ptype >= 1024 through VIRTCHNL, resulting in a write past
> the end of the bitmap and a kernel page fault.
>
> Reproduced with a custom kernel module injecting a crafted
> VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592),
> FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0,
> kernel 7.1.0-rc1.
7.1-rc1 (no need to resend)
> crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
> crash_parser: setting ptype=0xffff (max valid=1023)
> crash_parser: calling ice_parser_profile_init -- expect OOB crash!
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> Oops: Oops: 0002 [#1] SMP NOPTI
> CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1
> Hardware name: Intel Corporation S2600BPB/S2600BPB
> RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice]
> Call Trace:
> <TASK>
> ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
> crash_init+0x127/0xff0 [crash_parser]
> do_one_initcall+0x45/0x310
> do_init_module+0x64/0x270
> init_module_from_file+0xcc/0xf0
> idempotent_init_module+0x17b/0x280
> __x64_sys_finit_module+0x6e/0xe0
>
> Bail out early with -EINVAL when ptype is out of range.
Is a warning logged now?
> Fixes: e312b3a1e209 ("ice: add API for parser profile initialization")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c b/drivers/net/ethernet/intel/ice/ice_parser.c
> index f8e6963..3ede4c1 100644
> --- a/drivers/net/ethernet/intel/ice/ice_parser.c
> +++ b/drivers/net/ethernet/intel/ice/ice_parser.c
> @@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct ice_parser_result *rslt,
> u16 proto_off = 0;
> u16 off;
>
> + if (rslt->ptype >= ICE_FLOW_PTYPE_MAX)
> + return -EINVAL;
> +
> memset(prof, 0, sizeof(*prof));
> set_bit(rslt->ptype, prof->ptypes);
> if (blk == ICE_BLK_SW) {
Kind regards,
Paul
^ permalink raw reply
* [PATCH net-next v2 0/2] dpll: rework fractional frequency offset reporting
From: Ivan Vecera @ 2026-04-30 17:36 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
Rework how the fractional frequency offset (FFO) is reported in
the DPLL subsystem.
The fractional-frequency-offset-ppt attribute is moved from the
top-level pin attributes into the pin-parent-device nested attribute
set. This makes it consistent with phase-offset (which is already
per-parent) and clarifies that FFO PPT represents the frequency
difference between a pin and its parent DPLL device.
The two FFO contexts are distinguished in the ffo_get callback:
dpll=NULL for the top-level RX vs TX symbol rate offset and a valid
dpll pointer for the nested pin vs DPLL offset.
Patch 1 restructures the DPLL subsystem netlink handling, updates
the YAML spec and driver-api documentation, and adds NULL guards
to mlx5 and zl3073x drivers.
Patch 2 implements the nested FFO for zl3073x using the
dpll_df_offset_x register with ref_ofst=1, providing 2^-48
resolution. The old per-reference frequency measurement is removed
as it was redundant with measured-frequency.
Ivan Vecera (2):
dpll: move fractional-frequency-offset-ppt under pin-parent-device
dpll: zl3073x: report FFO as DPLL vs input reference offset
Documentation/driver-api/dpll.rst | 16 +++++++
Documentation/netlink/specs/dpll.yaml | 11 +++--
drivers/dpll/dpll_netlink.c | 34 ++++++++++----
drivers/dpll/dpll_nl.c | 1 +
drivers/dpll/zl3073x/chan.c | 31 ++++++++++++-
drivers/dpll/zl3073x/chan.h | 14 ++++++
drivers/dpll/zl3073x/core.c | 45 -------------------
drivers/dpll/zl3073x/dpll.c | 34 +++++++-------
drivers/dpll/zl3073x/ref.h | 14 ------
drivers/dpll/zl3073x/regs.h | 15 +++++++
.../net/ethernet/mellanox/mlx5/core/dpll.c | 4 ++
11 files changed, 126 insertions(+), 93 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH net-next v2 1/2] dpll: move fractional-frequency-offset-ppt under pin-parent-device
From: Ivan Vecera @ 2026-04-30 17:36 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260430173611.3312596-1-ivecera@redhat.com>
Move the fractional-frequency-offset-ppt attribute from the top-level
pin attributes into the pin-parent-device nested attribute set. This
makes it consistent with phase-offset which is already per-parent and
clarifies that FFO PPT represents the frequency difference between
a pin and its parent DPLL device.
The top-level fractional-frequency-offset attribute (in PPM) remains
unchanged for backward compatibility.
Distinguish the two contexts in the ffo_get callback by passing
dpll=NULL for the top-level (rx vs tx symbol rate) call and a valid
dpll pointer for the nested (pin vs parent DPLL) call. Update mlx5
and zl3073x drivers to return -ENODATA for the nested context they
do not yet support.
Add documentation for both FFO attributes to dpll.rst.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Documentation/driver-api/dpll.rst | 16 +++++++++
Documentation/netlink/specs/dpll.yaml | 11 +++---
drivers/dpll/dpll_netlink.c | 34 ++++++++++++++-----
drivers/dpll/dpll_nl.c | 1 +
drivers/dpll/zl3073x/dpll.c | 4 +++
.../net/ethernet/mellanox/mlx5/core/dpll.c | 4 +++
6 files changed, 56 insertions(+), 14 deletions(-)
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
index 37eaef785e304..8576d360a5815 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -258,6 +258,22 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
=============================== ========================
+Fractional frequency offset
+===========================
+
+The fractional frequency offset (FFO) represents the frequency difference
+between a pin and its parent DPLL device. It is reported in the
+``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT`` attribute nested under
+the parent device, in parts per trillion (PPT, 10^-12).
+
+This is analogous to ``DPLL_A_PIN_PHASE_OFFSET`` but in the frequency
+domain. It is typically reported only for the currently active input pin.
+
+The top-level ``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET`` attribute (in PPM)
+represents the RX vs TX symbol rate offset on the media associated with
+the pin (e.g. for SyncE ethernet ports) and is independent of the
+per-parent FFO PPT attribute.
+
Frequency monitor
=================
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index c45de70a47ce6..a5807169eb126 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -492,12 +492,10 @@ attribute-sets:
name: fractional-frequency-offset-ppt
type: sint
doc: |
- The FFO (Fractional Frequency Offset) of the pin with respect to
- the nominal frequency.
- Value = (frequency_measured - frequency_nominal) / frequency_nominal
+ The FFO (Fractional Frequency Offset) between a pin and its
+ parent DPLL device, similar to phase-offset but in frequency
+ domain.
Value is in PPT (parts per trillion, 10^-12).
- Note: This attribute provides higher resolution than the standard
- fractional-frequency-offset (which is in PPM).
-
name: measured-frequency
type: u64
@@ -534,6 +532,8 @@ attribute-sets:
name: operstate
-
name: phase-offset
+ -
+ name: fractional-frequency-offset-ppt
-
name: pin-parent-pin
subset-of: pin
@@ -703,7 +703,6 @@ operations:
- phase-adjust-max
- phase-adjust
- fractional-frequency-offset
- - fractional-frequency-offset-ppt
- esync-frequency
- esync-frequency-supported
- esync-pulse
diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index 05cf946b4be5e..39b99382be40d 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -418,6 +418,27 @@ dpll_msg_add_phase_offset(struct sk_buff *msg, struct dpll_pin *pin,
static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
struct dpll_pin_ref *ref,
struct netlink_ext_ack *extack)
+{
+ const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+ s64 ffo;
+ int ret;
+
+ if (!ops->ffo_get)
+ return 0;
+ ret = ops->ffo_get(pin, dpll_pin_on_dpll_priv(ref->dpll, pin),
+ NULL, NULL, &ffo, extack);
+ if (ret) {
+ if (ret == -ENODATA)
+ return 0;
+ return ret;
+ }
+ return nla_put_sint(msg, DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET,
+ div_s64(ffo, 1000000));
+}
+
+static int dpll_msg_add_ffo_ppt(struct sk_buff *msg, struct dpll_pin *pin,
+ struct dpll_pin_ref *ref,
+ struct netlink_ext_ack *extack)
{
const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
struct dpll_device *dpll = ref->dpll;
@@ -433,14 +454,8 @@ static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
return 0;
return ret;
}
- /* Put the FFO value in PPM to preserve compatibility with older
- * programs.
- */
- ret = nla_put_sint(msg, DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET,
- div_s64(ffo, 1000000));
- if (ret)
- return -EMSGSIZE;
- return nla_put_sint(msg, DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
+ return nla_put_sint(msg,
+ DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
ffo);
}
@@ -686,6 +701,9 @@ dpll_msg_add_pin_dplls(struct sk_buff *msg, struct dpll_pin *pin,
if (ret)
goto nest_cancel;
ret = dpll_msg_add_phase_offset(msg, pin, ref, extack);
+ if (ret)
+ goto nest_cancel;
+ ret = dpll_msg_add_ffo_ppt(msg, pin, ref, extack);
if (ret)
goto nest_cancel;
nla_nest_end(msg, attr);
diff --git a/drivers/dpll/dpll_nl.c b/drivers/dpll/dpll_nl.c
index 58235845fa3d5..23108574b8fb4 100644
--- a/drivers/dpll/dpll_nl.c
+++ b/drivers/dpll/dpll_nl.c
@@ -19,6 +19,7 @@ const struct nla_policy dpll_pin_parent_device_nl_policy[DPLL_A_PIN_OPERSTATE +
[DPLL_A_PIN_STATE] = NLA_POLICY_RANGE(NLA_U32, 1, 3),
[DPLL_A_PIN_OPERSTATE] = NLA_POLICY_RANGE(NLA_U32, 1, 4),
[DPLL_A_PIN_PHASE_OFFSET] = { .type = NLA_S64, },
+ [DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT] = { .type = NLA_SINT, },
};
const struct nla_policy dpll_pin_parent_pin_nl_policy[DPLL_A_PIN_STATE + 1] = {
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index 6fd718696de0d..f2d430d1a8e7b 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -299,6 +299,10 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
{
struct zl3073x_dpll_pin *pin = pin_priv;
+ /* Only rx vs tx symbol rate FFO is supported */
+ if (dpll)
+ return -ENODATA;
+
*ffo = pin->freq_offset;
return 0;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/dpll.c b/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
index bce72e8d1bc31..ef2c58c390efa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
@@ -306,6 +306,10 @@ static int mlx5_dpll_ffo_get(const struct dpll_pin *pin, void *pin_priv,
struct mlx5_dpll *mdpll = pin_priv;
int err;
+ /* Only rx vs tx symbol rate FFO is supported */
+ if (dpll)
+ return -ENODATA;
+
err = mlx5_dpll_synce_status_get(mdpll->mdev, &synce_status);
if (err)
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 2/2] dpll: zl3073x: report FFO as DPLL vs input reference offset
From: Ivan Vecera @ 2026-04-30 17:36 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260430173611.3312596-1-ivecera@redhat.com>
Replace the per-reference frequency offset measurement (which was
redundant with measured-frequency) with a direct read of the DPLL's
delta frequency offset vs its tracked input reference.
The new implementation uses the dpll_df_offset_x register with
ref_ofst=1 via the dpll_df_read_x semaphore mechanism. This
provides 2^-48 resolution (~3.5 fE) and reports the actual
frequency difference between the DPLL and its active input.
FFO is now reported only for the active input pin in the nested
(pin vs parent DPLL) context. Top-level FFO returns -ENODATA.
Rewrite ffo_check to compare the cached df_offset converted to PPT
instead of using the old per-reference measurement. Remove the
ref_ffo_update periodic measurement and the ref ffo field since
they are no longer needed.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/chan.c | 31 +++++++++++++++++++++++--
drivers/dpll/zl3073x/chan.h | 14 ++++++++++++
drivers/dpll/zl3073x/core.c | 45 -------------------------------------
drivers/dpll/zl3073x/dpll.c | 34 ++++++++++++----------------
drivers/dpll/zl3073x/ref.h | 14 ------------
drivers/dpll/zl3073x/regs.h | 15 +++++++++++++
6 files changed, 72 insertions(+), 81 deletions(-)
diff --git a/drivers/dpll/zl3073x/chan.c b/drivers/dpll/zl3073x/chan.c
index 2f48ca2391494..2fe3c3da84bb5 100644
--- a/drivers/dpll/zl3073x/chan.c
+++ b/drivers/dpll/zl3073x/chan.c
@@ -18,6 +18,7 @@
int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
{
struct zl3073x_chan *chan = &zldev->chan[index];
+ u64 val;
int rc;
rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_MON_STATUS(index),
@@ -25,8 +26,34 @@ int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
if (rc)
return rc;
- return zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
- &chan->refsel_status);
+ rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
+ &chan->refsel_status);
+ if (rc)
+ return rc;
+
+ /* Read df_offset vs tracked reference */
+ rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM | ZL_DPLL_DF_READ_REF_OFST);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_read_u48(zldev, ZL_REG_DPLL_DF_OFFSET(index), &val);
+ if (rc)
+ return rc;
+
+ chan->df_offset = sign_extend64(val, 47);
+
+ return 0;
}
/**
diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h
index 481da2133202b..4353809c69122 100644
--- a/drivers/dpll/zl3073x/chan.h
+++ b/drivers/dpll/zl3073x/chan.h
@@ -17,6 +17,7 @@ struct zl3073x_dev;
* @ref_prio: reference priority registers (4 bits per ref, P/N packed)
* @mon_status: monitor status register value
* @refsel_status: reference selection status register value
+ * @df_offset: frequency offset vs tracked reference in 2^-48 steps
*/
struct zl3073x_chan {
struct_group(cfg,
@@ -26,6 +27,7 @@ struct zl3073x_chan {
struct_group(stat,
u8 mon_status;
u8 refsel_status;
+ s64 df_offset;
);
};
@@ -37,6 +39,18 @@ int zl3073x_chan_state_set(struct zl3073x_dev *zldev, u8 index,
int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index);
+/**
+ * zl3073x_chan_df_offset_get - get cached df_offset vs tracked reference
+ * @chan: pointer to channel state
+ *
+ * Return: frequency offset in 2^-48 steps
+ */
+static inline s64
+zl3073x_chan_df_offset_get(const struct zl3073x_chan *chan)
+{
+ return chan->df_offset;
+}
+
/**
* zl3073x_chan_mode_get - get DPLL channel operating mode
* @chan: pointer to channel state
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 5f1e70f3e40a0..b3345060490db 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -704,44 +704,6 @@ zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
return 0;
}
-/**
- * zl3073x_ref_ffo_update - update reference fractional frequency offsets
- * @zldev: pointer to zl3073x_dev structure
- *
- * The function asks device to latch the latest measured fractional
- * frequency offset values, reads and stores them into the ref state.
- *
- * Return: 0 on success, <0 on error
- */
-static int
-zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
-{
- int i, rc;
-
- rc = zl3073x_ref_freq_meas_latch(zldev,
- ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
- if (rc)
- return rc;
-
- /* Read DPLL-to-REFx frequency offset measurements */
- for (i = 0; i < ZL3073X_NUM_REFS; i++) {
- s32 value;
-
- /* Read value stored in units of 2^-32 signed */
- rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
- if (rc)
- return rc;
-
- /* Convert to ppt
- * ffo = (10^12 * value) / 2^32
- * ffo = ( 5^12 * value) / 2^20
- */
- zldev->ref[i].ffo = mul_s64_u64_shr(value, 244140625, 20);
- }
-
- return 0;
-}
-
static void
zl3073x_dev_periodic_work(struct kthread_work *work)
{
@@ -776,13 +738,6 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
}
}
- /* Update references' fractional frequency offsets */
- rc = zl3073x_ref_ffo_update(zldev);
- if (rc)
- dev_warn(zldev->dev,
- "Failed to update fractional frequency offsets: %pe\n",
- ERR_PTR(rc));
-
list_for_each_entry(zldpll, &zldev->dplls, list)
zl3073x_dpll_changes_check(zldpll);
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index f2d430d1a8e7b..af50cd6200001 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -299,8 +299,12 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
{
struct zl3073x_dpll_pin *pin = pin_priv;
- /* Only rx vs tx symbol rate FFO is supported */
- if (dpll)
+ /* Only nested FFO (pin vs parent DPLL) is supported */
+ if (!dpll)
+ return -ENODATA;
+
+ /* Report FFO only for the active pin */
+ if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
return -ENODATA;
*ffo = pin->freq_offset;
@@ -1733,37 +1737,27 @@ zl3073x_dpll_pin_phase_offset_check(struct zl3073x_dpll_pin *pin)
}
/**
- * zl3073x_dpll_pin_ffo_check - check for pin fractional frequency offset change
+ * zl3073x_dpll_pin_ffo_check - check for FFO change on active pin
* @pin: pin to check
*
- * Check for the given pin's fractional frequency change.
- *
- * Return: true on fractional frequency offset change, false otherwise
+ * Return: true on change, false otherwise
*/
static bool
zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
{
struct zl3073x_dpll *zldpll = pin->dpll;
- struct zl3073x_dev *zldev = zldpll->dev;
- const struct zl3073x_ref *ref;
- u8 ref_id;
+ const struct zl3073x_chan *chan;
s64 ffo;
- /* Get reference monitor status */
- ref_id = zl3073x_input_pin_ref_get(pin->id);
- ref = zl3073x_ref_state_get(zldev, ref_id);
-
- /* Do not report ffo changes if the reference monitor report errors */
- if (!zl3073x_ref_is_status_ok(ref))
+ if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
return false;
- /* Compare with previous value */
- ffo = zl3073x_ref_ffo_get(ref);
+ chan = zl3073x_chan_state_get(zldpll->dev, zldpll->id);
+ ffo = mul_s64_u64_shr(zl3073x_chan_df_offset_get(chan),
+ 244140625, 36);
+
if (pin->freq_offset != ffo) {
- dev_dbg(zldev->dev, "%s freq offset changed: %lld -> %lld\n",
- pin->label, pin->freq_offset, ffo);
pin->freq_offset = ffo;
-
return true;
}
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
index 55e80e4f08734..e140ca3ea17dc 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -22,7 +22,6 @@ struct zl3073x_dev;
* @freq_ratio_n: FEC mode divisor
* @sync_ctrl: reference sync control
* @config: reference config
- * @ffo: current fractional frequency offset
* @meas_freq: measured input frequency in Hz
* @mon_status: reference monitor status
*/
@@ -40,7 +39,6 @@ struct zl3073x_ref {
u8 config;
);
struct_group(stat, /* Status */
- s64 ffo;
u32 meas_freq;
u8 mon_status;
);
@@ -58,18 +56,6 @@ int zl3073x_ref_state_update(struct zl3073x_dev *zldev, u8 index);
int zl3073x_ref_freq_factorize(u32 freq, u16 *base, u16 *mult);
-/**
- * zl3073x_ref_ffo_get - get current fractional frequency offset
- * @ref: pointer to ref state
- *
- * Return: the latest measured fractional frequency offset
- */
-static inline s64
-zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
-{
- return ref->ffo;
-}
-
/**
* zl3073x_ref_meas_freq_get - get measured input frequency
* @ref: pointer to ref state
diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h
index 8015808bdf548..9578f00095282 100644
--- a/drivers/dpll/zl3073x/regs.h
+++ b/drivers/dpll/zl3073x/regs.h
@@ -164,6 +164,11 @@
#define ZL_DPLL_MODE_REFSEL_MODE_NCO 4
#define ZL_DPLL_MODE_REFSEL_REF GENMASK(7, 4)
+#define ZL_REG_DPLL_DF_READ(_idx) \
+ ZL_REG_IDX(_idx, 5, 0x28, 1, ZL3073X_MAX_CHANNELS, 1)
+#define ZL_DPLL_DF_READ_SEM BIT(4)
+#define ZL_DPLL_DF_READ_REF_OFST BIT(3)
+
#define ZL_REG_DPLL_MEAS_CTRL ZL_REG(5, 0x50, 1)
#define ZL_DPLL_MEAS_CTRL_EN BIT(0)
#define ZL_DPLL_MEAS_CTRL_AVG_FACTOR GENMASK(7, 4)
@@ -176,6 +181,16 @@
#define ZL_REG_DPLL_PHASE_ERR_DATA(_idx) \
ZL_REG_IDX(_idx, 5, 0x55, 6, ZL3073X_MAX_CHANNELS, 6)
+/*******************************
+ * Register Pages 6-7, DPLL Data
+ *******************************/
+
+#define ZL_REG_DPLL_DF_OFFSET_03(_idx) \
+ ZL_REG_IDX(_idx, 6, 0x00, 6, 4, 0x20)
+#define ZL_REG_DPLL_DF_OFFSET_4 ZL_REG(7, 0x00, 6)
+#define ZL_REG_DPLL_DF_OFFSET(_idx) \
+ ((_idx) < 4 ? ZL_REG_DPLL_DF_OFFSET_03(_idx) : ZL_REG_DPLL_DF_OFFSET_4)
+
/***********************************
* Register Page 9, Synth and Output
***********************************/
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net 6/7] net: tls: fix use-after-free in tls_sw_sendmsg_locked after bpf verdict
From: Jiayuan Chen @ 2026-04-30 17:50 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, bpf,
john.fastabend, sd, linux-kselftest, Jakub Kicinski, Alessandro G,
ast
In-Reply-To: <20260429222944.2139041-7-kuba@kernel.org>
April 29, 2026 at 3:29 PM, "Jakub Kicinski" <kuba@kernel.org mailto:kuba@kernel.org?to=%22Jakub%20Kicinski%22%20%3Ckuba%40kernel.org%3E > wrote:
>
> After bpf_exec_tx_verdict() returns in the zerocopy path, the local
> msg_pl/msg_en pointers may be stale. If a BPF program set apply_bytes
> such that tls_push_record() splits the open record via
> tls_split_open_record(), ctx->open_rec is replaced with the split
> remainder while the original record is pushed to the tx_list and may
> be freed by tls_tx_records(). The caller's cached msg_pl/msg_en still
> reference the old (now-freed) record.
>
> This is triggered when bpf_exec_tx_verdict() returns -ENOSPC (BPF set
> cork_bytes > remaining data) after an internal record split: the code
> dereferences msg_pl->cork_bytes on the freed record, causing a UAF.
>
> Reported-by: Alessandro G <ale.grpp@gmail.com>
> Fixes: 54a3ecaeeeae ("bpf: fix ktls panic with sockmap")
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: john.fastabend@gmail.com
> CC: sd@queasysnail.net
> CC: jiayuan.chen@linux.dev
> CC: ast@kernel.org
> CC: bpf@vger.kernel.org
> ---
> net/tls/tls_sw.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
> index 600e13effaab..d086b43fc675 100644
> --- a/net/tls/tls_sw.c
> +++ b/net/tls/tls_sw.c
> @@ -1157,6 +1157,13 @@ static int tls_sw_sendmsg_locked(struct sock *sk, struct msghdr *msg,
> else if (ret == -ENOMEM)
> goto wait_for_memory;
> else if (ctx->open_rec && ret == -ENOSPC) {
> + /* bpf_exec_tx_verdict() may have
> + * called tls_split_open_record(),
> + * freeing the old record. Re-fetch.
> + */
> + rec = ctx->open_rec;
> + msg_pl = &rec->msg_plaintext;
> + msg_en = &rec->msg_encrypted;
> if (msg_pl->cork_bytes) {
> ret = 0;
> goto send_end;
> --
> 2.54.0
>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev mailto:jiayuan.chen@linux.dev >
^ permalink raw reply
* Re: [PATCH net 7/7] selftests: bpf: cover tls_sw_sendmsg UAF after bpf_exec_tx_verdict split
From: Jiayuan Chen @ 2026-04-30 17:55 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, bpf,
john.fastabend, sd, linux-kselftest, Jakub Kicinski, andrii,
eddyz87, ast, daniel, martin.lau, memxor, song, yonghong.song,
jolsa, shuah, isolodrai
In-Reply-To: <20260429222944.2139041-8-kuba@kernel.org>
2026年4月29日 15:29, "Jakub Kicinski" <kuba@kernel.org mailto:kuba@kernel.org?to=%22Jakub%20Kicinski%22%20%3Ckuba%40kernel.org%3E > wrote:
>
> Add a regression test for the use-after-free in tls_sw_sendmsg_locked()
> where the cached msg_pl pointer becomes stale after bpf_exec_tx_verdict()
> returns -ENOSPC: tls_push_record() may have called
> tls_split_open_record() which replaces ctx->open_rec and frees the old
> record, but the caller still dereferences msg_pl->cork_bytes.
>
> Reusing prog_sk_policy with apply_bytes=1000 + cork_bytes=800, a single
> 1500-byte send on a kTLS TX socket in a sockmap drives the split-and-free
> path. Without the fix, KASAN reports slab-use-after-free in tls_sw_sendmsg
> and the kernel hangs; with the fix the test completes cleanly.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: andrii@kernel.org
> CC: eddyz87@gmail.com
> CC: ast@kernel.org
> CC: daniel@iogearbox.net
> CC: martin.lau@linux.dev
> CC: memxor@gmail.com
> CC: song@kernel.org
> CC: yonghong.song@linux.dev
> CC: jolsa@kernel.org
> CC: shuah@kernel.org
> CC: john.fastabend@gmail.com
> CC: jiayuan.chen@linux.dev
> CC: isolodrai@meta.com
> CC: bpf@vger.kernel.org
> CC: linux-kselftest@vger.kernel.org
> ---
>
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
^ permalink raw reply
* Re: [GIT PULL] bluetooth-next 2026-04-13
From: patchwork-bot+bluetooth @ 2026-04-30 17:55 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260413132247.320961-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to bluetooth/bluetooth-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 13 Apr 2026 09:22:47 -0400 you wrote:
> The following changes since commit 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7:
>
> tools: ynl: tests: fix leading space on Makefile target (2026-04-09 20:41:40 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git tags/for-net-next-2026-04-13
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth-next 2026-04-13
https://git.kernel.org/bluetooth/bluetooth-next/c/e9dc62f25ba6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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