* [syzbot] [net?] WARNING: ODEBUG bug in lane_ioctl (3)
From: syzbot @ 2026-04-29 2:25 UTC (permalink / raw)
To: davem, edumazet, horms, kuba, linux-kernel, netdev, pabeni,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: e728258debd5 Merge tag 'net-7.1-rc1' of git://git.kernel.o..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1752f702580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ca77bfc4078c8193
dashboard link: https://syzkaller.appspot.com/bug?extid=ca9d5686d06994c6547c
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16811c36580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=128c52d2580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/24195bde5d1d/disk-e728258d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/78131d1b0e14/vmlinux-e728258d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/836d0dd78c10/bzImage-e728258d.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ca9d5686d06994c6547c@syzkaller.appspotmail.com
------------[ cut here ]------------
ODEBUG: init active (active state 0) object: ffff888077a60f78 object type: timer_list hint: lec_arp_check_expire+0x0/0xc90 net/atm/lec.c:-1
WARNING: lib/debugobjects.c:632 at debug_print_object lib/debugobjects.c:629 [inline], CPU#0: syz-executor253/5933
WARNING: lib/debugobjects.c:632 at __debug_object_init+0x2b1/0x4e0 lib/debugobjects.c:780, CPU#0: syz-executor253/5933
Modules linked in:
CPU: 0 UID: 0 PID: 5933 Comm: syz-executor253 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
RIP: 0010:debug_print_object lib/debugobjects.c:629 [inline]
RIP: 0010:__debug_object_init+0x30f/0x4e0 lib/debugobjects.c:780
Code: 3c 38 00 74 08 4c 89 ef e8 0e df 74 fd 4d 8b 4d 00 4c 89 f7 48 c7 c6 20 a7 28 8c 4c 89 e2 8b 4c 24 08 4c 8b 04 24 ff 74 24 10 <67> 48 0f b9 3a 48 83 c4 08 ff 05 8e 8c 77 0b 83 fd 03 75 3f 4c 8b
RSP: 0018:ffffc90003e278f8 EFLAGS: 00010246
RAX: 1ffffffff179e734 RBX: ffff888077a60f78 RCX: 0000000000000000
RDX: ffffffff8c28ab20 RSI: ffffffff8c28a720 RDI: ffffffff903e69a0
RBP: 0000000000000003 R08: ffff888077a60f78 R09: ffffffff8bcf4d00
R10: dffffc0000000000 R11: ffffffff81b236d0 R12: ffffffff8c28ab20
R13: ffffffff8bcf39a0 R14: ffffffff903e69a0 R15: dffffc0000000000
FS: 00007f3e1e8976c0(0000) GS:ffff888125213000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055a602110fd8 CR3: 00000000753ea000 CR4: 00000000003526f0
Call Trace:
<TASK>
debug_timer_init kernel/time/timer.c:788 [inline]
debug_init kernel/time/timer.c:836 [inline]
timer_init_key+0x41/0x2c0 kernel/time/timer.c:880
lec_arp_init net/atm/lec.c:1274 [inline]
lecd_attach net/atm/lec.c:781 [inline]
lane_ioctl+0x1579/0x2220 net/atm/lec.c:1037
do_vcc_ioctl+0x36d/0x9d0 net/atm/ioctl.c:159
svc_ioctl+0x1f6/0x7d0 net/atm/svc.c:611
sock_do_ioctl+0x101/0x320 net/socket.c:1313
sock_ioctl+0x5c6/0x7f0 net/socket.c:1434
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3e1e8bf0d9
Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 d0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f3e1e897158 EFLAGS: 00000246
ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f3e1e96fb48 RCX: 00007f3e1e8bf0d9
RDX: 0000000000000000 RSI: 00000000000061d0 RDI: 0000000000000005
RBP: 00007f3e1e96fb40 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3e1e9413b0
R13: 0000000000000000 R14: 0000200000000040 R15: b635773f07ebbeef
</TASK>
----------------
Code disassembly (best guess):
0: 3c 38 cmp $0x38,%al
2: 00 74 08 4c add %dh,0x4c(%rax,%rcx,1)
6: 89 ef mov %ebp,%edi
8: e8 0e df 74 fd call 0xfd74df1b
d: 4d 8b 4d 00 mov 0x0(%r13),%r9
11: 4c 89 f7 mov %r14,%rdi
14: 48 c7 c6 20 a7 28 8c mov $0xffffffff8c28a720,%rsi
1b: 4c 89 e2 mov %r12,%rdx
1e: 8b 4c 24 08 mov 0x8(%rsp),%ecx
22: 4c 8b 04 24 mov (%rsp),%r8
26: ff 74 24 10 push 0x10(%rsp)
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 48 83 c4 08 add $0x8,%rsp
33: ff 05 8e 8c 77 0b incl 0xb778c8e(%rip) # 0xb778cc7
39: 83 fd 03 cmp $0x3,%ebp
3c: 75 3f jne 0x7d
3e: 4c rex.WR
3f: 8b .byte 0x8b
---
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 syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
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
* [PATCH net-next v3] net/smc: cap allocation order for SMC-R physically contiguous buffers
From: D. Wythe @ 2026-04-29 2:16 UTC (permalink / raw)
To: David S. Miller, Dust Li, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Sidraya Jayagond, Wenjia Zhang
Cc: Mahanta Jambigi, Simon Horman, Tony Lu, Wen Gu, linux-kernel,
linux-rdma, linux-s390, netdev, oliver.yang, pasic
The alloc_pages() cannot satisfy requests exceeding MAX_PAGE_ORDER,
and attempting such allocations will lead to guaranteed failures
and potential kernel warnings.
For SMCR_PHYS_CONT_BUFS, cap the allocation order to MAX_PAGE_ORDER.
This ensures the attempts to allocate the largest possible physically
contiguous chunk succeed, instead of failing with an invalid order.
This also avoids redundant "try-fail-degrade" cycles in
__smc_buf_create().
For SMCR_MIXED_BUFS, no cap is needed: if the order exceeds
MAX_PAGE_ORDER, alloc_pages() will silently fail (__GFP_NOWARN)
and automatically fall back to virtual memory.
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
---
Changes v2 -> v3:
https://lore.kernel.org/netdev/20260407124337.88128-1-alibuda@linux.alibaba.com/
Remove unnecessary parentheses
Changes v1 -> v2:
https://lore.kernel.org/netdev/20260312082154.36971-1-alibuda@linux.alibaba.com/
---
net/smc/smc_core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index e2d083daeb7e..cf6b620fef05 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -2440,6 +2440,10 @@ static int __smc_buf_create(struct smc_sock *smc, bool is_smcd, bool is_rmb)
/* use socket send buffer size (w/o overhead) as start value */
bufsize = smc->sk.sk_sndbuf / 2;
+ /* limit bufsize for physically contiguous buffers */
+ if (!is_smcd && lgr->buf_type == SMCR_PHYS_CONT_BUFS)
+ bufsize = min_t(int, bufsize, PAGE_SIZE << MAX_PAGE_ORDER);
+
for (bufsize_comp = smc_compress_bufsize(bufsize, is_smcd, is_rmb);
bufsize_comp >= 0; bufsize_comp--) {
if (is_rmb) {
--
2.45.0
^ permalink raw reply related
* Re: [PATCH ipsec-next v3] xfrm: cleanup error path in xfrm_add_policy()
From: Deepanshu Kartikey @ 2026-04-29 2:01 UTC (permalink / raw)
To: steffen.klassert, herbert, davem, edumazet, kuba, pabeni, horms,
sd
Cc: netdev, linux-kernel
In-Reply-To: <20260414020947.65905-1-kartikey406@gmail.com>
On Tue, Apr 14, 2026 at 7:39 AM Deepanshu Kartikey
<kartikey406@gmail.com> wrote:
>
> Replace the open-coded manual cleanup in the error path of
> xfrm_add_policy() with xfrm_policy_destroy(), which already
> handles all the necessary cleanup internally. This is consistent
> with how xfrm_policy_construct() handles its own error paths.
>
> The walk.dead flag must be set before calling xfrm_policy_destroy()
> as required by BUG_ON(!policy->walk.dead).
>
> Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> ---
> v3:
> - Changed prefix to ipsec-next as this is a cleanup
> - Dropped syzbot references as suggested by Sabrina Dubroca
> v2:
> - Reworded commit message to reflect cleanup rather than bugfix
> as suggested by Sabrina Dubroca
> - Removed incorrect Fixes: and Closes: tags
> - Corrected subject prefix to PATCH ipsec
> ---
> net/xfrm/xfrm_user.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index d56450f61669..ae144d1e4a65 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -2267,9 +2267,8 @@ static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
>
> if (err) {
> xfrm_dev_policy_delete(xp);
> - xfrm_dev_policy_free(xp);
> - security_xfrm_policy_free(xp->security);
> - kfree(xp);
> + xp->walk.dead = 1;
> + xfrm_policy_destroy(xp);
> return err;
> }
>
> --
> 2.43.0
>
Gentle ping on this patch . Please let me know the status of this patch.
If anything is required from my side
Thanks
^ permalink raw reply
* Re: [PATCH net 2/2] ip6_gre: Use cached t->net in ip6erspan_changelink().
From: Eric Dumazet @ 2026-04-29 2:00 UTC (permalink / raw)
To: Xiao Liang
Cc: Maoyi Xie, netdev, kuniyu, davem, kuba, pabeni, dsahern, kuznet,
linux-kernel, stable, security
In-Reply-To: <CABAhCOTmZ4hAuhtimOX1YQDGFC2fbXm5WmwT0Z8PxZU7Zq-2Fw@mail.gmail.com>
On Tue, Apr 28, 2026 at 6:58 PM Xiao Liang <shaw.leon@gmail.com> wrote:
>
> On Tue, Apr 28, 2026 at 7:07 PM Maoyi Xie <maoyixie.tju@gmail.com> wrote:
> >
> > From: Maoyi Xie <maoyi.xie@ntu.edu.sg>
> >
> > After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of
> > rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns
> > ip6gre hash via link_net. ip6erspan_changelink() was not converted in
> > that series and still uses dev_net(dev), which diverges from the
> > device's creation netns after IFLA_NET_NS_FD migration.
> >
> > This re-inserts the tunnel into the wrong per-netns hash, leaving a
> > stale entry in the original creation netns. When that netns is later
> > destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a
> > slab-use-after-free reported by KASAN, followed by a kernel BUG at
> > net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify().
> >
> > Reachable from an unprivileged user namespace ("unshare --user
> > --map-root-user --net"); cross-tenant scope on container hosts.
> >
> > Note: ip6gre_changelink() (the non-erspan sibling earlier in the same
> > file) already uses the cached t->net correctly. The bug is specific
> > to ip6erspan_changelink() copying the wrong shape.
> >
> > Fixes: 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops")
>
> The changes look good to me. But why is 5e72ce3e3980 mentioned
> here? It neither introduced nor was intended to fix this bug.
Which patch added the bug then in your opinion?
^ permalink raw reply
* Re: [PATCH net 2/2] ip6_gre: Use cached t->net in ip6erspan_changelink().
From: Xiao Liang @ 2026-04-29 1:58 UTC (permalink / raw)
To: Maoyi Xie
Cc: netdev, kuniyu, davem, kuba, edumazet, pabeni, dsahern, kuznet,
linux-kernel, stable, security
In-Reply-To: <20260428110713.2550315-3-maoyixie.tju@gmail.com>
On Tue, Apr 28, 2026 at 7:07 PM Maoyi Xie <maoyixie.tju@gmail.com> wrote:
>
> From: Maoyi Xie <maoyi.xie@ntu.edu.sg>
>
> After commit 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of
> rtnl_link_ops"), ip6erspan_newlink() correctly resolves the per-netns
> ip6gre hash via link_net. ip6erspan_changelink() was not converted in
> that series and still uses dev_net(dev), which diverges from the
> device's creation netns after IFLA_NET_NS_FD migration.
>
> This re-inserts the tunnel into the wrong per-netns hash, leaving a
> stale entry in the original creation netns. When that netns is later
> destroyed, ip6gre_exit_rtnl_net() walks the stale entry, producing a
> slab-use-after-free reported by KASAN, followed by a kernel BUG at
> net/core/dev.c (LIST_POISON1) in unregister_netdevice_many_notify().
>
> Reachable from an unprivileged user namespace ("unshare --user
> --map-root-user --net"); cross-tenant scope on container hosts.
>
> Note: ip6gre_changelink() (the non-erspan sibling earlier in the same
> file) already uses the cached t->net correctly. The bug is specific
> to ip6erspan_changelink() copying the wrong shape.
>
> Fixes: 5e72ce3e3980 ("net: ipv6: Use link netns in newlink() of rtnl_link_ops")
The changes look good to me. But why is 5e72ce3e3980 mentioned
here? It neither introduced nor was intended to fix this bug.
Thanks.
> Reported-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
> Cc: stable@vger.kernel.org # v5.15+
> Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
> ---
> net/ipv6/ip6_gre.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
> index dafcc0dcd..38ac14cc0 100644
> --- a/net/ipv6/ip6_gre.c
> +++ b/net/ipv6/ip6_gre.c
> @@ -2261,7 +2261,8 @@ static int ip6erspan_changelink(struct net_device *dev, struct nlattr *tb[],
> struct nlattr *data[],
> struct netlink_ext_ack *extack)
> {
> - struct ip6gre_net *ign = net_generic(dev_net(dev), ip6gre_net_id);
> + struct ip6_tnl *nt = netdev_priv(dev);
> + struct ip6gre_net *ign = net_generic(nt->net, ip6gre_net_id);
> struct __ip6_tnl_parm p;
> struct ip6_tnl *t;
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next] tcp: add sk->sk_synq_overflow_ts
From: Eric Dumazet @ 2026-04-29 1:58 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Neal Cardwell, Kuniyuki Iwashima, netdev,
eric.dumazet
In-Reply-To: <20260429014913.1043836-1-edumazet@google.com>
On Tue, Apr 28, 2026 at 6:49 PM Eric Dumazet <edumazet@google.com> wrote:
>
> tcp_synq_overflow() and tcp_synq_no_recent_overflow() are currently
> using tp->rx_opt.ts_recent_stamp to store a 32bit jiffie value.
>
> Use instead full "unsigned long" storage, as an union with sk->sk_stamp
> which is not used by a TCP listener.
>
> As a bonus, we can remove time_between32() from include/linux/time.h.
Please disregard this, I sent a wrong version of this patch.
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next 4/4] r8152: Add firmware upload capability for RTL8157/RTL8159
From: Andrew Lunn @ 2026-04-29 1:57 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260428-rtl8159_net_next-v1-4-52d03927b46f@birger-koblitz.de>
On Tue, Apr 28, 2026 at 05:47:24AM +0200, Birger Koblitz wrote:
> The RTL8159 requires firmware for its PHY in order to work at
> connection speeds > 5GBit. Add support for uploading firmware for
> the PHYs using the existing rtl8152_apply_firmware() function
> in r8157_hw_phy_cfg() and set up the correct names for the firmware
> files.
>
> If no firmware is found, both the RTL8157 and the RTL8159 will continue
> to work.
>
> Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
> ---
> drivers/net/usb/r8152.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 08cc3c1dae0facb2400890ba4d093c97ed56d40b..56e00fe6f32405ce753df3e03e54a7daaf1a29ac 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -4663,10 +4663,11 @@ static bool rtl8152_is_fw_phy_speed_up_ok(struct r8152 *tp, struct fw_phy_speed_
> case RTL_VER_11:
> case RTL_VER_12:
> case RTL_VER_14:
> - case RTL_VER_16:
> goto out;
> case RTL_VER_13:
> case RTL_VER_15:
> + case RTL_VER_16:
> + case RTL_VER_17:
Is that a bug fix?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/4] r8152: Add irq mitigation for RTL8157/9
From: Andrew Lunn @ 2026-04-29 1:56 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260428-rtl8159_net_next-v1-3-52d03927b46f@birger-koblitz.de>
On Tue, Apr 28, 2026 at 05:47:23AM +0200, Birger Koblitz wrote:
> Add interrupt mitigation code for both RTL8157 and RTL8159 that prevents
> USB interrupt callbacks with urb->status ESHUTDOWN being triggered. While the
> issue is rarely seen on the RTL8157, without the mitigation, it is
> common on the RTL8159:
> [273.561863] r8152 7-1:1.0 enx88c9b3b5xxxx: Stop submitting intr, status -108
>
> Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
> ---
> drivers/net/usb/r8152.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 8255261d73148a7b4dabe0188faf07cb1f356437..08cc3c1dae0facb2400890ba4d093c97ed56d40b 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -8444,6 +8444,12 @@ static void r8156_init(struct r8152 *tp)
> else
> r8153_u2p3en(tp, false);
>
> + if (tp->version >= RTL_VER_16) {
> + /* Disable Interrupt Mitigation */
> + ocp_byte_clr_bits(tp, MCU_TYPE_USB, 0xcf04,
> + BIT(0) | BIT(1) | BIT(2) | BIT(7));
> + }
What does interrupt mitigation do?
Is this a different name for interrupt coalescence, where the MAC
delays interrupts for a period of time so more packets are in the
receive ring when it does interrupt, so reducing the number of
interrupts, and bigger bursts of packets are processed at once?
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/4] r8152: Add support for 10Gbit Link Speeds and EEE
From: Andrew Lunn @ 2026-04-29 1:53 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260428-rtl8159_net_next-v1-1-52d03927b46f@birger-koblitz.de>
On Tue, Apr 28, 2026 at 05:47:21AM +0200, Birger Koblitz wrote:
> The RTL8159 supports 10GBit Link speeds. Add support for this speed
> in the setup and setting/getting through ethtool. Also add 10GBit EEE.
> Add functionality for setup and ethtool get/set methods.
>
> Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/4] r8152: Add support for the RTL8159 chip
From: Andrew Lunn @ 2026-04-29 1:52 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260428-rtl8159_net_next-v1-2-52d03927b46f@birger-koblitz.de>
> @@ -3431,6 +3432,7 @@ static void rtl8152_nic_reset(struct r8152 *tp)
> ocp_word_clr_bits(tp, MCU_TYPE_USB, USB_USB_CTRL, CDC_ECM_EN);
> break;
>
> + case RTL_VER_17:
> case RTL_VER_16:
> ocp_byte_clr_bits(tp, MCU_TYPE_PLA, PLA_CR, CR_RE | CR_TE);
nitpick. The other switch statements seem to be sorted. So 17 should
be after 16.
> + /* Power level tuning */
> + // test mode power level
> + sram_write_w0w1(tp, 0x8415, 0xff00, 0x9300);
> + // normal link power level 10G, 5G, 2.5G
> + sram_write_w0w1(tp, 0x81a3, 0xff00, 0x0f00);
> + sram_write_w0w1(tp, 0x81ae, 0xff00, 0x0f00);
> + sram_write_w0w1(tp, 0x81b9, 0xff00, 0xb900);
> + //nomal link TX filter
normal? Please also add a space after the //. netdev also prefers /*
*/.
> + /* XG INRX parameters */
> + // RC coefficients
> + sram2_write(tp, 0x84ac, 0x0000);
> + sram2_write(tp, 0x84ae, 0x0000);
> + sram2_write(tp, 0x84b0, 0xf818);
> + sram2_write_w0w1(tp, 0x84b2, 0xff00, 0x6000);
> + //Training AAGC PAR (with uc2 patch)
space
> +static int r8159_wait_backup_restore(struct r8152 *tp)
> +{
> + u32 ocp_data;
> +
> + ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_MISC_0);
> + if (!(ocp_data & PCUT_STATUS))
> + return 0;
> +
> + return poll_timeout_us(ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_GPHY_CTRL),
> + ocp_data & BACKUP_RESTRORE, 200, 2000, false);
> +}
> +
> static void r8156_init(struct r8152 *tp)
> @@ -8221,6 +8421,9 @@ static void r8156_init(struct r8152 *tp)
> return;
> }
>
> + if (tp->version == RTL_VER_17 && r8159_wait_backup_restore(tp))
> + return;
You should probably do something with the return value from
r8159_wait_backup_restore(). At minimum a dev_err().
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net 0/4] mptcp: misc fixes for v7.1-rc2
From: patchwork-bot+netdevbpf @ 2026-04-29 1:50 UTC (permalink / raw)
To: Matthieu Baerts
Cc: martineau, geliang, davem, edumazet, kuba, pabeni, horms, fw,
netdev, mptcp, linux-kernel, yangang, stable, sashiko-bot, lance
In-Reply-To: <20260427-net-mptcp-misc-fixes-7-1-rc2-v1-0-7432b7f279fa@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 21:54:32 +0200 you wrote:
> Here are various unrelated fixes:
>
> - Patches 1-2: set timestamp flags on 'ssk', not 'sk' (typo); Plus do
> that with sleepable lock_sock/release_sock. A fix for v5.14.
>
> - Patch 3: respect SO_LINGER(1, 0) by sending MP_FASTCLOSE at close time
> as expected. A fix for v6.1.
>
> [...]
Here is the summary with links:
- [net,1/4] mptcp: sockopt: set timestamp flags on subflow socket, not msk
https://git.kernel.org/netdev/net/c/5f95c21fc23a
- [net,2/4] mptcp: fix scheduling with atomic in timestamp sockopt
https://git.kernel.org/netdev/net/c/b5c52908d52c
- [net,3/4] mptcp: fastclose msk when linger time is 0
https://git.kernel.org/netdev/net/c/f14d6e9c3678
- [net,4/4] mptcp: pm: kernel: reset fullmesh counter after flush
https://git.kernel.org/netdev/net/c/1774d3cf3cf1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net-next] tcp: add sk->sk_synq_overflow_ts
From: Eric Dumazet @ 2026-04-29 1:49 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Neal Cardwell, Kuniyuki Iwashima, netdev,
eric.dumazet, Eric Dumazet
tcp_synq_overflow() and tcp_synq_no_recent_overflow() are currently
using tp->rx_opt.ts_recent_stamp to store a 32bit jiffie value.
Use instead full "unsigned long" storage, as an union with sk->sk_stamp
which is not used by a TCP listener.
As a bonus, we can remove time_between32() from include/linux/time.h.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/time.h | 13 ---------
include/net/sock.h | 5 +++-
include/net/sock_reuseport.h | 2 +-
include/net/tcp.h | 56 ++++++++++++------------------------
4 files changed, 24 insertions(+), 52 deletions(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index 16cf4522d6f338176f1fa753360e8bdec2c7bc8d..7554e44ea4a9472d306c770e2e6d2907ef5f244a 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -84,19 +84,6 @@ static inline bool itimerspec64_valid(const struct itimerspec64 *its)
#define time_after32(a, b) ((s32)((u32)(b) - (u32)(a)) < 0)
#define time_before32(b, a) time_after32(a, b)
-/**
- * time_between32 - check if a 32-bit timestamp is within a given time range
- * @t: the time which may be within [l,h]
- * @l: the lower bound of the range
- * @h: the higher bound of the range
- *
- * time_before32(t, l, h) returns true if @l <= @t <= @h. All operands are
- * treated as 32-bit integers.
- *
- * Equivalent to !(time_before32(@t, @l) || time_after32(@t, @h)).
- */
-#define time_between32(t, l, h) ((u32)(h) - (u32)(l) >= (u32)(t) - (u32)(l))
-
# include <vdso/time.h>
#endif
diff --git a/include/net/sock.h b/include/net/sock.h
index dccd3738c3687056b67c8de44fce9842dcc365ec..ed1e52de43c3394fae74f45a85527dec08c7ec48 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -548,7 +548,10 @@ struct sock {
struct pid *sk_peer_pid;
const struct cred *sk_peer_cred;
- ktime_t sk_stamp;
+ union {
+ ktime_t sk_stamp;
+ unsigned long sk_synq_overflow_ts; /* tcp_synq_overflow */
+ };
#if BITS_PER_LONG==32
seqlock_t sk_stamp_seq;
#endif
diff --git a/include/net/sock_reuseport.h b/include/net/sock_reuseport.h
index 6e4faf3ee76fbd86e2c4ac6ff13ead5c9a9187d6..a6beda5dca40777e27ef071d777081fd8af6ea03 100644
--- a/include/net/sock_reuseport.h
+++ b/include/net/sock_reuseport.h
@@ -20,7 +20,7 @@ struct sock_reuseport {
/* The last synq overflow event timestamp of this
* reuse->socks[] group.
*/
- unsigned int synq_overflow_ts;
+ unsigned long synq_overflow_ts;
/* ID stays the same even after the size of socks[] grows. */
unsigned int reuseport_id;
unsigned int bind_inany:1;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index ecbadcb3a7446cb18c245e670ba49ff574dfaff7..78ca1e336321da50953e6268c4a5d5185eb7791a 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -634,56 +634,38 @@ struct bpf_tcp_req_attrs {
*/
static inline void tcp_synq_overflow(const struct sock *sk)
{
- unsigned int last_overflow;
- unsigned int now = jiffies;
-
- if (sk->sk_reuseport) {
- struct sock_reuseport *reuse;
-
- reuse = rcu_dereference(sk->sk_reuseport_cb);
- if (likely(reuse)) {
- last_overflow = READ_ONCE(reuse->synq_overflow_ts);
- if (!time_between32(now, last_overflow,
- last_overflow + HZ))
- WRITE_ONCE(reuse->synq_overflow_ts, now);
- return;
- }
- }
+ unsigned long last_overflow, now = jiffies;
+ struct sock_reuseport *reuse;
+ unsigned long *ptr;
+
+ reuse = sk->sk_reuseport ? rcu_dereference(sk->sk_reuseport_cb) : NULL;
+ ptr = reuse ? &reuse->synq_overflow_ts : &((struct sock *)sk)->sk_synq_overflow_ts;
+ last_overflow = READ_ONCE(*ptr);
- last_overflow = READ_ONCE(tcp_sk(sk)->rx_opt.ts_recent_stamp);
- if (!time_between32(now, last_overflow, last_overflow + HZ))
- WRITE_ONCE(tcp_sk_rw(sk)->rx_opt.ts_recent_stamp, now);
+ if (time_after(now, last_overflow + HZ))
+ WRITE_ONCE(*ptr, now);
}
/* syncookies: no recent synqueue overflow on this listening socket? */
static inline bool tcp_synq_no_recent_overflow(const struct sock *sk)
{
- unsigned int last_overflow;
- unsigned int now = jiffies;
-
- if (sk->sk_reuseport) {
- struct sock_reuseport *reuse;
-
- reuse = rcu_dereference(sk->sk_reuseport_cb);
- if (likely(reuse)) {
- last_overflow = READ_ONCE(reuse->synq_overflow_ts);
- return !time_between32(now, last_overflow - HZ,
- last_overflow +
- TCP_SYNCOOKIE_VALID);
- }
- }
+ unsigned long last_overflow, now = jiffies;
+ const struct sock_reuseport *reuse;
+ const unsigned long *ptr;
- last_overflow = READ_ONCE(tcp_sk(sk)->rx_opt.ts_recent_stamp);
+ reuse = sk->sk_reuseport ? rcu_dereference(sk->sk_reuseport_cb) : NULL;
+ ptr = reuse ? &reuse->synq_overflow_ts : &sk->sk_synq_overflow_ts;
+ last_overflow = READ_ONCE(*ptr);
/* If last_overflow <= jiffies <= last_overflow + TCP_SYNCOOKIE_VALID,
* then we're under synflood. However, we have to use
* 'last_overflow - HZ' as lower bound. That's because a concurrent
- * tcp_synq_overflow() could update .ts_recent_stamp after we read
- * jiffies but before we store .ts_recent_stamp into last_overflow,
+ * tcp_synq_overflow() could update synq_overflow_ts after we read
+ * jiffies but before we store synq_overflow_ts into last_overflow,
* which could lead to rejecting a valid syncookie.
*/
- return !time_between32(now, last_overflow - HZ,
- last_overflow + TCP_SYNCOOKIE_VALID);
+ return !time_in_range(now, last_overflow - HZ,
+ last_overflow + TCP_SYNCOOKIE_VALID);
}
static inline u32 tcp_cookie_time(void)
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [PATCH net-next] net/mlx5: Add MLX5_VXLAN config option
From: Jakub Kicinski @ 2026-04-29 1:46 UTC (permalink / raw)
To: Marc Harvey
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni, netdev,
linux-rdma, linux-kernel, Kuniyuki Iwashima
In-Reply-To: <20260428-mlx5_vxlan-v1-1-cf666d042618@google.com>
On Tue, 28 Apr 2026 22:44:34 +0000 Marc Harvey wrote:
> Currently, there is no way to disable mlx5 vxlan offloading if vxlan
> is enabled. We've (possibly) seen some minor udp rr and udp stream
> regressions when enabling vxlan, and want a way to disable this
> offloading. Also coupling vxlan offloading with vxlan enablement
> generally limits the flexability of vxlan setups.
>
> Add a new config option for mlx5 vxlan offloading specifically, so
> that users can use vxlan without automatically opting in to the
> offloading.
>
> To keep the same behavior as before, the new config option is enabled
> by default if vxlan is enabled.
Can we delay init of whatever makes the device slow down until the
first vxlan port is registered? A kconfig level optimization of this
sort will have rather limited applicability.
^ permalink raw reply
* Re: [PATCH net-next 3/3] psp: validate IPv4 header fields in psp_dev_rcv()
From: Jakub Kicinski @ 2026-04-29 1:43 UTC (permalink / raw)
To: Willem de Bruijn
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms,
daniel.zahka
In-Reply-To: <willemdebruijn.kernel.223eebd28b57a@gmail.com>
On Tue, 28 Apr 2026 20:22:34 -0400 Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > psp_dev_rcv() is called from the NIC driver's RX completion path
> > before the frame reaches ip_rcv_core(), so the IP header has not
> > been validated in SW, yet. We expect that the device has done
> > all this validation, but let's also add the SW checks, to avoid
> > surprises.
>
> If devices are expected to have verified this, should these be more
> noisy checks, similar to netdev_rx_csum_fault?
Maybe "expect" is a bit of a strong word, I meant "anticipate" /
"suspect". Dropping invalid packet in SW doesn't seem like a huge
problem, other paths in this function already do. For rx csum the
problem is that we got a incorrectly math'ed out value for what is
likely a valid packet.
That's just to explain my thinking, if you prefer we warn / dump skb
I can respin.
^ permalink raw reply
* Re: [PATCH net-next v7 4/4] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: Andrew Lunn @ 2026-04-29 1:41 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms
In-Reply-To: <20260427072603.1191-1-lizhi2@eswincomputing.com>
> +&gmac1 {
> + phy-handle = <&gmac1_phy0>;
> + /*
> + * For the TX path of gmac1, there is a skew between the TX clock
> + * and data on the MAC controller inside the silicon. This skew happens
> + * to be approximately 2 ns. Therefore, it can be considered that the
> + * 2 ns delay of TX is provided by the MAC.
> + * No delay configuration for tx is needed in software via PHY driver.
> + */
> + phy-mode = "rgmii-rxid";
This is wrong. Take a read of
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
phy-mode describes the board. If the board provides the 2ns delay, you
use rgmii. If the MAC/PHY pair needs to provide the delay, you using
rgmii-id.
If rgmii-id is used, it is up to the MAC/PHY to decide which will add
the delay. If the MAC adds the delay, it needs to mask the value of
phy-mode it passes to the PHY so it does not also add the delay.
Your broken hardware means you cannot support 'rgmii' or 'rgmii-rx',
since you cannot turn off this 2ns delay, so you end up with double
delays if anybody designs a board with 2ns TX delay on the board
itself. So please validate the PHY modes and return -EINVAL if these
modes are used.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next] ppp: add PPPOX symbol
From: patchwork-bot+netdevbpf @ 2026-04-29 1:40 UTC (permalink / raw)
To: Qingfang Deng
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, julianbraha,
ebiggers, netdev, linux-kernel, linux-ppp
In-Reply-To: <20260428012830.3069-1-qingfang.deng@linux.dev>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 28 Apr 2026 09:28:26 +0800 you wrote:
> Add a dedicated CONFIG_PPPOX symbol to handle the PPPoX generic module,
> avoiding redundant pppox.o definitions in the Makefile.
>
> Signed-off-by: Qingfang Deng <qingfang.deng@linux.dev>
> ---
> drivers/net/ppp/Kconfig | 6 ++++++
> drivers/net/ppp/Makefile | 6 +++---
> 2 files changed, 9 insertions(+), 3 deletions(-)
Here is the summary with links:
- [net-next] ppp: add PPPOX symbol
https://git.kernel.org/netdev/net-next/c/09942ddedcb9
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 v2 0/4] netconsole: configfs store callback fixes
From: patchwork-bot+netdevbpf @ 2026-04-29 1:40 UTC (permalink / raw)
To: Breno Leitao
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, k-keiichi, satyam,
akpm, thepacketgeek, asantostc, gustavold, netdev, linux-kernel,
kernel-team, horms
In-Reply-To: <20260427-netconsole_ai_fixes-v2-0-59965f29d9cc@debian.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 07:30:34 -0700 you wrote:
> V2 for issues in netconsole's configfs store callbacks.
>
> There are still some changes I want to make, such as, having the dynamic
> lock when reading from configfs (_show() callbacks), wich will solve
> other issues, but I will keep it for later.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
>
> [...]
Here is the summary with links:
- [net,v2,1/4] netconsole: return count instead of strnlen(buf, count) from store callbacks
https://git.kernel.org/netdev/net/c/d62c6f2df5c0
- [net,v2,2/4] netconsole: avoid clobbering userdatum value on truncated write
https://git.kernel.org/netdev/net/c/e6dd94252b0f
- [net,v2,3/4] netconsole: propagate device name truncation in dev_name_store()
https://git.kernel.org/netdev/net/c/92ceb7bff62c
- [net,v2,4/4] netconsole: restore userdatum value on update_userdata() failure
https://git.kernel.org/netdev/net/c/869cd6490faf
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 0/5] net/sched: sch_cake: annotate data-races in cake_dump_stats() (series)
From: patchwork-bot+netdevbpf @ 2026-04-29 1:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, jhs, jiri, toke, netdev, eric.dumazet
In-Reply-To: <20260427083606.459355-1-edumazet@google.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 08:36:01 +0000 you wrote:
> cake_dump_stats() runs without qdisc spinlock being held.
>
> This mini series adds missing READ_ONCE()/WRITE_ONCE() annotations.
>
> Original patch was too big, splitting it eases code review.
>
> Eric Dumazet (5):
> net/sched: sch_cake: annotate data-races in cake_dump_stats() (I)
> net/sched: sch_cake: annotate data-races in cake_dump_stats() (II)
> net/sched: sch_cake: annotate data-races in cake_dump_stats() (III)
> net/sched: sch_cake: annotate data-races in cake_dump_stats() (IV)
> net/sched: sch_cake: annotate data-races in cake_dump_stats() (V)
>
> [...]
Here is the summary with links:
- [v2,net,1/5] net/sched: sch_cake: annotate data-races in cake_dump_stats() (I)
https://git.kernel.org/netdev/net/c/44967ac3785e
- [v2,net,2/5] net/sched: sch_cake: annotate data-races in cake_dump_stats() (II)
https://git.kernel.org/netdev/net/c/91a96427b93b
- [v2,net,3/5] net/sched: sch_cake: annotate data-races in cake_dump_stats() (III)
https://git.kernel.org/netdev/net/c/276a98a43496
- [v2,net,4/5] net/sched: sch_cake: annotate data-races in cake_dump_stats() (IV)
https://git.kernel.org/netdev/net/c/8fab48d87745
- [v2,net,5/5] net/sched: sch_cake: annotate data-races in cake_dump_stats() (V)
https://git.kernel.org/netdev/net/c/a6c95b833dc1
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] net: dummy: do not acquire RTNL for too long
From: patchwork-bot+netdevbpf @ 2026-04-29 1:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, netdev, eric.dumazet
In-Reply-To: <20260427091016.737015-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 09:10:16 +0000 you wrote:
> Instead of holding RTNL for an arbitrary amount of time,
> call register_netdev() for each dummy device created
> at module loading time.
>
> Tested:
>
> modprobe dummy numdummies=10000
>
> [...]
Here is the summary with links:
- [net-next] net: dummy: do not acquire RTNL for too long
https://git.kernel.org/netdev/net-next/c/bed510e44095
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 v2] net: psp: check for device unregister when creating assoc
From: patchwork-bot+netdevbpf @ 2026-04-29 1:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms,
yimingqian591, willemb, daniel.zahka, willemdebruijn.kernel
In-Reply-To: <20260427190606.366101-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 12:06:06 -0700 you wrote:
> psp_assoc_device_get_locked() obtains a psp_dev reference via
> psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU);
> it then acquires psd->lock and drops the reference. Before
> the lock is taken, psp_dev_unregister() can run to completion:
> take psd->lock, clear out state, unlock, drop the registration
> reference.
>
> [...]
Here is the summary with links:
- [net,v2] net: psp: check for device unregister when creating assoc
https://git.kernel.org/netdev/net/c/b89769f936a8
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 v2 0/2] sctp: fix a vtag verification failure caused by stale INITs
From: patchwork-bot+netdevbpf @ 2026-04-29 1:30 UTC (permalink / raw)
To: Xin Long
Cc: netdev, netfilter-devel, linux-sctp, davem, kuba, edumazet,
pabeni, horms, pablo, fw, phil, marcelo.leitner, yiche.cy
In-Reply-To: <cover.1777214801.git.lucien.xin@gmail.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 26 Apr 2026 10:46:39 -0400 you wrote:
> Similar to Scenario B in commit 8e56b063c865 ( netfilter: handle the
> connecting collision properly in nf_conntrack_proto_sctp"):
>
> Scenario B: INIT_ACK is delayed until the peer completes its own handshake
>
> 192.168.1.2 > 192.168.1.1: sctp (1) [INIT] [init tag: 3922216408]
> 192.168.1.1 > 192.168.1.2: sctp (1) [INIT] [init tag: 144230885]
> 192.168.1.2 > 192.168.1.1: sctp (1) [INIT ACK] [init tag: 3922216408]
> 192.168.1.1 > 192.168.1.2: sctp (1) [COOKIE ECHO]
> 192.168.1.2 > 192.168.1.1: sctp (1) [COOKIE ACK]
> 192.168.1.1 > 192.168.1.2: sctp (1) [INIT ACK] [init tag: 3914796021] *
>
> [...]
Here is the summary with links:
- [net,v2,1/2] netfilter: skip recording stale or retransmitted INIT
https://git.kernel.org/netdev/net/c/576a5d2bad48
- [net,v2,2/2] sctp: discard stale INIT after handshake completion
https://git.kernel.org/netdev/net/c/8a92cb475ca9
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/8] netfilter: arp_tables: fix IEEE1394 ARP payload parsing
From: patchwork-bot+netdevbpf @ 2026-04-29 1:30 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, kuba, pabeni, edumazet, fw, horms
In-Reply-To: <20260428095840.51961-2-pablo@netfilter.org>
Hello:
This series was applied to netdev/net.git (main)
by Pablo Neira Ayuso <pablo@netfilter.org>:
On Tue, 28 Apr 2026 11:58:32 +0200 you wrote:
> Weiming Shi says:
>
> "arp_packet_match() unconditionally parses the ARP payload assuming two
> hardware addresses are present (source and target). However,
> IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address
> field, and arp_hdr_len() already accounts for this by returning a
> shorter length for ARPHRD_IEEE1394 devices.
>
> [...]
Here is the summary with links:
- [net,1/8] netfilter: arp_tables: fix IEEE1394 ARP payload parsing
https://git.kernel.org/netdev/net/c/1e8e3f449b1e
- [net,2/8] netfilter: nf_tables: use list_del_rcu for netlink hooks
https://git.kernel.org/netdev/net/c/f3224ee463f8
- [net,3/8] rculist: add list_splice_rcu() for private lists
https://git.kernel.org/netdev/net/c/f902877b6355
- [net,4/8] netfilter: nf_tables: join hook list via splice_list_rcu() in commit phase
https://git.kernel.org/netdev/net/c/a6134e62dba2
- [net,5/8] netfilter: nf_tables: add hook transactions for device deletions
https://git.kernel.org/netdev/net/c/10f79dbd7719
- [net,6/8] netfilter: xt_policy: fix strict mode inbound policy matching
https://git.kernel.org/netdev/net/c/4b2b4d7d4e20
- [net,7/8] netfilter: reject zero shift in nft_bitwise
https://git.kernel.org/netdev/net/c/fe11e5c40817
- [net,8/8] netfilter: nf_conntrack_sip: don't use simple_strtoul
https://git.kernel.org/netdev/net/c/8cf6809cddcb
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] bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()
From: patchwork-bot+netdevbpf @ 2026-04-29 1:30 UTC (permalink / raw)
To: Weiming Shi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, willemb,
martin.varghese, netdev, xmei5
In-Reply-To: <20260426165350.1663137-2-bestswngs@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 26 Apr 2026 09:53:51 -0700 you wrote:
> bareudp_fill_metadata_dst() passes bareudp->sock to
> udp_tunnel6_dst_lookup() in the IPv6 path without a NULL check.
> The socket is only created in bareudp_open() and NULLed in
> bareudp_stop(), so calling this function while the device is down
> triggers a NULL dereference via sock->sk.
>
> BUG: kernel NULL pointer dereference, address: 0000000000000018
> RIP: 0010:udp_tunnel6_dst_lookup (net/ipv6/ip6_udp_tunnel.c:160)
> Call Trace:
> <TASK>
> bareudp_fill_metadata_dst (drivers/net/bareudp.c:532)
> do_execute_actions (net/openvswitch/actions.c:901)
> ovs_execute_actions (net/openvswitch/actions.c:1589)
> ovs_packet_cmd_execute (net/openvswitch/datapath.c:700)
> genl_family_rcv_msg_doit (net/netlink/genetlink.c:1114)
> genl_rcv_msg (net/netlink/genetlink.c:1209)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> </TASK>
>
> [...]
Here is the summary with links:
- [net] bareudp: fix NULL pointer dereference in bareudp_fill_metadata_dst()
https://git.kernel.org/netdev/net/c/aa6c6d9ee064
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: psp: require admin permission for dev-set and key-rotate
From: patchwork-bot+netdevbpf @ 2026-04-29 1:30 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms,
daniel.zahka, willemdebruijn.kernel, donald.hunter
In-Reply-To: <20260427195856.401223-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 27 Apr 2026 12:58:56 -0700 you wrote:
> The dev-set and key-rotate netlink operations modify shared device
> state (PSP version configuration and cryptographic key material,
> respectively) but do not require CAP_NET_ADMIN. The only access
> control is psp_dev_check_access() which merely verifies netns
> membership.
>
> Fixes: 00c94ca2b99e ("psp: base PSP device support")
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> [...]
Here is the summary with links:
- [net] net: psp: require admin permission for dev-set and key-rotate
https://git.kernel.org/netdev/net/c/b718342a7fba
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 v7 1/4] dt-bindings: ethernet: eswin: add clock sampling control
From: Andrew Lunn @ 2026-04-29 1:28 UTC (permalink / raw)
To: lizhi2
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, Conor Dooley
In-Reply-To: <20260427072439.1134-1-lizhi2@eswincomputing.com>
> For the TX path of eth1, there is also a skew between the TX clock
> and data on the MAC controller inside the silicon. This skew happens
> to be approximately 2 ns. Therefore, it can be considered that the
> 2 ns delay of TX is provided by the MAC, so the TX is compliant with
> the RGMII standard.
> tx-internal-delay-ps:
> - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> + minimum: 0
> + maximum: 2540
> + multipleOf: 20
This does not seem correct for eth1. Isn't minimum 2000, maximum 4540?
You have this fixed 2ns you cannot turn off.
Andrew
^ 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