* Re: [PATCH net-next v3 1/4] net: eth: fbnic: Fix addr validation in pcs write
From: Jakub Kicinski @ 2026-05-07 1:58 UTC (permalink / raw)
To: Paolo Abeni
Cc: mike.marciniszyn, Alexander Duyck, kernel-team, Andrew Lunn,
David S. Miller, Eric Dumazet, Heiner Kallweit, Russell King,
Jacob Keller, Mohsin Bashir, Simon Horman, Lee Trager,
Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260504135815.44226-2-mike.marciniszyn@gmail.com>
On Mon, 4 May 2026 09:58:12 -0400 mike.marciniszyn@gmail.com wrote:
> From: "Mike Marciniszyn (Meta)" <mike.marciniszyn@gmail.com>
>
> The DW IP has two distinct PCS address ranges cooresponding
> to the C45 PCS registers.
>
> The shim translates the PCS addr/regno into specific CSR writes
> into one of those two zero-relative.
>
> This patch fixes a one off in the test that could allow an invalid
> CSR write if an addr == 2 was called.
>
> This patch contains a fix for addr validation in fbnic_mdio_write_pcs()
> to only return actual CSR reads for addr 0 and 1.
>
> There are as of yet, no real impact for the bug as no PCS writes are
> not yet present.
Hi Paolo! Was there a reason / do you recall why this was not applied?
(I dropped it from patchwork now. If the omission was accidental it has
to be reposted)
^ permalink raw reply
* Re: [PATCH net] tipc: avoid sending zero-length stream messages
From: Cássio Gabriel Monteiro Pires @ 2026-05-07 1:52 UTC (permalink / raw)
To: Tung Quang Nguyen
Cc: netdev@vger.kernel.org, tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
syzbot+aa7d098bd6fa788fae8e@syzkaller.appspotmail.com, Jon Maloy,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
In-Reply-To: <GV1P189MB1988FEBC4D7BA3F00E210774C63F2@GV1P189MB1988.EURP189.PROD.OUTLOOK.COM>
[-- Attachment #1.1.1: Type: text/plain, Size: 5504 bytes --]
Hi!
On 5/6/26 03:41, Tung Quang Nguyen wrote:
>> Subject: [PATCH net] tipc: avoid sending zero-length stream messages
>>
>> TIPC stream send currently enters the transmit loop even when the user
>> payload length is zero. This can build and transmit a header-only connection
>> message.
>>
>> For local TIPC sockets, such messages are delivered synchronously through the
>> loopback receive path. When this happens while socket backlog processing is
>> being flushed, reply transmission can re-enter TIPC receive processing
>> repeatedly and trigger an RCU stall.
>>
> Can you demonstrate this scenario using code ? It is better to point out what current code is faulty.
The minimized user-visible trigger is essentially:
int fd[2];
struct msghdr msg = {};
socketpair(AF_TIPC, SOCK_STREAM, 0, fd);
/* In parallel, this makes release_sock() flush backlog. */
setsockopt(fd[0], SOL_SOCKET, SO_ATTACH_BPF, &bad_fd,
sizeof(bad_fd));
/* Repeated zero-length MSG_PROBE send on the connected peer. */
for (i = 0; i < 64; i++)
sendmsg(fd[1], &msg, MSG_PROBE | MSG_MORE);
The faulty current-code path is that TIPC stream send does not handle
MSG_PROBE before entering __tipc_sendstream(). MSG_PROBE is supposed to
probe without transmitting data, but the call reaches __tipc_sendstream()
with dlen == 0.
__tipc_sendstream() uses a do/while loop, so even when dlen is 0 the body
runs once:
send = min_t(size_t, dlen - sent, TIPC_MAX_USER_MSG_SIZE);
At that point send is 0, but the code can still call tipc_msg_append() or
tipc_msg_build(), creating a TIPC connection message with only the header.
It then calls:
tipc_node_xmit(net, txq, dnode, tsk->portid);
For a local TIPC socketpair, tipc_node_xmit() takes the in_own_node() path
and synchronously calls tipc_sk_rcv(). When this happens while
release_sock() is processing backlog, the receive path can generate
response traffic through tipc_node_distr_xmit(), which re-enters the same
local receive path.
I should have made that explicit in the changelog and pointed at the
missing MSG_PROBE handling as the faulty part.
>>
>> diff --git a/net/tipc/socket.c b/net/tipc/socket.c index
>> 9329919fb07f..3c7838713d74 100644
>> --- a/net/tipc/socket.c
>> +++ b/net/tipc/socket.c
>> @@ -1585,6 +1585,8 @@ static int __tipc_sendstream(struct socket *sock,
>> struct msghdr *m, size_t dlen)
>> tipc_sk_connected(sk)));
>> if (unlikely(rc))
>> break;
>> + if (unlikely(!dlen && sk->sk_type == SOCK_STREAM))
>> + break;
> This change is wrong. It immediately breaks normal connection set up because the ACK (zero in length) has no chance to be sent back from the server to the client.
> Please try to test your patch before submission.
I did test the patch with the syzkaller C repro under QEMU for 10 minutes, and
it did not trigger the reported RCU stall:
/tmp/repro & pid=$!; sleep 600; kill $pid
dmesg | grep -Ei 'rcu.*stall|rcu_preempt|soft lockup|panic|BUG|WARNING' (attached)
The dmesg check did not show any repro-triggered RCU stall, soft lockup,
panic, BUG, or WARNING. But that test only covered the syzkaller trigger;
it did not cover normal active/passive TIPC stream connection setup, which
your review points out is broken by this version.
I re-checked the TIPC connection setup path as well.
tipc_accept() intentionally sends the server-side ACK as a zero-length
stream message:
iov_iter_kvec(&m.msg_iter, ITER_SOURCE, NULL, 0, 0);
__tipc_sendstream(new_sock, &m, 0);
So blocking all zero-length sends inside __tipc_sendstream() prevents
that ACK from being transmitted and can break normal SOCK_STREAM
connection setup.
After re-checking the syzkaller repro, the real trigger seems to be narrower
than zero-length stream send. The repro uses a user sendmsg() with
MSG_PROBE | MSG_MORE and no payload on an already connected TIPC stream
socket. MSG_PROBE is supposed to probe without sending, but TIPC stream
send currently lets that path reach __tipc_sendstream(), where the
do/while body can still run once with dlen == 0 and build/transmit a
header-only message.
I think we should avoid suppressing the internal __tipc_sendstream() ACK path
and instead handle the user-originated zero-length MSG_PROBE case before it
reaches the internal stream send helper.
The v2 fix would look like this:
-- 8< --
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 9329919fb07f..4783df337971 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1542,6 +1542,10 @@ static int tipc_sendstream(struct socket *sock, struct msghdr *m, size_t dsz)
struct sock *sk = sock->sk;
int ret;
+ /* MSG_PROBE asks only to probe the path, not to transmit data. */
+ if (unlikely((m->msg_flags & MSG_PROBE) && !dsz))
+ return 0;
+
lock_sock(sk);
ret = __tipc_sendstream(sock, m, dsz);
release_sock(sk);
-- >8 --
I tested the reworked patch with the syzkaller C reproducer under QEMU.
The reproducer was run for 10 minutes:
/tmp/repro & pid=$!; sleep 600; kill $pid
dmesg | grep -Ei 'rcu.*stall|rcu_preempt|soft lockup|panic|BUG|WARNING' (attached)
The grep only matched boot-time command-line/debug messages; no
repro-triggered RCU stall, soft lockup, panic, BUG, or WARNING appeared.
What you think?
[-- Attachment #1.1.2: patch_v1_test_log.txt --]
[-- Type: text/plain, Size: 2365 bytes --]
# dmesg | grep -Ei 'rcu.*stall|rcu_preempt|soft lockup|panic|BUG|WARNING'
[ 0.000000][ T0] net.ifnames=0 panic_on_warn=1
[ 0.000000][ T0] Kernel command line: earlyprintk=serial net.ifnames=0 sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000 nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000 nf-conntrack-sane.ports=20000 binder.debug_mask=0 rcupdate.rcu_expedited=1 rcupdate.rcu_cpu_stall_cputime=1 no_hash_pointers page_owner=on sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4 secretmem.enable=1 sysctl.max_rcu_stall_to_panic=1 msr.allow_writes=off coredump_filter=0xffff root=/dev/sda console=ttyS0 vsyscall=native numa=fake=2 kvm-intel.nested=1 spec_store_bypass_disable=prctl nopcid vivid.n_devs=64 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 netrom.nr_ndevs=32 rose.rose_ndevs=32 smp.csd_lock_timeout=100000 watchdog_thresh=55 workqueue.watchdog_thresh=140 sysctl.net.core.netdev_unregister_timeout_secs=140 dummy_hcd.num=32 max_loop=32 nbds_max=32 \
[ 0.000000][ T0] Kernel command line: comedi.comedi_num_legacy_minors=4 panic_on_warn=1 console=ttyS0 root=/dev/vda1 rootfstype=ext4 rw earlyprintk=serial
[ 0.000000][ T0] net.ifnames=0 panic_on_warn=1
[ 0.000000][ T0] ** If you see this message and you are not debugging **
[ 0.000000][ T0] rcu: RCU callback double-/use-after-free debug is enabled.
[ 0.000000][ T0] rcu: RCU debug extended QS entry/exit.
[ 10.704615][ T1] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 21.826838][ T1] orangefs_debugfs_init: called with debug mask: :none: :0:
[ 22.032237][ T1] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
[ 77.296497][ T1] usbcore: registered new interface driver usb_debug
[ 77.309604][ T1] usbserial: USB Serial support registered for debug
[ 114.238149][ T1] pvrusb2: Debug mask is 31 (0x1f)
[ 181.100641][ T1] debug_vm_pgtable: [debug_vm_pgtable ]: Validating architecture page table helpers
[ 201.556741][ T1] Failed to set sysctl parameter 'max_rcu_stall_to_panic=1': parameter not found
[1]+ Terminated /tmp/repro
[-- Attachment #1.1.3: patch_v2_test_log.txt --]
[-- Type: text/plain, Size: 2419 bytes --]
# dmesg | grep -Ei 'rcu.*stall|rcu_preempt|soft lockup|panic|BUG|WARNING'
[ 0.000000][ T0] Command line: console=ttyS0 root=/dev/vda1 rootfstype=ext4 rw earlyprintk=serial net.ifnames=0 panic_on_warn=1
[ 1.462430][ T0] Kernel command line: earlyprintk=serial net.ifnames=0 sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000 nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000 nf-conntrack-sane.ports=20000 binder.debug_mask=0 rcupdate.rcu_expedited=1 rcupdate.rcu_cpu_stall_cputime=1 no_hash_pointers page_owner=on sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4 secretmem.enable=1 sysctl.max_rcu_stall_to_panic=1 msr.allow_writes=off coredump_filter=0xffff root=/dev/sda console=ttyS0 vsyscall=native numa=fake=2 kvm-intel.nested=1 spec_store_bypass_disable=prctl nopcid vivid.n_devs=64 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 netrom.nr_ndevs=32 rose.rose_ndevs=32 smp.csd_lock_timeout=100000 watchdog_thresh=55 workqueue.watchdog_thresh=140 sysctl.net.core.netdev_unregister_timeout_secs=140 dummy_hcd.num=32 max_loop=32 nbds_max=32 \
[ 1.470761][ T0] Kernel command line: comedi.comedi_num_legacy_minors=4 panic_on_warn=1 console=ttyS0 root=/dev/vda1 rootfstype=ext4 rw earlyprintk=serial net.ifnames=0 panic_on_warn=1
[ 3.155914][ T0] ** If you see this message and you are not debugging **
[ 3.813298][ T0] rcu: RCU callback double-/use-after-free debug is enabled.
[ 3.814645][ T0] rcu: RCU debug extended QS entry/exit.
[ 17.096163][ T1] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 28.566521][ T1] orangefs_debugfs_init: called with debug mask: :none: :0:
[ 28.796190][ T1] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled
[ 84.486523][ T1] usbcore: registered new interface driver usb_debug
[ 84.504286][ T1] usbserial: USB Serial support registered for debug
[ 114.419251][ T1] pvrusb2: Debug mask is 31 (0x1f)
[ 179.396180][ T1] debug_vm_pgtable: [debug_vm_pgtable ]: Validating architecture page table helpers
[ 185.907359][ T1] Failed to set sysctl parameter 'max_rcu_stall_to_panic=1': parameter not found
[1]+ Terminated /tmp/repro
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply related
* Re: [PATCH net-next V3 0/5] net/mlx5e: Report more netdev stats
From: patchwork-bot+netdevbpf @ 2026-05-07 1:50 UTC (permalink / raw)
To: Tariq Toukan
Cc: edumazet, kuba, pabeni, andrew+netdev, davem, saeedm, mbloch,
leon, netdev, linux-rdma, linux-kernel, gal, dtatulea
In-Reply-To: <20260504183704.272322-1-tariqt@nvidia.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 4 May 2026 21:36:59 +0300 you wrote:
> Hi,
>
> This series by Gal extends the set of counters reported in netdev stats,
> by adding:
> - hw_gso_packets/bytes
> - RX HW-GRO stats
> - TX csum_none
> - TX queue stop/wake
>
> [...]
Here is the summary with links:
- [net-next,V3,1/5] net/mlx5e: Count full skb length in TSO byte counters
https://git.kernel.org/netdev/net-next/c/de58db5f0d95
- [net-next,V3,2/5] net/mlx5e: Report hw_gso_packets and hw_gso_bytes netdev stats
https://git.kernel.org/netdev/net-next/c/38e7e4a209c2
- [net-next,V3,3/5] net/mlx5e: Report RX HW-GRO netdev stats
https://git.kernel.org/netdev/net-next/c/97b96c3b47d1
- [net-next,V3,4/5] net/mlx5e: Report TX csum_none netdev stat
https://git.kernel.org/netdev/net-next/c/d8e5b2f7a5c3
- [net-next,V3,5/5] net/mlx5e: Report stop and wake TX queue stats
https://git.kernel.org/netdev/net-next/c/32b7e50e284a
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 v1 bpf] bpf: Free reuseport cBPF prog after RCU grace period.
From: kernel test robot @ 2026-05-07 1:40 UTC (permalink / raw)
To: Kuniyuki Iwashima, Martin KaFai Lau, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi
Cc: llvm, oe-kbuild-all, Kuniyuki Iwashima, bpf, netdev, Eulgyu Kim
In-Reply-To: <20260424235247.1990272-1-kuniyu@google.com>
Hi Kuniyuki,
kernel test robot noticed the following build errors:
[auto build test ERROR on bpf/master]
url: https://github.com/intel-lab-lkp/linux/commits/Kuniyuki-Iwashima/bpf-Free-reuseport-cBPF-prog-after-RCU-grace-period/20260425-093050
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git master
patch link: https://lore.kernel.org/r/20260424235247.1990272-1-kuniyu%40google.com
patch subject: [PATCH v1 bpf] bpf: Free reuseport cBPF prog after RCU grace period.
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260507/202605070321.vVxQf7dU-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260507/202605070321.vVxQf7dU-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605070321.vVxQf7dU-lkp@intel.com/
All errors (new ones prefixed by >>):
>> net/core/filter.c:1666:6: error: conflicting types for 'sk_reuseport_prog_free'
1666 | void sk_reuseport_prog_free(struct bpf_prog *prog, bool wait_rcu)
| ^
include/linux/filter.h:1146:6: note: previous declaration is here
1146 | void sk_reuseport_prog_free(struct bpf_prog *prog);
| ^
1 error generated.
vim +/sk_reuseport_prog_free +1666 net/core/filter.c
1665
> 1666 void sk_reuseport_prog_free(struct bpf_prog *prog, bool wait_rcu)
1667 {
1668 if (!prog)
1669 return;
1670
1671 if (bpf_prog_was_classic(prog))
1672 call_rcu(&prog->aux->rcu, sk_reuseport_prog_free_rcu);
1673 else
1674 bpf_prog_put(prog);
1675 }
1676
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dpll: add fractional frequency offset to pin-parent-device
From: Jakub Kicinski @ 2026-05-07 1:33 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Jiri Pirko, Andrew Lunn, Arkadiusz Kubalewski,
David S. Miller, Donald Hunter, Eric Dumazet, 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: <20260504155340.411063-2-ivecera@redhat.com>
On Mon, 4 May 2026 17:53:39 +0200 Ivan Vecera wrote:
> + At top level this represents the RX vs TX symbol rate
> + offset on the media associated with the pin.
Isn't this a hacky hack? I'd think that pin is in or out.
Having a freq offset between two pins or pin and parent's
ref lock makes sense. This new interpretation sounds like
we are trying to shove a difference between two pins into one?
> @@ -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;
It's easy for driver authors to forget this sort of validation.
We should fail close, so it's better to have some "capability"
bits or something for the driver to opt into getting given format
of the call.
^ permalink raw reply
* Re: [PATCH net] tcp: tcp_child_process() related UAF
From: patchwork-bot+netdevbpf @ 2026-05-07 1:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, ncardwell, kuniyu, netdev,
eric.dumazet, melotti
In-Reply-To: <20260505153927.3435532-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 5 May 2026 15:39:27 +0000 you wrote:
> tcp_child_process( .. child ...) currently calls sock_put(child).
>
> Unfortunately @child (named @nsk in callers) can be used after
> this point to send a RST packet.
>
> To fix this UAF, I remove the sock_put() from tcp_child_process()
> and let the callers handle this after it is safe.
>
> [...]
Here is the summary with links:
- [net] tcp: tcp_child_process() related UAF
https://git.kernel.org/netdev/net/c/c8f7244c8ccc
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 00/11] mptcp: pm: misc. fixes for v7.1-rc3
From: patchwork-bot+netdevbpf @ 2026-05-07 1:30 UTC (permalink / raw)
To: Matthieu Baerts
Cc: martineau, geliang, davem, edumazet, kuba, pabeni, horms, cpaasch,
netdev, mptcp, linux-kernel, stable, shuah, linux-kselftest
In-Reply-To: <20260505-net-mptcp-pm-fixes-7-1-rc3-v1-0-fca8091060a4@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 05 May 2026 17:00:48 +0200 you wrote:
> Here are various fixes, mainly related to ADD_ADDRs:
>
> - Patch 1: save ADD_ADDR for rtx with ID0 when needed. A fix for v6.1.
>
> - Patch 2: remove unneeded exception for ID 0. A fix for v5.10.
>
> - Patches 3-5: fix potential data-race and leaks during ADD_ADDR rtx. A
> fix for v5.10.
>
> [...]
Here is the summary with links:
- [net,01/11] mptcp: pm: kernel: correctly retransmit ADD_ADDR ID 0
https://git.kernel.org/netdev/net/c/b12014d2d36e
- [net,02/11] mptcp: pm: ADD_ADDR rtx: allow ID 0
https://git.kernel.org/netdev/net/c/03f324f3f1f7
- [net,03/11] mptcp: pm: ADD_ADDR rtx: fix potential data-race
https://git.kernel.org/netdev/net/c/5cd6e0ad79d2
- [net,04/11] mptcp: pm: ADD_ADDR rtx: always decrease sk refcount
https://git.kernel.org/netdev/net/c/9634cb35af17
- [net,05/11] mptcp: pm: ADD_ADDR rtx: free sk if last
https://git.kernel.org/netdev/net/c/b7b9a4615697
- [net,06/11] mptcp: pm: ADD_ADDR rtx: resched blocked ADD_ADDR quicker
https://git.kernel.org/netdev/net/c/3cf12492891c
- [net,07/11] mptcp: pm: ADD_ADDR rtx: skip inactive subflows
https://git.kernel.org/netdev/net/c/c6d395e2de13
- [net,08/11] mptcp: pm: ADD_ADDR rtx: return early if no retrans
https://git.kernel.org/netdev/net/c/62a9b19dce77
- [net,09/11] mptcp: pm: prio: skip closed subflows
https://git.kernel.org/netdev/net/c/166b78344031
- [net,10/11] selftests: mptcp: check output: catch cmd errors
https://git.kernel.org/netdev/net/c/65db7b27b90e
- [net,11/11] selftests: mptcp: pm: restrict 'unknown' check to pm_nl_ctl
https://git.kernel.org/netdev/net/c/53705ddfa184
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 3/3] net: dsa: yt921x: Add port qdisc tbf support
From: Jakub Kicinski @ 2026-05-07 1:23 UTC (permalink / raw)
To: mmyangfl
Cc: Jakub Kicinski, netdev, andrew, olteanv, davem, edumazet, pabeni,
jhs, jiri, horms, linux-kernel
In-Reply-To: <20260504101258.1608004-4-mmyangfl@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.
---
net: dsa: yt921x: Add port qdisc tbf support
This commit wires up the port_setup_tc DSA operation to offload a TBF
qdisc onto the yt921x per-port shaper, adding register definitions for
the shaper control block and a marker-transform helper that shares the
existing policer plumbing.
> diff --git a/drivers/net/dsa/yt921x.c b/drivers/net/dsa/yt921x.c
> index 42dca9617fb1..dc38e0dd22ee 100644
> --- a/drivers/net/dsa/yt921x.c
> +++ b/drivers/net/dsa/yt921x.c
[ ... ]
> @@ -1378,6 +1390,112 @@ yt921x_dsa_port_policer_add(struct dsa_switch *ds, int port,
> return res;
> }
>
> +static int
> +yt921x_tbf_validate(struct yt921x_priv *priv,
> + const struct tc_tbf_qopt_offload *qopt)
> +{
> + struct netlink_ext_ack *extack = qopt->extack;
> +
> + if (qopt->parent != TC_H_ROOT) {
> + NL_SET_ERR_MSG_MOD(extack, "Parent should be \"root\"");
> + return -EOPNOTSUPP;
> + }
> +
> + switch (qopt->command) {
> + case TC_TBF_REPLACE: {
> + const struct tc_tbf_qopt_offload_replace_params *p;
> +
> + p = &qopt->replace_params;
> +
> + if (p->mtu || p->peak.rate_bytes_ps) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "Offload not supported when mtu/peakrate is configured");
> + return -EOPNOTSUPP;
> + }
Is the p->mtu check overly broad here? tbf_change() in
net/sched/sch_tbf.c sets q->mtu from the user-supplied qopt->mtu whenever
TCA_TBF_PBURST is absent, so p->mtu can be non-zero even when no peakrate
has been requested. A user that explicitly passes the mtu parameter to
tc would then be denied offload with an error that attributes the failure
to mtu/peakrate together.
Would gating only on p->peak.rate_bytes_ps better reflect what the
hardware cannot do?
> +
> + if (!p->rate.mpu) {
> + NL_SET_ERR_MSG_MOD(extack, "Assuming mpu = 64");
> + } else if (p->rate.mpu != 64) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "Offload not supported when mpu is other than 64");
> + return -EOPNOTSUPP;
> + }
Is setting an extack message on the success path intentional?
psched_ratecfg_precompute() leaves mpu at 0 by default, so the common
tc qdisc add ... tbf rate X burst Y invocation will hit the first branch,
return 0, and iproute2 will then print:
Warning: yt921x: Assuming mpu = 64.
on every TBF replace.
Also, is the assumption actually enforced anywhere? yt921x_marker_tfm_shape()
and yt921x_marker_tfm() do not appear to compensate the rate computation
for a 64-byte MPU, so the message seems to document an assumption that is
not modelled by the transform.
> +
> + break;
> + }
> + default:
> + break;
> + }
> +
> + return 0;
> +}
Would it be clearer to have yt921x_tbf_validate() return -EOPNOTSUPP for
commands the handler cannot service, so the supported command set is
stated once? The default arm here returns 0 for every command other than
TC_TBF_REPLACE (including TC_TBF_STATS and TC_TBF_GRAFT) while
yt921x_dsa_port_setup_tc_tbf_port() below returns -EOPNOTSUPP for those
same commands. There is no observable bug today, but if the validator is
ever used on its own the two lists can drift.
> +
> +static int
> +yt921x_dsa_port_setup_tc_tbf_port(struct dsa_switch *ds, int port,
> + const struct tc_tbf_qopt_offload *qopt)
> +{
> + struct yt921x_priv *priv = to_yt921x_priv(ds);
> + struct netlink_ext_ack *extack = qopt->extack;
> + u32 ctrls[2];
> + int res;
> +
> + switch (qopt->command) {
> + case TC_TBF_DESTROY:
> + ctrls[0] = 0;
> + ctrls[1] = 0;
> + break;
Is there a concern about the write ordering on teardown?
yt921x_reg64_write() -> yt921x_regs_write() performs two independent
register writes (reg+0 then reg+4). On TC_TBF_DESTROY the first write
sets CIR=0 and CBS=0 while the previously programmed EN bit in ctrls[1]
is still set; only the second write clears EN. The REPLACE path writes
configuration before arming EN, but the inverse is not followed here.
Would writing ctrls[1]=0 first (or clearing EN via a read-modify-write
before zeroing CIR/CBS) be safer for the hardware state machine?
> + case TC_TBF_REPLACE: {
[ ... ]
> + ctrls[0] = YT921X_PORT_SHAPE_CTRLa_CIR(marker.cir) |
> + YT921X_PORT_SHAPE_CTRLa_CBS(marker.cbs);
> + ctrls[1] = YT921X_PORT_SHAPE_CTRLb_UNIT(marker.unit) |
> + YT921X_PORT_SHAPE_CTRLb_EN;
> + break;
> + }
> + default:
> + return -EOPNOTSUPP;
> + }
Does returning -EOPNOTSUPP for TC_TBF_STATS defeat the hw offload
indicator? qdisc_offload_dump_helper() in net/sched/sch_api.c first
clears TCQ_F_OFFLOADED, then calls into the driver, and only re-sets the
flag on a zero return:
sch->flags &= ~TCQ_F_OFFLOADED;
if (!tc_skip_hw(sch->flags))
err = qdisc_offload(sch, type, type_data, extack);
if (err == -EOPNOTSUPP)
return 0;
if (err)
return err;
sch->flags |= TCQ_F_OFFLOADED;
tbf_dump() invokes this path on every dump, so even after a successful
TC_TBF_REPLACE, tc -s qdisc show would keep reporting offload false and
tc_fill_qdisc() would emit TCA_HW_OFFLOAD=0.
Would a stub TC_TBF_STATS case that returns 0 (leaving bstats/qstats
untouched) preserve the flag here? mlxsw does this in its
spectrum_qdisc.c.
[ ... ]
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: sched: tbf: pass all params to offload users
From: Jakub Kicinski @ 2026-05-07 1:23 UTC (permalink / raw)
To: mmyangfl
Cc: Jakub Kicinski, netdev, andrew, olteanv, davem, edumazet, pabeni,
jhs, jiri, horms, linux-kernel
In-Reply-To: <20260504101258.1608004-3-mmyangfl@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.
---
net: sched: tbf: pass all params to offload users
This change extends struct tc_tbf_qopt_offload_replace_params with
limit, max_size, buffer, mtu and a peak ratecfg, and populates them
from tbf_sched_data in tbf_offload_change() so offload drivers can see
all the tbf parameters.
> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
> index 3bd08d7f39c1..d73c04e3d919 100644
> --- a/include/net/pkt_cls.h
> +++ b/include/net/pkt_cls.h
> @@ -1040,8 +1040,12 @@ enum tc_tbf_command {
> };
>
> struct tc_tbf_qopt_offload_replace_params {
> + u32 limit;
> + u32 max_size;
> + s64 buffer;
> + s64 mtu;
The buffer and mtu fields are stored in tbf_sched_data in nanoseconds
(see tbf_change() in net/sched/sch_tbf.c where they are derived via
PSCHED_TICKS2NS(qopt->buffer) and psched_l2t_ns()), but they are
exposed here as bare s64 buffer / s64 mtu right next to max_size
which is a byte count.
Would it be worth renaming these to buffer_ns / mtu_ns, or adding
kerneldoc to describe their unit?
A driver author reading this struct and seeing mtu adjacent to
max_size might reasonably assume mtu is a byte MTU and program
hardware accordingly.
> struct psched_ratecfg rate;
> - u32 max_size;
> + struct psched_ratecfg peak;
tbf_change() does memset(&peak, 0, sizeof(peak)) when no peakrate is
configured, and the qdisc internally uses tbf_peak_present(q) which
checks q->peak.rate_bytes_ps != 0 to distinguish absent from present.
With peak exposed to offload drivers, every driver now has to
reproduce this convention implicitly (e.g. by checking
p->peak.rate_bytes_ps).
Would an explicit indicator such as a bool peak_present field, or at
least kerneldoc spelling out the rate_bytes_ps == 0 means absent
contract, make this safer for future offload consumers?
> struct gnet_stats_queue *qstats;
> };
>
[ ... ]
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: dsa: yt921x: Add port qdisc tbf support
From: Jakub Kicinski @ 2026-05-07 1:22 UTC (permalink / raw)
To: mmyangfl
Cc: Jakub Kicinski, netdev, andrew, olteanv, davem, edumazet, pabeni,
jhs, jiri, horms, linux-kernel
In-Reply-To: <20260504101258.1608004-4-mmyangfl@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.
---
net: dsa: yt921x: Add port qdisc tbf support
This patch enables port shaping and adds support for limiting the rate of
outgoing traffic using the TBF qdisc offload.
> diff --git a/drivers/net/dsa/yt921x.c b/drivers/net/dsa/yt921x.c
> index 42dca9617fb1..dc38e0dd22ee 100644
> --- a/drivers/net/dsa/yt921x.c
> +++ b/drivers/net/dsa/yt921x.c
[ ... ]
> @@ -1378,6 +1390,112 @@ yt921x_dsa_port_policer_add(struct dsa_switch *ds, int port,
> return res;
> }
>
> +static int
> +yt921x_tbf_validate(struct yt921x_priv *priv,
> + const struct tc_tbf_qopt_offload *qopt)
> +{
[ ... ]
> + switch (qopt->command) {
> + case TC_TBF_REPLACE: {
> + const struct tc_tbf_qopt_offload_replace_params *p;
> +
> + p = &qopt->replace_params;
> +
> + if (p->mtu || p->peak.rate_bytes_ps) {
The userspace tc utility unconditionally sets a default MTU (typically 2047)
when adding a TBF qdisc, which is passed to the driver via p->mtu. Since
p->mtu is never zero, will this unconditionally reject all offload requests?
> + NL_SET_ERR_MSG_MOD(extack,
> + "Offload not supported when mtu/peakrate is configured");
> + return -EOPNOTSUPP;
> + }
> +
> + if (!p->rate.mpu) {
Does this code miss validation for p->rate.overhead?
The TC TBF layer allows configuring overhead to account for additional
headers. If the hardware relies on fixed wire frame sizes and the driver
ignores p->rate.overhead, could this lead to a silent misconfiguration
where the hardware shapes traffic at a different effective rate than
requested?
> + NL_SET_ERR_MSG_MOD(extack, "Assuming mpu = 64");
> + } else if (p->rate.mpu != 64) {
> + NL_SET_ERR_MSG_MOD(extack,
> + "Offload not supported when mpu is other than 64");
> + return -EOPNOTSUPP;
> + }
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net: sched: tbf: pass all params to offload users
From: Jakub Kicinski @ 2026-05-07 1:22 UTC (permalink / raw)
To: mmyangfl
Cc: Jakub Kicinski, netdev, andrew, olteanv, davem, edumazet, pabeni,
jhs, jiri, horms, linux-kernel
In-Reply-To: <20260504101258.1608004-3-mmyangfl@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.
---
net: sched: tbf: pass all params to offload users
This commit exposes additional TBF parameters (limit, buffer, mtu, and peak
rate) to hardware offload drivers so they have finer-grained control over
queue configuration.
> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
> index 3bd08d7f39c1..d73c04e3d919 100644
> --- a/include/net/pkt_cls.h
> +++ b/include/net/pkt_cls.h
> @@ -1040,8 +1040,12 @@ enum tc_tbf_command {
> };
>
> struct tc_tbf_qopt_offload_replace_params {
> + u32 limit;
> + u32 max_size;
> + s64 buffer;
> + s64 mtu;
Are buffer and mtu the most clear variable names for the offload API?
In sch_tbf.c, these fields store token bucket depths converted to nanoseconds,
rather than raw configuration bytes. Exposing time values under names that
typically imply byte sizes could mislead driver authors.
> struct psched_ratecfg rate;
> - u32 max_size;
> + struct psched_ratecfg peak;
> struct gnet_stats_queue *qstats;
> };
[ ... ]
> diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
> index 4576111fe075..8a1110d59dec 100644
> --- a/net/sched/sch_tbf.c
> +++ b/net/sched/sch_tbf.c
> @@ -153,8 +153,12 @@ static void tbf_offload_change(struct Qdisc *sch,
> qopt.command = TC_TBF_REPLACE;
> qopt.handle = sch->handle;
> qopt.parent = sch->parent;
> - qopt.replace_params.rate = q->rate;
> + qopt.replace_params.limit = q->limit;
> qopt.replace_params.max_size = q->max_size;
Does passing q->max_size here provide the driver with the original burst size?
The software TBF overwrites q->max_size with min(burst, pburst) when a peak
rate is configured. As a result, the offload API only passes this overwritten
value, meaning a driver attempting to offload a dual-rate TBF is not given
the original burst size in bytes and would have to reverse-engineer it from
the nanosecond buffer value.
> + qopt.replace_params.buffer = q->buffer;
> + qopt.replace_params.mtu = q->mtu;
Will this cause the yt921x offload (introduced in the next patch) to
unconditionally reject all offloads?
The yt921x driver attempts to reject dual-rate offloads by checking if p->mtu
or p->peak.rate_bytes_ps are set. However, the tc userspace tool always
populates the mtu parameter with a default value (like 2047 bytes) for legacy
rate table compatibility.
Since tc always sets mtu, q->mtu will be non-zero, causing the yt921x driver
to return -EOPNOTSUPP and reject the configuration.
Should the offload API explicitly pass the raw burst and pburst parameters in
bytes instead?
> + qopt.replace_params.rate = q->rate;
> + qopt.replace_params.peak = q->peak;
> qopt.replace_params.qstats = &sch->qstats;
>
> dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_QDISC_TBF, &qopt);
^ permalink raw reply
* Re: [PATCH v2 net] net/sched: sch_sfq: annotate data-races from sfq_dump_class_stats()
From: patchwork-bot+netdevbpf @ 2026-05-07 1:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260505091133.2452510-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 5 May 2026 09:11:33 +0000 you wrote:
> sfq_dump_class_stats() runs locklessly, add needed READ_ONCE()
> and 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>
> ---
> v2: fix logic error in sfq_dec()
>
> [...]
Here is the summary with links:
- [v2,net] net/sched: sch_sfq: annotate data-races from sfq_dump_class_stats()
https://git.kernel.org/netdev/net/c/770b136ff9bf
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 1/2] net/sched: sch_cbs: Call qdisc_reset for child qdisc
From: Jakub Kicinski @ 2026-05-07 1:10 UTC (permalink / raw)
To: jhs
Cc: Jakub Kicinski, netdev, victor, davem, edumazet, pabeni, jiri,
horms, vinicius.gomes, graypanda.inzag, security
In-Reply-To: <20260505132102.128903-1-jhs@mojatatu.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.
---
net/sched: sch_cbs: Call qdisc_reset for child qdisc
This commit introduces a reset callback for the CBS qdisc. The new
cbs_reset() function propagates the reset to the child qdisc to prevent
qlen and backlog accounting issues during resets.
> diff --git a/net/sched/sch_cbs.c b/net/sched/sch_cbs.c
> index 8c9a0400c8622..1efd72581614e 100644
> --- a/net/sched/sch_cbs.c
> +++ b/net/sched/sch_cbs.c
> @@ -243,6 +243,16 @@ static struct sk_buff *cbs_dequeue(struct Qdisc *sch)
> return q->dequeue(sch);
> }
>
> +static void cbs_reset(struct Qdisc *sch)
> +{
> + struct cbs_sched_data *q = qdisc_priv(sch);
> +
> + qdisc_reset(q->qdisc);
Can this cause a null pointer dereference during qdisc teardown?
If a CBS qdisc is created and cbs_init() fails (for example, if opt is null),
it returns -EINVAL leaving q->qdisc and q->watchdog uninitialized.
The cleanup path in qdisc_create_dflt() will call qdisc_put(), which
triggers __qdisc_destroy(). __qdisc_destroy() unconditionally calls
qdisc_reset() before calling ops->destroy().
Because q->qdisc is null here, calling qdisc_reset(q->qdisc) would
dereference a null pointer.
> + qdisc_watchdog_cancel(&q->watchdog);
Similarly, could this trigger a crash by calling hrtimer_cancel() on an
uninitialized timer?
Does cbs_reset() need an early return if q->qdisc is null, similar to the
safety guard already present in cbs_destroy(), to prevent these issues?
> + q->credits = 0;
> + q->last = 0;
> +}
> +
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net v2] net: rtsn: fix mdio_node leak in rtsn_mdio_alloc()
From: patchwork-bot+netdevbpf @ 2026-05-07 0:50 UTC (permalink / raw)
To: Shitalkumar Gandhi
Cc: niklas.soderlund, geert+renesas, andrew, kuba, davem, edumazet,
pabeni, horms, netdev, linux-renesas-soc, linux-kernel,
shitalkumar.gandhi
In-Reply-To: <20260505123236.406000-1-shitalkumar.gandhi@cambiumnetworks.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 5 May 2026 18:02:36 +0530 you wrote:
> of_get_child_by_name() takes a reference. The rtsn_reset() and
> rtsn_change_mode() failure paths jump to out_free_bus and leak
> mdio_node.
>
> Add out_put_node to drop it before falling through.
>
> Fixes: b0d3969d2b4d ("net: ethernet: rtsn: Add support for Renesas Ethernet-TSN")
> Signed-off-by: Shitalkumar Gandhi <shitalkumar.gandhi@cambiumnetworks.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> [...]
Here is the summary with links:
- [net,v2] net: rtsn: fix mdio_node leak in rtsn_mdio_alloc()
https://git.kernel.org/netdev/net/c/701ea57feaab
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] inetpeer: add a missing read_seqretry() in inet_getpeer()
From: patchwork-bot+netdevbpf @ 2026-05-07 0:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet, melotti
In-Reply-To: <20260505133233.3039575-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 5 May 2026 13:32:33 +0000 you wrote:
> When performing a lockless lookup over the inet_peer rbtree,
> if a matching node is found, inet_getpeer() returns it immediately
> without validating the seqlock sequence.
>
> This missing check introduces a race condition:
>
> Trigger Path: When a host receives an incoming fragmented IPv4 packet,
> ip4_frag_init() (in net/ipv4/ip_fragment.c) calls inet_getpeer_v4()
> to track the peer.
>
> [...]
Here is the summary with links:
- [net] inetpeer: add a missing read_seqretry() in inet_getpeer()
https://git.kernel.org/netdev/net/c/67ef49047d31
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 0/3] netdevsim: psp: fix init and uninit bugs
From: patchwork-bot+netdevbpf @ 2026-05-07 0:50 UTC (permalink / raw)
To: Daniel Zahka
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, willemb,
willemdebruijn.kernel, netdev, linux-kernel
In-Reply-To: <20260505-psd-rcu-v1-0-a8f69ec1ab96@gmail.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 05 May 2026 03:42:22 -0700 you wrote:
> This series has three fixes. The first is a straightforward NULL
> pointer dereference that is reachable by creating and destroying some
> vfs on a kernel with INET_PSP enabled.
>
> The last two patches deal with nsim_psp_rereg_write(), which is a
> debugfs handler that reregisters netdevsim's psp_dev without
> aquiescing and disabling tx/rx processing. This was added to enable
> some tests in psp.py where a psp device is unregistered while it still
> referenced by tcp socket state.
>
> [...]
Here is the summary with links:
- [net,1/3] netdevsim: psp: only call nsim_psp_uninit() on PFs
https://git.kernel.org/netdev/net/c/7ce3f1bedaac
- [net,2/3] netdevsim: psp: serialize calls to nsim_psp_uninit()
https://git.kernel.org/netdev/net/c/24c96a42006e
- [net,3/3] netdevsim: psp: rcu protect psp_dev reference
https://git.kernel.org/netdev/net/c/07bdec3fc737
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] ipv6: fix potential UAF caused by ip6_forward_proxy_check()
From: patchwork-bot+netdevbpf @ 2026-05-07 0:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, idosch, dsahern, netdev, eric.dumazet,
melotti
In-Reply-To: <20260505130056.2927197-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 5 May 2026 13:00:56 +0000 you wrote:
> ip6_forward_proxy_check() calls pskb_may_pull() which might re-allocate
> skb->head.
>
> Reload ipv6_hdr() after the pskb_may_pull() call to avoid using
> the freed memory.
>
> Fixes: e21e0b5f19ac ("[IPV6] NDISC: Handle NDP messages to proxied addresses.")
> Reported-by: Damiano Melotti <melotti@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> [...]
Here is the summary with links:
- [net] ipv6: fix potential UAF caused by ip6_forward_proxy_check()
https://git.kernel.org/netdev/net/c/7aaa8f5e45a9
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 v2 net-next 5/8] net: ena: PHC: Check return code before setting timestamp output
From: Kiyanovski, Arthur @ 2026-05-07 0:39 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, Jakub Kicinski, netdev@vger.kernel.org,
Richard Cochran, Eric Dumazet, Paolo Abeni, David Woodhouse,
Thomas Gleixner, Miroslav Lichvar, Andrew Lunn, Wen Gu, Xuan Zhuo,
Woodhouse, David, Sarna, Yuval, Machulsky, Zorik,
Matushevsky, Alexander, Bshara, Saeed, Wilson, Matt,
Liguori, Anthony, Bshara, Nafea, Schmeilin, Evgeny,
Belgazal, Netanel, Saidi, Ali, Herrenschmidt, Benjamin,
Dagan, Noam, Arinzon, David, Ostrovsky, Evgeny, Tabachnik, Ofir,
Bernstein, Amit, linux-kselftest@vger.kernel.org,
shuah@kernel.org, vadim.fedorenko@linux.dev
In-Reply-To: <20260505093130.GP15617@horms.kernel.org>
> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Subject: RE: [EXTERNAL] [PATCH v2 net-next 5/8] net: ena: PHC: Check return
> code before setting timestamp output
>
> On Thu, Apr 30, 2026 at 03:25:02AM +0000, Arthur Kiyanovski wrote:
> > ena_phc_gettimex64() is setting the output parameter regardless of
> > whether ena_com_phc_get_timestamp() succeeded or failed.
> >
> > When ena_com_phc_get_timestamp() returns an error, the timestamp
> > parameter may contain uninitialized stack memory (e.g., when PHC is
> > disabled or in blocked state) or invalid hardware values. Passing
> > these to userspace via the PTP ioctl is both a security issue
> > (information leak) and a correctness bug.
> >
> > Fix by checking the return code after releasing the lock and only
> > setting the output timestamp on success.
> >
> > Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver")
> > Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
>
> Hi Arthur,
>
> Perhaps I am missing a dependency, but it seems to me that it would be best
> to separate this patch from the rest of this patch-set and post it a fix targeted
> at net, CCed to stable.
Thank you Simon,
I resent it to net separately.
Thank you,
Arthur
^ permalink raw reply
* [PATCH net] net: ena: PHC: Check return code before setting timestamp output
From: Arthur Kiyanovski @ 2026-05-07 0:35 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, netdev
Cc: Arthur Kiyanovski, Richard Cochran, Eric Dumazet, Paolo Abeni,
David Woodhouse, Thomas Gleixner, Miroslav Lichvar, Andrew Lunn,
Wen Gu, Xuan Zhuo, David Woodhouse, Yonatan Sarna,
Zorik Machulsky, Alexander Matushevsky, Saeed Bshara, Matt Wilson,
Anthony Liguori, Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal,
Ali Saidi, Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, stable
ena_phc_gettimex64() is setting the output parameter regardless
of whether ena_com_phc_get_timestamp() succeeded or failed.
When ena_com_phc_get_timestamp() returns an error, the timestamp
parameter may contain uninitialized stack memory (e.g., when PHC is
disabled or in blocked state) or invalid hardware values. Passing
these to userspace via the PTP ioctl is both a security issue
(information leak) and a correctness bug.
Fix by checking the return code after releasing the lock and only
setting the output timestamp on success.
Fixes: e0ea34158ee8 ("net: ena: Add PHC support in the ENA driver")
Cc: stable@vger.kernel.org
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_phc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_phc.c b/drivers/net/ethernet/amazon/ena/ena_phc.c
index 7867e893fd15..c2a3ff1ef645 100644
--- a/drivers/net/ethernet/amazon/ena/ena_phc.c
+++ b/drivers/net/ethernet/amazon/ena/ena_phc.c
@@ -46,9 +46,12 @@ static int ena_phc_gettimex64(struct ptp_clock_info *clock_info,
spin_unlock_irqrestore(&phc_info->lock, flags);
+ if (rc)
+ return rc;
+
*ts = ns_to_timespec64(timestamp_nsec);
- return rc;
+ return 0;
}
static int ena_phc_settime64(struct ptp_clock_info *clock_info,
--
2.47.3
^ permalink raw reply related
* Re: [PATCH net-next v2] rtase: Fix flow control configuration
From: patchwork-bot+netdevbpf @ 2026-05-07 0:30 UTC (permalink / raw)
To: Justin Lai
Cc: kuba, davem, edumazet, pabeni, andrew+netdev, linux-kernel,
netdev, horms, pkshih, larry.chiu
In-Reply-To: <20260505064121.31286-1-justinlai0215@realtek.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 5 May 2026 14:41:21 +0800 you wrote:
> The hardware has two sets of registers controlling TX/RX flow control.
> The effective flow control state is determined by the logical OR of
> these two sets of bits.
>
> RTASE_FORCE_TXFLOW_EN and RTASE_FORCE_RXFLOW_EN in RTASE_CPLUS_CMD are
> the bits used by the driver to control TX/RX flow control according to
> the ethtool pause configuration.
>
> [...]
Here is the summary with links:
- [net-next,v2] rtase: Fix flow control configuration
https://git.kernel.org/netdev/net-next/c/fea3521e043f
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 1/8] ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()
From: patchwork-bot+netdevbpf @ 2026-05-07 0:30 UTC (permalink / raw)
To: Steffen Klassert; +Cc: davem, kuba, herbert, netdev
In-Reply-To: <20260505132326.1362733-2-steffen.klassert@secunet.com>
Hello:
This series was applied to netdev/net.git (main)
by Steffen Klassert <steffen.klassert@secunet.com>:
On Tue, 5 May 2026 15:22:57 +0200 you wrote:
> From: Yilin Zhu <zylzyl2333@gmail.com>
>
> xfrm6_rcv_encap() performs an IPv6 route lookup when the skb does not
> already have a dst attached. ip6_route_input_lookup() returns a
> referenced dst entry even when the lookup resolves to an error route.
>
> If dst->error is set, xfrm6_rcv_encap() drops the skb without attaching
> the dst to the skb and without releasing the reference returned by the
> lookup. Repeated packets hitting this path therefore leak dst entries.
>
> [...]
Here is the summary with links:
- [1/8] ipv6: xfrm6: release dst on error in xfrm6_rcv_encap()
https://git.kernel.org/netdev/net/c/bc0fcb9823cd
- [2/8] xfrm: ah: account for ESN high bits in async callbacks
https://git.kernel.org/netdev/net/c/ec54093e6a8f
- [3/8] tools/selftests: Use a sensible timeout value for iperf3 client
https://git.kernel.org/netdev/net/c/ada95e5e603b
- [4/8] tools/selftests: Add a VXLAN+IPsec traffic test
https://git.kernel.org/netdev/net/c/e64e03b478e2
- [5/8] xfrm: Don't clobber inner headers when already set
https://git.kernel.org/netdev/net/c/fa90a3145c03
- [6/8] xfrm: provide message size for XFRM_MSG_MAPPING
https://git.kernel.org/netdev/net/c/28465227c80f
- [7/8] xfrm: defensively unhash xfrm_state lists in __xfrm_state_delete
https://git.kernel.org/netdev/net/c/14acf9652e56
- [8/8] xfrm: esp: avoid in-place decrypt on shared skb frags
https://git.kernel.org/netdev/net/c/f4c50a4034e6
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 4/5] llc: convert to getsockopt_iter
From: Jakub Kicinski @ 2026-05-07 0:25 UTC (permalink / raw)
To: Breno Leitao
Cc: Oliver Hartkopp, Marc Kleine-Budde, Robin van der Gracht,
Oleksij Rempel, kernel, Jeremy Kerr, Matt Johnston,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Shuah Khan, linux-can, linux-kernel, netdev, linux-kselftest,
kernel-team
In-Reply-To: <20260505-getsock_two-v1-4-4cb0738950e0@debian.org>
On Tue, 05 May 2026 04:12:41 -0700 Breno Leitao wrote:
> Convert LLC socket's getsockopt implementation to use the new
> getsockopt_iter callback with sockopt_t.
>
> Key changes:
> - Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
> - Use opt->optlen for buffer length (input) and returned size (output)
> - Use copy_to_iter() instead of put_user()/copy_to_user()
> - Add linux/uio.h for copy_to_iter()
kdoc needs to be adjusted here.
When you repost could you split the CAN stuff out and send it
to Marc and co. ? We don't normally take CAN patches directly.
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 4/8] tools/selftests: Add a VXLAN+IPsec traffic test
From: Jakub Kicinski @ 2026-05-07 0:23 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <20260506170435.34984dfc@kernel.org>
On Wed, 6 May 2026 17:04:35 -0700 Jakub Kicinski wrote:
> Oh, sorry, changed my mind we can't pull this:( both the Makefile and
> config break alphabetic sort, our CI will flag every incoming as red
> if we merge this as is, we need this on top:
Eh, let me just commit this and move on..
^ permalink raw reply
* Re: [PATCH 4/8] tools/selftests: Add a VXLAN+IPsec traffic test
From: Jakub Kicinski @ 2026-05-07 0:04 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, Herbert Xu, netdev
In-Reply-To: <20260505132326.1362733-5-steffen.klassert@secunet.com>
On Tue, 5 May 2026 15:23:00 +0200 Steffen Klassert wrote:
> diff --git a/tools/testing/selftests/drivers/net/hw/config b/tools/testing/selftests/drivers/net/hw/config
> index dd50cb8a7911..ae0168c2bbe6 100644
> --- a/tools/testing/selftests/drivers/net/hw/config
> +++ b/tools/testing/selftests/drivers/net/hw/config
> @@ -12,5 +12,10 @@ CONFIG_NET_IPGRE=y
> CONFIG_NET_IPGRE_DEMUX=y
> CONFIG_NETKIT=y
> CONFIG_NET_SCH_INGRESS=y
> +CONFIG_INET6_ESP=y
> +CONFIG_INET6_ESP_OFFLOAD=y
> +CONFIG_INET_ESP=y
> +CONFIG_INET_ESP_OFFLOAD=y
> CONFIG_UDMABUF=y
> CONFIG_VXLAN=y
> +CONFIG_XFRM_USER=y
Oh, sorry, changed my mind we can't pull this:( both the Makefile and
config break alphabetic sort, our CI will flag every incoming as red
if we merge this as is, we need this on top:
diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
index 3b6ff4708005..82809d5b2478 100644
--- a/tools/testing/selftests/drivers/net/hw/Makefile
+++ b/tools/testing/selftests/drivers/net/hw/Makefile
@@ -28,12 +28,12 @@ TEST_PROGS = \
ethtool_rmon.sh \
ethtool_std_stats.sh \
gro_hw.py \
hw_stats_l3.sh \
hw_stats_l3_gre.sh \
- ipsec_vxlan.py \
iou-zcrx.py \
+ ipsec_vxlan.py \
irq.py \
loopback.sh \
nic_timestamp.py \
nk_netns.py \
nk_qlease.py \
diff --git a/tools/testing/selftests/drivers/net/hw/config b/tools/testing/selftests/drivers/net/hw/config
index ae0168c2bbe6..8c132ace2b8d 100644
--- a/tools/testing/selftests/drivers/net/hw/config
+++ b/tools/testing/selftests/drivers/net/hw/config
@@ -1,21 +1,21 @@
CONFIG_BPF_SYSCALL=y
CONFIG_FAIL_FUNCTION=y
CONFIG_FAULT_INJECTION=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_FUNCTION_ERROR_INJECTION=y
+CONFIG_INET6_ESP=y
+CONFIG_INET6_ESP_OFFLOAD=y
+CONFIG_INET_ESP=y
+CONFIG_INET_ESP_OFFLOAD=y
CONFIG_IO_URING=y
CONFIG_IPV6=y
CONFIG_IPV6_GRE=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_CLS_BPF=y
CONFIG_NET_IPGRE=y
CONFIG_NET_IPGRE_DEMUX=y
CONFIG_NETKIT=y
CONFIG_NET_SCH_INGRESS=y
-CONFIG_INET6_ESP=y
-CONFIG_INET6_ESP_OFFLOAD=y
-CONFIG_INET_ESP=y
-CONFIG_INET_ESP_OFFLOAD=y
CONFIG_UDMABUF=y
CONFIG_VXLAN=y
CONFIG_XFRM_USER=y
^ permalink raw reply related
* Re: [PATCH] devlink/param: replace deprecated strcpy() with strscpy()
From: Álvaro Costa @ 2026-05-06 23:52 UTC (permalink / raw)
To: Jakub Kicinski
Cc: jiri, David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
open list:DEVLINK, open list
In-Reply-To: <20260506154252.65d673c2@kernel.org>
On Wed, May 6, 2026 at 7:42 PM Jakub Kicinski <kuba@kernel.org> wrote:
> The current code validates the netlink attr is nul-terminated.
> I'm not sure if your patch retains current behavior.
> I am sure, however, that checking whether the change is correct
> is a poor use of everyone's time.
> Please don't send these sort of patches for networking.
> --
> pw-bot: reject
Ok, thank you for the quick feedback!
^ 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