* [PATCH net] ipvs: fix shift-out-of-bounds in ip_vs_rht_desired_size
From: Julian Anastasov @ 2026-04-27 23:40 UTC (permalink / raw)
To: Simon Horman
Cc: Pablo Neira Ayuso, Florian Westphal, lvs-devel, netfilter-devel,
netdev
Calling roundup_pow_of_two() with 0 has undefined result:
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'unsigned long'
CPU: 1 UID: 0 PID: 77 Comm: kworker/u8:4 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Workqueue: events_unbound conn_resize_work_handler
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
ubsan_epilogue+0xa/0x30 lib/ubsan.c:233
__ubsan_handle_shift_out_of_bounds+0x385/0x410 lib/ubsan.c:494
__roundup_pow_of_two include/linux/log2.h:57 [inline]
ip_vs_rht_desired_size+0x2cf/0x410 net/netfilter/ipvs/ip_vs_core.c:240
ip_vs_conn_desired_size net/netfilter/ipvs/ip_vs_conn.c:765 [inline]
conn_resize_work_handler+0x1b6/0x14c0 net/netfilter/ipvs/ip_vs_conn.c:822
process_one_work kernel/workqueue.c:3302 [inline]
process_scheduled_works+0xb5d/0x1860 kernel/workqueue.c:3385
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3466
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Reported-by: syzbot+217f1db9c791e27fe54a@syzkaller.appspotmail.com
Fixes: b655388111cf ("ipvs: add resizable hash tables")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/netfilter/ipvs/ip_vs_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index f5b7a2047291..ea450944465f 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -237,7 +237,7 @@ int ip_vs_rht_desired_size(struct netns_ipvs *ipvs, struct ip_vs_rht *t, int n,
{
if (!t)
return 1 << min_bits;
- n = roundup_pow_of_two(n);
+ n = n ? roundup_pow_of_two(n) : 1;
if (lfactor < 0) {
int factor = min(-lfactor, max_bits);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] MAINTAINERS: add pcnet_cs to PCMCIA
From: patchwork-bot+netdevbpf @ 2026-04-27 23:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, linux
In-Reply-To: <20260423220857.3490118-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 23 Apr 2026 15:08:57 -0700 you wrote:
> Per discussion under the Link make sure Dominik can help
> with the patches to drivers/net/ethernet/8390/pcnet_cs.c
>
> cc: linux@dominikbrodowski.net
> Link: https://lore.kernel.org/aeomUh5JqFvkLTH7@scops.dominikbrodowski.net
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> [...]
Here is the summary with links:
- [net] MAINTAINERS: add pcnet_cs to PCMCIA
https://git.kernel.org/netdev/net/c/3618442d54f3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2] Documentation: net/smc: correct old value of smcr_max_recv_wr
From: patchwork-bot+netdevbpf @ 2026-04-27 23:50 UTC (permalink / raw)
To: Mahanta Jambigi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, alibuda, dust.li,
sidraya, wenjia, wintera, pasic, horms, tonylu, guwen, netdev,
linux-s390
In-Reply-To: <20260424052336.3262350-1-mjambigi@linux.ibm.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 24 Apr 2026 07:23:36 +0200 you wrote:
> The smc-sysctl.rst documentation incorrectly stated that the previous
> hardcoded maximum number of WR buffers on the receive path (smcr_max_recv_wr)
> was 16. The correct historical value used before the introduction of the sysctl
> control was 48. Update the documentation to reflect the accurate historical
> value. Also fix a couple of minor typos.
>
> Fixes: aef3cdb47bbb net/smc: make wr buffer count configurable
> Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
> Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
> Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
>
> [...]
Here is the summary with links:
- [net-next,v2] Documentation: net/smc: correct old value of smcr_max_recv_wr
https://git.kernel.org/netdev/net-next/c/790ead939486
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: ethernet: rnpgbe: mark nonfunctional incomplete driver as BROKEN
From: Jakub Kicinski @ 2026-04-27 23:59 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: netdev, stable, Yibo Dong, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Vadim Fedorenko, MD Danish Anwar
In-Reply-To: <20260425041816.19070-1-enelsonmoore@gmail.com>
On Fri, 24 Apr 2026 21:18:15 -0700 Ethan Nelson-Moore wrote:
> +# This section depends on BROKEN because its only child item also does;
> +# see the explanation below.
> config NET_VENDOR_MUCSE
> bool "Mucse devices"
> default y
> + depends on BROKEN
> help
> If you have a network (Ethernet) card from Mucse(R), say Y.
We can keep the vendor as is, this doesn't enable any code compilation
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library
From: Dmitry Safonov @ 2026-04-28 0:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Eric Biggers, netdev, linux-crypto, linux-kernel, Eric Dumazet,
Neal Cardwell, Kuniyuki Iwashima, David S . Miller, David Ahern,
Paolo Abeni, Simon Horman, Ard Biesheuvel, Jason A . Donenfeld,
Herbert Xu, Dmitry Safonov
In-Reply-To: <20260427155538.2e1b8488@kernel.org>
On Mon, 27 Apr 2026 at 23:55, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 27 Apr 2026 20:09:05 +0100 Dmitry Safonov wrote:
> > I do like these numbers quite much! Yet, as I mentioned in version 1,
> > removing a fallback for other algorithms' support does not sound good
> > to me. There are two reasons:
> > - Ronald P. Bonica (the original RFC5925 author), together with Tony
> > Li do have an active RFC draft to support the additional algorithms
> > [1], potentially in addition to TCP Extended Options [2]
> > - There is at least one open-source BGP implementation (BIRD) that
> > allows using the algorithms that you are removing [3]. Without a
> > deprecation period and communication with at least known open source
> > users, it implies intentionally breaking them, which I can't agree
> > with.
> >
> > I don't feel like Naking as we don't have any customers using anything
> > other than the 3 algorithms above (and BGP implementation is
> > [unfortunately] closed-source, so that would not feel appropriate even
> > if we had such customers), yet I do feel like it's worth and
> > appropriate to express my thoughts/concerns.
>
> What do you want to happen? You are the maintainer of this code,
> you don't get so say "i don't want to nack it but also no" :)
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"
:-)
> Like Eric says if there are no real users code can be deleted.
> Adding deprecation warnings upstream is quite slow, IDK if injecting
> deprecation warnings to stable has been discussed..
FWIW, I've written to bird's mailing list inviting them to this
thread; in case if they need other algorithms to be supported,
hopefully that should avoid any breakages on their side.
I'm aware that ciena and fortinet use tcp-ao too, but I'm less
concerned, as they aren't open source.
Thanks,
Dmitry
^ permalink raw reply
* Re: [PATCH net V2 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Jakub Kicinski @ 2026-04-28 0:05 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Tariq Toukan, Eric Dumazet, Paolo Abeni, Andrew Lunn,
David S. Miller, Boris Pismenny, Saeed Mahameed, Leon Romanovsky,
Mark Bloch, Daniel Zahka, Cosmin Ratiu, Raed Salem,
Rahul Rameshbabu, Dragos Tatulea, Kees Cook, netdev, linux-rdma,
linux-kernel, Gal Pressman
In-Reply-To: <willemdebruijn.kernel.2f90e0de4485b@gmail.com>
On Sun, 26 Apr 2026 09:17:08 -0400 Willem de Bruijn wrote:
> > priv->psp->psp is initialized with the PSP device as returned by
> > psp_dev_create(). This could also return an error, in which case a
> > future psp_dev_unregister() will result in unpleasantness.
> >
> > Avoid that by using a local variable and only saving the PSP device when
> > registration succeeds.
> > Also apply some light refactoring of the functions managing the PSP
> > device in order to make them more readable/safe.
>
> This is generally discouraged as it obfuscates the fix.
+1, I should have said this during the v1 convo, I thought it's obvious
:\
^ permalink raw reply
* Re: [PATCH 1/2] hv_sock: fix ARM64 support
From: Jakub Kicinski @ 2026-04-28 0:06 UTC (permalink / raw)
To: Hamza Mahfooz
Cc: linux-kernel, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Stefano Garzarella, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Himadri Pandya,
Michael Kelley, linux-hyperv, virtualization, netdev,
Saurabh Sengar, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Deepak Rawat,
dri-devel, stable
In-Reply-To: <20260425181719.1538483-1-hamzamahfooz@linux.microsoft.com>
On Sat, 25 Apr 2026 11:17:18 -0700 Hamza Mahfooz wrote:
> VMBUS ring buffers must be page aligned. Therefore, the current value of
> 24K presents a challenge on ARM64 kernels (with 64K pages). So, use
> VMBUS_RING_SIZE() to ensure they are always aligned and large enough to
> hold all of the relevant data.
Please split the fixes into two independent postings.
They have to go via different trees AFAICT
^ permalink raw reply
* Re: [BUG] net: tcp: SO_LINGER with l_linger=0 leaks memory when closing sockets with pending send data
From: Kuniyuki Iwashima @ 2026-04-28 0:15 UTC (permalink / raw)
To: Ahmed, Aaron
Cc: stable@vger.kernel.org, netdev@vger.kernel.org,
ncardwell@google.com, edumazet@google.com
In-Reply-To: <A7A3F2FE-B18C-4F6D-A5E4-78164D6904F5@amazon.com>
On Mon, Apr 27, 2026 at 3:27 PM Ahmed, Aaron <aarnahmd@amazon.com> wrote:
>
> Hi Kuniyuki!
>
> Thanks for taking a look! To clarify the issue: the problem shows up on long-running servers
> with many concurrent connections. The original reproducer exits
> right after closing the sockets, so the memory gets cleaned up at
> process exit. In production the server never exits, so the memory
> just keeps growing. Is this expected behavior?
>
> I've written an updated reproducer that models a persistent
> server. You can pass 0 or 1 as an argument to set the l_linger value.
I tested it on both net-next.git and vanilla v6.18.20,
but I didn't see much difference.
l_linger=0:
sockets: used 41243
TCP: inuse 41101 orphan 0 tw 0 alloc 41103 mem 2635
l_linger=1:
sockets: used 50143
TCP: inuse 50007 orphan 0 tw 0 alloc 50009 mem 8473
>
> This outputs the following:
>
> When l_linger=0:
>
> TCP: inuse 7 orphan 0 tw 2 alloc 100009 mem 197259
>
> When l_linger=1:
>
> TCP: inuse 50008 orphan 0 tw 5 alloc 50009 mem 14426
>
> With l_linger=0, only 7 sockets are in use but ~770 MB of TCP
> memory has no owner. With l_linger=1, 50,008 sockets are in use
> but only ~56 MB of memory.
Both 'inuse' and 'alloc' show the number of TCP sockets, but
'inuse' is per-netns while 'alloc' is global. 'mem' is also a global
counter.
I'm not sure if you saw the result from the wrong netns.
For example, I can see your l_linger=0 like result by:
# ip netns add test
# ip netns exec test cat /proc/net/sockstat
sockets: used 0
TCP: inuse 0 orphan 0 tw 0 alloc 50009 mem 13078
And if you see the counters drop close to 0 after killing
the process, the "leaked" counter should be tracked properly
somewhere else.
^ permalink raw reply
* Re: [PATCH net v2] netdevsim: zero initialize struct iphdr in dummy sk_buff
From: patchwork-bot+netdevbpf @ 2026-04-28 0:30 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <20260426201434.742030-1-zlatistiv@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 26 Apr 2026 23:14:34 +0300 you wrote:
> Syzbot reports a KMSAN uninit-value originating from
> nsim_dev_trap_skb_build, with the allocation also
> being performed in the same function.
>
> Fix this by calling skb_put_zero instead of skb_put to
> guarantee zero initialization of the whole IP header.
>
> [...]
Here is the summary with links:
- [net,v2] netdevsim: zero initialize struct iphdr in dummy sk_buff
https://git.kernel.org/netdev/net/c/35eaa6d8d6c2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit()
From: Jakub Kicinski @ 2026-04-28 0:39 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <aezLa2POvT0It5AA@lore-desk>
On Sat, 25 Apr 2026 16:10:51 +0200 Lorenzo Bianconi wrote:
> - Does the TSO checksum calculation earlier in this function ensure the
> TCP header is in the linear portion of the SKB?
> This issue is not related to the current patch. Moreover, can we have a TSO
> packet where the tcp header is not in the linear area of the skb?
Don't think so.
> - If dma_map_single() fails partway through a multi-fragment packet and
> triggers this goto error_unmap, will it break the Tx ring contiguity?
> This issue is not related to the current patch. Moreover, I guess the hw is
> capable of managing out-of-order descriptors.
>
> - Is it safe to map fragment data using dma_map_single() instead of
> skb_frag_dma_map()?
> This issue is not related to the current patch. I will post a dedicated patch
> for it.
I don't think it's an issue. Unless you support DMABUF zero-copy
the skb_frag helper is just for convenience. I wouldn't bother.
^ permalink raw reply
* Re: [PATCH v8 net 0/6] netem: bug fixes
From: patchwork-bot+netdevbpf @ 2026-04-28 0:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, jiri, jhs, horms
In-Reply-To: <20260418032027.900913-1-stephen@networkplumber.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 17 Apr 2026 20:19:38 -0700 you wrote:
> These bugs were found when doing AI-assisted review of sch_netem.c
> during investigation of the packet duplication recursion problem
> addressed in Jamal's series.
>
> The fixes cover:
>
> - probability gaps in the 4-state Markov loss model
> - queue limit not accounting for reordered packets
> - PRNG reseeded on every tc change, breaking reproducibility
> - slot configuration not validated (inverted ranges, negative
> delays, negative limits)
> - slot delay arithmetic overflow for ranges above ~2.1 seconds
> - negative latency and jitter wrapping to huge time_to_send
> values via u64 arithmetic
>
> [...]
Here is the summary with links:
- [net,v8,1/6] net/sched: netem: fix probability gaps in 4-state loss model
https://git.kernel.org/netdev/net/c/732b463449fd
- [net,v8,2/6] net/sched: netem: fix queue limit check to include reordered packets
https://git.kernel.org/netdev/net/c/4185701fcce6
- [net,v8,3/6] net/sched: netem: only reseed PRNG when seed is explicitly provided
https://git.kernel.org/netdev/net/c/986afaf80994
- [net,v8,4/6] net/sched: netem: validate slot configuration
https://git.kernel.org/netdev/net/c/01801c359a74
- [net,v8,5/6] net/sched: netem: fix slot delay calculation overflow
https://git.kernel.org/netdev/net/c/51e94e1e2fef
- [net,v8,6/6] net/sched: netem: check for negative latency and jitter
https://git.kernel.org/netdev/net/c/90be9fedb218
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] vrf: Fix a potential NPD when removing a port from a VRF
From: patchwork-bot+netdevbpf @ 2026-04-28 0:50 UTC (permalink / raw)
To: Ido Schimmel
Cc: netdev, davem, kuba, pabeni, edumazet, dsahern, jiri,
andrew+netdev, royenheart, yifanwucs, tomapufckgml, yuantan098
In-Reply-To: <20260423063607.1208202-1-idosch@nvidia.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 23 Apr 2026 09:36:07 +0300 you wrote:
> RCU readers that identified a net device as a VRF port using
> netif_is_l3_slave() assume that a subsequent call to
> netdev_master_upper_dev_get_rcu() will return a VRF device. They then
> continue to dereference its l3mdev operations.
>
> This assumption is not always correct and can result in a NPD [1]. There
> is no RCU synchronization when removing a port from a VRF, so it is
> possible for an RCU reader to see a new master device (e.g., a bridge)
> that does not have l3mdev operations.
>
> [...]
Here is the summary with links:
- [net] vrf: Fix a potential NPD when removing a port from a VRF
https://git.kernel.org/netdev/net/c/2674d603a9e6
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit()
From: patchwork-bot+netdevbpf @ 2026-04-28 0:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260424-airoha-xmit-fix-read-frag-v1-1-fdc0a83c79e8@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 24 Apr 2026 11:00:28 +0200 you wrote:
> The transmit loop in airoha_dev_xmit() reads fragment address and length
> during its final iteration, when the loop index equals
> skb_shinfo(skb)->nr_frags, at which point the fragment data is
> uninitialized. While these values are never consumed, the read itself is
> unsafe and may trigger a page fault. Fix this by avoiding the fragment
> read on the last iteration.
> Additionally, move the skb pointer from the first to the last used packet
> descriptor, so that airoha_qdma_tx_napi_poll() defers freeing the skb
> until the final descriptor is processed.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit()
https://git.kernel.org/netdev/net/c/bde34e84edc8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: patchwork-bot+netdevbpf @ 2026-04-28 0:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-wake_netdev_txqs-optmization-v1-1-e0be95115d53@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 21 Apr 2026 10:53:33 +0200 you wrote:
> Do not wake every netdev TX queue across all ports sharing the QDMA
> running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs()
> but only the ones that are mapped the specific QDMA stopped hw TX queue.
> This patch can potentially avoid waking already stopped netdev TX queues
> that are mapped to a different QDMA hw TX queue.
> Introduce airoha_qdma_get_txq utility routine.
>
> [...]
Here is the summary with links:
- [net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
https://git.kernel.org/netdev/net/c/e070aac63b42
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: stop net_device TX queue before updating CPU index
From: patchwork-bot+netdevbpf @ 2026-04-28 0:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-xmit-stop-condition-v1-1-e670d6a48467@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 21 Apr 2026 08:43:07 +0200 you wrote:
> Currently, airoha_eth driver updates the CPU index register prior of
> verifying whether the number of free descriptors has fallen below the
> threshold.
> Move net_device TX queue length check before updating the TX CPU index
> in order to update TX CPU index even if there are more packets to be
> transmitted but the net_device TX queue is going to be stopped
> accounting the inflight packets.
>
> [...]
Here is the summary with links:
- [net] net: airoha: stop net_device TX queue before updating CPU index
https://git.kernel.org/netdev/net/c/3854de7b38be
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: fix BQL imbalance in TX path
From: patchwork-bot+netdevbpf @ 2026-04-28 0:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, hkelam, horms,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260421-airoha-fix-bql-v1-1-f135afe4275b@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 21 Apr 2026 08:35:11 +0200 you wrote:
> Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight
> packets are accounted only for the AIROHA_NUM_TX_RING netdev TX
> queues. The queue index is computed as:
>
> qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx)
> txq = netdev_get_tx_queue(dev, qid);
>
> [...]
Here is the summary with links:
- [net] net: airoha: fix BQL imbalance in TX path
https://git.kernel.org/netdev/net/c/2d9f5a118205
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net/sched: sch_choke: annotate data-races in choke_dump_stats()
From: patchwork-bot+netdevbpf @ 2026-04-28 0:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260423062839.2524324-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 23 Apr 2026 06:28:39 +0000 you wrote:
> choke_dump_stats() only runs with RTNL held.
> It reads fields that can be changed in qdisc fast path.
> Add READ_ONCE()/WRITE_ONCE() annotations.
>
> Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
>
> [...]
Here is the summary with links:
- [net] net/sched: sch_choke: annotate data-races in choke_dump_stats()
https://git.kernel.org/netdev/net/c/d3aeb889dcbd
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats()
From: patchwork-bot+netdevbpf @ 2026-04-28 0:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260423063527.2568262-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 23 Apr 2026 06:35:27 +0000 you wrote:
> fq_codel_dump_stats() acquires the qdisc spinlock a bit too late.
>
> Move this acquisition before we fill tc_fq_pie_xstats with live data.
>
> Alternative would be to add READ_ONCE() and WRITE_ONCE() annotations,
> but the spinlock is needed anyway to scan q->new_flows and q->old_flows.
>
> [...]
Here is the summary with links:
- [net] net/sched: sch_fq_pie: annotate data-races in fq_pie_dump_stats()
https://git.kernel.org/netdev/net/c/59b145771c79
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: phonet: fix BUG_ON() in pn_socket_autobind()
From: Jakub Kicinski @ 2026-04-28 0:54 UTC (permalink / raw)
To: kartikey406
Cc: Jakub Kicinski, pabeni, netdev, syzbot+706f5eb79044e686c794,
horms, linux-kernel, edumazet, davem, courmisch
In-Reply-To: <20260422021533.16987-1-kartikey406@gmail.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: phonet: fix BUG_ON() in pn_socket_autobind()
This commit fixes a kernel crash in pn_socket_autobind() by checking
the socket's bound state directly before calling pn_socket_bind(),
eliminating ambiguous -EINVAL interpretation.
Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794
> pn_socket_autobind() calls pn_socket_bind() and treats
> -EINVAL as a signal that the socket was already bound,
> then uses BUG_ON() to verify it:
>
> if (err != -EINVAL)
> return err;
> BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
>
> However, pn_socket_bind() returns -EINVAL in multiple
> cases:
>
> 1. address length too short
The commit message lists "address length too short" as a cause of the
BUG_ON crash, but is this accurate?
Looking at pn_socket_autobind(), it always passes
len=sizeof(struct sockaddr_pn) to pn_socket_bind():
err = pn_socket_bind(sock, (struct sockaddr_unsized *)&sa,
sizeof(struct sockaddr_pn));
While pn_socket_bind() does have this check:
if (len < sizeof(struct sockaddr_pn))
return -EINVAL;
This case cannot be triggered through pn_socket_autobind() since it
always passes the correct length. The BUG_ON is only reachable through
pn_socket_autobind(), so listing this as a cause seems misleading.
Should the commit message be updated to remove case 1, or clarify that
it's describing pn_socket_bind() in general rather than paths that can
trigger the BUG_ON?
> 2. socket not in TCP_CLOSE state
Can case 2 (socket not in TCP_CLOSE state) actually trigger the BUG_ON
crash with sobject still zero?
The combined check in pn_socket_bind() is:
if (sk->sk_state != TCP_CLOSE || pn_port(pn->sobject)) {
err = -EINVAL;
goto out;
}
For the BUG_ON to fire, we need sk_state != TCP_CLOSE while sobject
remains zero (unbound). Looking at phonet state transitions:
- pn_socket_connect() binds the socket before changing state
- pn_socket_listen() binds the socket before changing state
- pep_sock_accept() creates sockets with state=TCP_SYN_RECV but also
sets sobject
- pep_ioctl(SIOCPNENABLEPIPE) checks sobject before changing state
Is there a code path that changes sk_state to non-TCP_CLOSE without
first binding the socket? The syzbot crash is real, but the mechanism
described couldn't be verified. Could this involve a race condition or
a different code path?
> 3. socket already bound <- only intended case
>
> When -EINVAL comes from cases 1 or 2, sobject is still
> zero (never assigned), causing BUG_ON to fire and crash
> the kernel.
Given the issues with cases 1 and 2 above, is the explanation of the
crash mechanism accurate? Case 1 cannot happen from pn_socket_autobind(),
and case 2's ability to leave sobject at zero while triggering -EINVAL
could not be verified.
The syzbot crash is confirmed (RIP at pn_socket_autobind
net/phonet/socket.c:213 via pn_socket_sendmsg), but could the commit
message more accurately describe how the crash actually occurs?
> diff --git a/net/phonet/socket.c b/net/phonet/socket.c
> index c4af26357144..5a55e7d14e85 100644
> --- a/net/phonet/socket.c
> +++ b/net/phonet/socket.c
> @@ -204,14 +204,14 @@ static int pn_socket_autobind(struct socket *sock)
> struct sockaddr_pn sa;
> int err;
>
> + if (pn_port(pn_sk(sock->sk)->sobject))
> + return 0; /* socket was already bound */
> +
> memset(&sa, 0, sizeof(sa));
> sa.spn_family = AF_PHONET;
> err = pn_socket_bind(sock, (struct sockaddr_unsized *)&sa,
> sizeof(struct sockaddr_pn));
> - if (err != -EINVAL)
> - return err;
> - BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
> - return 0; /* socket was already bound */
> + return err;
> }
The fix itself is correct and removes the dangerous BUG_ON(). However,
the pn_port(sobject) check is performed without holding any lock. Could
a concurrent pn_socket_bind() race with this check? This is likely
benign since pn_socket_bind() re-checks under lock_sock(), but is this
the intended behavior?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: atheros: atl1e: use atomic functions with memory barriers for next_to_clean
From: Jakub Kicinski @ 2026-04-28 0:59 UTC (permalink / raw)
To: Gui-Dong Han
Cc: Chris Snook, Andrew Lunn, David S . Miller, Eric Dumazet,
Paolo Abeni, netdev, linux-kernel, baijiaju1990
In-Reply-To: <20260422093717.893646-1-hanguidong02@gmail.com>
On Wed, 22 Apr 2026 17:37:17 +0800 Gui-Dong Han wrote:
> Found by auditing atomic operations used for synchronization.
> A similar fix can be found in 6df8e84aa6b5.
>
> Do not change atl1e_init_ring_ptrs(). Its atomic_set() runs during
> bring-up before NAPI and interrupts are enabled, so it is not a runtime
> publication point between Tx cleanup and Tx submission.
>
> In my opinion, implementing ad-hoc lockless algorithms directly within
> individual drivers is highly error-prone. To avoid these subtle memory
> ordering and barrier bugs, drivers should rely on established, well-tested
> kernel libraries like kfifo to handle this type of concurrency.
I don't think this is sufficient, we can still race stop vs wake.
Please convert the driver to use netif_txq_maybe_stop() and friends.
--
pw-bot: cr
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: ptp: serialize E825 PHY timer start with PTP lock
From: Nowlin, Alexander @ 2026-04-28 0:59 UTC (permalink / raw)
To: Nitka, Grzegorz, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Kubalewski, Arkadiusz, Nguyen, Anthony L,
Kitszel, Przemyslaw
In-Reply-To: <20260422123144.485930-2-grzegorz.nitka@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Grzegorz Nitka
> Sent: Wednesday, April 22, 2026 5:32 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 1/2] ice: ptp: serialize E825 PHY timer start with PTP lock
>
> ice_start_phy_timer_eth56g() programs TIMETUS registers and issues INIT_INCVAL without holding the > global PTP semaphore.
>
> This allows concurrent PTP command paths to interleave with PHY timer start, which can make the
> sequence fail and leave timer initialization inconsistent.
>
> Take the PTP lock around TIMETUS registers programming and INIT_INCVAL command execution, and
> make sure the lock is released on all error paths.
>
> Keep the subsequent sync step outside of this critical section, since
> ice_sync_phy_timer_eth56g() takes the same semaphore internally.
>
> Fixes: 7cab44f1c35f ("ice: Introduce ETH56G PHY model for E825C products")
> Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 2/2] ice: ptp: use primary NAC semaphore on E825
From: Nowlin, Alexander @ 2026-04-28 1:00 UTC (permalink / raw)
To: Nitka, Grzegorz, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Kubalewski, Arkadiusz, Nguyen, Anthony L,
Kitszel, Przemyslaw
In-Reply-To: <20260422123144.485930-3-grzegorz.nitka@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Grzegorz Nitka
> Sent: Wednesday, April 22, 2026 5:32 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Kubalewski, Arkadiusz <arkadiusz.kubalewski@intel.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net 2/2] ice: ptp: use primary NAC semaphore on E825
>
> For E825 2xNAC configurations, PTP semaphore operations must hit the primary NAC register block so both sides coordinate on the same lock.
>
> Commit e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825
> devices") updated other primary-only PTP register accesses to use the primary NAC on non-primary functions, but left ice_ptp_lock() and ice_ptp_unlock() operating on the local NAC. As a result, secondary NAC > PTP paths can take a different semaphore than the primary side.
>
> Select the primary hardware in ice_ptp_lock() and ice_ptp_unlock() when the current function is not primary, keeping semaphore operations symmetric and consistent with the rest of the 2xNAC PTP register
> access path.
>
> Fixes: e2193f9f9ec9 ("ice: enable timesync operation on 2xNAC E825 devices")
> Reviewed-by: Arkadiusz Kubalewski <Arkadiusz.kubalewski@intel.com>
> Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* Re: [PATCH] net: ethernet: rnpgbe: mark nonfunctional incomplete driver as BROKEN
From: Ethan Nelson-Moore @ 2026-04-28 1:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, stable, Yibo Dong, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Vadim Fedorenko, MD Danish Anwar
In-Reply-To: <20260427165959.3a294f1a@kernel.org>
Hi, Jakub,
On Mon, Apr 27, 2026 at 5:00 PM Jakub Kicinski <kuba@kernel.org> wrote:
> We can keep the vendor as is, this doesn't enable any code compilation
I disabled it because otherwise an option for Mucse devices which
cannot be opened appears in menuconfig, which is confusing.
Ethan
^ permalink raw reply
* Re: [PATCH net v3] ipv6: rpl: reserve mac_len headroom when recompressed SRH grows
From: patchwork-bot+netdevbpf @ 2026-04-28 1:10 UTC (permalink / raw)
To: Greg KH
Cc: netdev, linux-kernel, davem, dsahern, edumazet, kuba, pabeni,
horms, stable
In-Reply-To: <2026042133-gout-unvented-1bd9@gregkh>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 21 Apr 2026 15:16:33 +0200 you wrote:
> ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps
> the next segment into ipv6_hdr->daddr, recompresses, then pulls the old
> header and pushes the new one plus the IPv6 header back. The
> recompressed header can be larger than the received one when the swap
> reduces the common-prefix length the segments share with daddr (CmprI=0,
> CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).
>
> [...]
Here is the summary with links:
- [net,v3] ipv6: rpl: reserve mac_len headroom when recompressed SRH grows
https://git.kernel.org/netdev/net/c/9e6bf146b559
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] NFC: trf7970a: Ignore antenna noise when checking for RF field
From: patchwork-bot+netdevbpf @ 2026-04-28 1:10 UTC (permalink / raw)
To: Paul Geurts
Cc: mgreer, sameo, linux-wireless, netdev, linux-kernel,
martijn.de.gouw
In-Reply-To: <20260422100930.581237-1-paul.geurts@prodrive-technologies.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 22 Apr 2026 12:09:30 +0200 you 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.
>
> [...]
Here is the summary with links:
- NFC: trf7970a: Ignore antenna noise when checking for RF field
https://git.kernel.org/netdev/net/c/a9bc28aa4e64
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