* [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
@ 2026-03-31 11:59 Fernando Fernandez Mancera
2026-03-31 12:13 ` Eric Dumazet
2026-03-31 17:35 ` Jakub Kicinski
0 siblings, 2 replies; 9+ messages in thread
From: Fernando Fernandez Mancera @ 2026-03-31 11:59 UTC (permalink / raw)
To: netdev
Cc: horms, pabeni, kuba, edumazet, davem, dsahern,
Fernando Fernandez Mancera, Yiming Qian
When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
single nexthops and small Equal-Cost Multi-Path groups, this fixed
allocation fails for large nexthop groups like 512+ nexthops.
This results in the following warning splat:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#19: rep/9282
[...]
RIP: 0010:rtm_get_nexthop+0x176/0x1c0
[...]
Call Trace:
<TASK>
rtnetlink_rcv_msg+0x168/0x670
netlink_rcv_skb+0x5c/0x110
netlink_unicast+0x203/0x2e0
netlink_sendmsg+0x222/0x460
____sys_sendmsg+0x35a/0x380
___sys_sendmsg+0x99/0xe0
__sys_sendmsg+0x8a/0xf0
do_syscall_64+0x12f/0x1590
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Fix this by allocating the size dynamically using nh_nlmsg_size(), this
is consistent with nexthop_notify() behavior. In addition, replace
alloc_skb() with nlmsg_new().
This cannot be reproduced via iproute2 as the group size is currently
limited and the command fails as follows:
addattr_l ERROR: message exceeded bound of 1048
Fixes: 430a049190de ("nexthop: Add support for nexthop groups")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Closes: https://lore.kernel.org/netdev/CAL_bE8Li2h4KO+AQFXW4S6Yb_u5X4oSKnkywW+LPFjuErhqELA@mail.gmail.com/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
Note: as this cannot be reproduced by iproute2 and a custom C script
is needed to trigger it, I do not think a selftest covering this corner
case is worth here.
---
net/ipv4/nexthop.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
index c942f1282236..b502c3ad41bf 100644
--- a/net/ipv4/nexthop.c
+++ b/net/ipv4/nexthop.c
@@ -3377,15 +3377,15 @@ static int rtm_get_nexthop(struct sk_buff *in_skb, struct nlmsghdr *nlh,
if (err)
return err;
- err = -ENOBUFS;
- skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!skb)
- goto out;
-
err = -ENOENT;
nh = nexthop_find_by_id(net, id);
if (!nh)
- goto errout_free;
+ goto out;
+
+ err = -ENOBUFS;
+ skb = nlmsg_new(nh_nlmsg_size(nh), GFP_KERNEL);
+ if (!skb)
+ goto out;
err = nh_fill_node(skb, nh, RTM_NEWNEXTHOP, NETLINK_CB(in_skb).portid,
nlh->nlmsg_seq, 0, op_flags);
--
2.53.0
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 11:59 [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() Fernando Fernandez Mancera
@ 2026-03-31 12:13 ` Eric Dumazet
2026-03-31 12:50 ` Fernando Fernandez Mancera
2026-03-31 17:35 ` Jakub Kicinski
1 sibling, 1 reply; 9+ messages in thread
From: Eric Dumazet @ 2026-03-31 12:13 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, kuba, davem, dsahern, Yiming Qian
On Tue, Mar 31, 2026 at 5:00 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
> single nexthops and small Equal-Cost Multi-Path groups, this fixed
> allocation fails for large nexthop groups like 512+ nexthops.
>
> This results in the following warning splat:
>
> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#19: rep/9282
> [...]
> RIP: 0010:rtm_get_nexthop+0x176/0x1c0
> [...]
> Call Trace:
> <TASK>
> rtnetlink_rcv_msg+0x168/0x670
> netlink_rcv_skb+0x5c/0x110
> netlink_unicast+0x203/0x2e0
> netlink_sendmsg+0x222/0x460
> ____sys_sendmsg+0x35a/0x380
> ___sys_sendmsg+0x99/0xe0
> __sys_sendmsg+0x8a/0xf0
> do_syscall_64+0x12f/0x1590
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
> </TASK>
I find these stack traces without symbols not very useful.
Any reason you have not used scripts/decode_stacktrace.sh ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 12:13 ` Eric Dumazet
@ 2026-03-31 12:50 ` Fernando Fernandez Mancera
2026-03-31 13:38 ` Eric Dumazet
0 siblings, 1 reply; 9+ messages in thread
From: Fernando Fernandez Mancera @ 2026-03-31 12:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, horms, pabeni, kuba, davem, dsahern, Yiming Qian
On 3/31/26 2:13 PM, Eric Dumazet wrote:
> On Tue, Mar 31, 2026 at 5:00 AM Fernando Fernandez Mancera
> <fmancera@suse.de> wrote:
>>
>> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
>> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
>> single nexthops and small Equal-Cost Multi-Path groups, this fixed
>> allocation fails for large nexthop groups like 512+ nexthops.
>>
>> This results in the following warning splat:
>>
>> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#19: rep/9282
>> [...]
>> RIP: 0010:rtm_get_nexthop+0x176/0x1c0
>> [...]
>> Call Trace:
>> <TASK>
>> rtnetlink_rcv_msg+0x168/0x670
>> netlink_rcv_skb+0x5c/0x110
>> netlink_unicast+0x203/0x2e0
>> netlink_sendmsg+0x222/0x460
>> ____sys_sendmsg+0x35a/0x380
>> ___sys_sendmsg+0x99/0xe0
>> __sys_sendmsg+0x8a/0xf0
>> do_syscall_64+0x12f/0x1590
>> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>> </TASK>
>
> I find these stack traces without symbols not very useful.
Hi Eric,
sure, here is the decoded trace:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0,
CPU#20: rep/4608
RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395 (discriminator 2))
Call Trace:
<TASK>
rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
netlink_unicast (net/netlink/af_netlink.c:1319
net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
____sys_sendmsg (net/socket.c:721 (discriminator 16) net/socket.c:736
(discriminator 16) net/socket.c:2585 (discriminator 16))
___sys_sendmsg (net/socket.c:2641)
__sys_sendmsg (net/socket.c:2671 (discriminator 1))
do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1)
arch/x86/entry/syscall_64.c:94 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
>
> Any reason you have not used scripts/decode_stacktrace.sh ?
>
Not really, in the past I checked other commits with `git log --grep
"Call Trace"` and found out that most of the traces did not have symbols
so I decided to attach the raw trace.
I do not really have a personal preference here. If trace with symbols
is preferred I will do it like that in the future. I could also send a
V2 of this patch if needed.
Thanks!
Fernando.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 12:50 ` Fernando Fernandez Mancera
@ 2026-03-31 13:38 ` Eric Dumazet
2026-03-31 14:38 ` Fernando Fernandez Mancera
0 siblings, 1 reply; 9+ messages in thread
From: Eric Dumazet @ 2026-03-31 13:38 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, kuba, davem, dsahern, Yiming Qian
On Tue, Mar 31, 2026 at 5:50 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> On 3/31/26 2:13 PM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 5:00 AM Fernando Fernandez Mancera
> > <fmancera@suse.de> wrote:
> >>
> >> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
> >> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
> >> single nexthops and small Equal-Cost Multi-Path groups, this fixed
> >> allocation fails for large nexthop groups like 512+ nexthops.
> >>
> >> This results in the following warning splat:
> >>
> >> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#19: rep/9282
> >> [...]
> >> RIP: 0010:rtm_get_nexthop+0x176/0x1c0
> >> [...]
> >> Call Trace:
> >> <TASK>
> >> rtnetlink_rcv_msg+0x168/0x670
> >> netlink_rcv_skb+0x5c/0x110
> >> netlink_unicast+0x203/0x2e0
> >> netlink_sendmsg+0x222/0x460
> >> ____sys_sendmsg+0x35a/0x380
> >> ___sys_sendmsg+0x99/0xe0
> >> __sys_sendmsg+0x8a/0xf0
> >> do_syscall_64+0x12f/0x1590
> >> entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >> </TASK>
> >
> > I find these stack traces without symbols not very useful.
>
> Hi Eric,
>
> sure, here is the decoded trace:
>
> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0,
> CPU#20: rep/4608
> RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395 (discriminator 2))
> Call Trace:
> <TASK>
> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> netlink_unicast (net/netlink/af_netlink.c:1319
> net/netlink/af_netlink.c:1344)
> netlink_sendmsg (net/netlink/af_netlink.c:1894)
> ____sys_sendmsg (net/socket.c:721 (discriminator 16) net/socket.c:736
> (discriminator 16) net/socket.c:2585 (discriminator 16))
> ___sys_sendmsg (net/socket.c:2641)
> __sys_sendmsg (net/socket.c:2671 (discriminator 1))
> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1)
> arch/x86/entry/syscall_64.c:94 (discriminator 1))
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
>
> >
> > Any reason you have not used scripts/decode_stacktrace.sh ?
> >
>
> Not really, in the past I checked other commits with `git log --grep
> "Call Trace"` and found out that most of the traces did not have symbols
> so I decided to attach the raw trace.
>
> I do not really have a personal preference here. If trace with symbols
> is preferred I will do it like that in the future. I could also send a
> V2 of this patch if needed.
Please send a V2 (after the ~24 hours delay) as we prefer this
whenever possible.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 13:38 ` Eric Dumazet
@ 2026-03-31 14:38 ` Fernando Fernandez Mancera
0 siblings, 0 replies; 9+ messages in thread
From: Fernando Fernandez Mancera @ 2026-03-31 14:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, horms, pabeni, kuba, davem, dsahern, Yiming Qian
On 3/31/26 3:38 PM, Eric Dumazet wrote:
> On Tue, Mar 31, 2026 at 5:50 AM Fernando Fernandez Mancera
> <fmancera@suse.de> wrote:
>>
>> On 3/31/26 2:13 PM, Eric Dumazet wrote:
>>> On Tue, Mar 31, 2026 at 5:00 AM Fernando Fernandez Mancera
>>> <fmancera@suse.de> wrote:
>>>>
>>>> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
>>>> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
>>>> single nexthops and small Equal-Cost Multi-Path groups, this fixed
>>>> allocation fails for large nexthop groups like 512+ nexthops.
>>>>
>>>> This results in the following warning splat:
>>>>
>>>> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#19: rep/9282
>>>> [...]
>>>> RIP: 0010:rtm_get_nexthop+0x176/0x1c0
>>>> [...]
>>>> Call Trace:
>>>> <TASK>
>>>> rtnetlink_rcv_msg+0x168/0x670
>>>> netlink_rcv_skb+0x5c/0x110
>>>> netlink_unicast+0x203/0x2e0
>>>> netlink_sendmsg+0x222/0x460
>>>> ____sys_sendmsg+0x35a/0x380
>>>> ___sys_sendmsg+0x99/0xe0
>>>> __sys_sendmsg+0x8a/0xf0
>>>> do_syscall_64+0x12f/0x1590
>>>> entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>> </TASK>
>>>
>>> I find these stack traces without symbols not very useful.
>>
>> Hi Eric,
>>
>> sure, here is the decoded trace:
>>
>> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0,
>> CPU#20: rep/4608
>> RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395 (discriminator 2))
>> Call Trace:
>> <TASK>
>> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
>> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
>> netlink_unicast (net/netlink/af_netlink.c:1319
>> net/netlink/af_netlink.c:1344)
>> netlink_sendmsg (net/netlink/af_netlink.c:1894)
>> ____sys_sendmsg (net/socket.c:721 (discriminator 16) net/socket.c:736
>> (discriminator 16) net/socket.c:2585 (discriminator 16))
>> ___sys_sendmsg (net/socket.c:2641)
>> __sys_sendmsg (net/socket.c:2671 (discriminator 1))
>> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1)
>> arch/x86/entry/syscall_64.c:94 (discriminator 1))
>> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
>> </TASK>
>>
>>>
>>> Any reason you have not used scripts/decode_stacktrace.sh ?
>>>
>>
>> Not really, in the past I checked other commits with `git log --grep
>> "Call Trace"` and found out that most of the traces did not have symbols
>> so I decided to attach the raw trace.
>>
>> I do not really have a personal preference here. If trace with symbols
>> is preferred I will do it like that in the future. I could also send a
>> V2 of this patch if needed.
>
> Please send a V2 (after the ~24 hours delay) as we prefer this
> whenever possible.
>
Yes, in addition nh_nlmsg_size() isn't accounting the bytes for stats
dump so this needs a v2 anyway.
Thanks,
Fernando.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 11:59 [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() Fernando Fernandez Mancera
2026-03-31 12:13 ` Eric Dumazet
@ 2026-03-31 17:35 ` Jakub Kicinski
2026-03-31 17:40 ` Fernando Fernandez Mancera
1 sibling, 1 reply; 9+ messages in thread
From: Jakub Kicinski @ 2026-03-31 17:35 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, edumazet, davem, dsahern, Yiming Qian
On Tue, 31 Mar 2026 13:59:43 +0200 Fernando Fernandez Mancera wrote:
> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
> single nexthops and small Equal-Cost Multi-Path groups, this fixed
> allocation fails for large nexthop groups like 512+ nexthops.
router_mpath_seed.sh says:
[ 9.366434] WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x181/0x1b0, CPU#0: ip/342
[ 9.366490] Modules linked in: vrf veth
[ 9.366519] CPU: 0 UID: 0 PID: 342 Comm: ip Not tainted 7.0.0-rc5-virtme #1 PREEMPT(lazy)
[ 9.366567] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 9.366610] RIP: 0010:rtm_get_nexthop+0x181/0x1b0
[ 9.366649] Code: 25 a7 ee ff eb 80 48 c7 c7 a0 ee af ae e8 57 30 f5 ff 4d 85 ed 74 08 49 c7 45 00 a0 ee af ae b8 ea ff ff ff e9 5d ff ff ff 90 <0f> 0b 90 ba 02 00 00 00 4c 89 ee 31 ff e8 2d 84 eb ff b8 a6 ff ff
[ 9.366754] RSP: 0018:ff5db175808bf9d8 EFLAGS: 00010286
[ 9.366790] RAX: 00000000ffffffa6 RBX: ff3c7cb941dab700 RCX: 0000000000000000
[ 9.366835] RDX: 0000000000000003 RSI: 0000000000000000 RDI: ff3c7cb94404a300
[ 9.366872] RBP: ff3c7cb94404a400 R08: ff3c7cb9413f25a8 R09: ff3c7cb94196cb40
[ 9.366916] R10: ff3c7cb94196ca00 R11: 000000000000000e R12: ffffffffaf8df6c0
[ 9.366967] R13: ff3c7cb94404a300 R14: ff3c7cb94525e180 R15: ff3c7cb94404a400
[ 9.367018] FS: 00007fa1f5261440(0000) GS:ff3c7cb9cf3fb000(0000) knlGS:0000000000000000
[ 9.367064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9.367102] CR2: 000000000044f720 CR3: 000000000573f001 CR4: 0000000000771ef0
[ 9.367149] PKRU: 55555554
[ 9.367165] Call Trace:
[ 9.367183] <TASK>
[ 9.367201] rtnetlink_rcv_msg+0x13a/0x3e0
[ 9.367227] ? get_page_from_freelist+0x1109/0x16c0
[ 9.367259] ? rtnl_calcit.isra.0+0x120/0x120
[ 9.367286] netlink_rcv_skb+0x59/0x100
[ 9.367310] netlink_unicast+0x255/0x380
[ 9.367333] netlink_sendmsg+0x1cc/0x3e0
[ 9.367356] ____sys_sendmsg+0x164/0x260
[ 9.367390] ___sys_sendmsg+0x99/0xe0
[ 9.367415] __sys_sendmsg+0x8a/0xe0
[ 9.367441] do_syscall_64+0x101/0xfc0
[ 9.367466] ? exc_page_fault+0x6e/0x170
[ 9.367493] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 9.367528] RIP: 0033:0x7fa1f53bbc5e
[ 9.367550] Code: 4d 89 d8 e8 34 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa
[ 9.367653] RSP: 002b:00007ffc00947ff0 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
[ 9.367700] RAX: ffffffffffffffda RBX: 000000000048ba90 RCX: 00007fa1f53bbc5e
[ 9.367744] RDX: 0000000000000000 RSI: 00007ffc009480b0 RDI: 0000000000000005
[ 9.367787] RBP: 00007ffc00948000 R08: 0000000000000000 R09: 0000000000000000
[ 9.367835] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000049d620
[ 9.367889] R13: 0000000069cbe823 R14: 0000000000000004 R15: 000000000049d620
decoded:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/forwarding/results/582821/vm-crash-thr4-1
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 17:35 ` Jakub Kicinski
@ 2026-03-31 17:40 ` Fernando Fernandez Mancera
2026-03-31 22:41 ` Jakub Kicinski
0 siblings, 1 reply; 9+ messages in thread
From: Fernando Fernandez Mancera @ 2026-03-31 17:40 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, horms, pabeni, edumazet, davem, dsahern, Yiming Qian
On 3/31/26 7:35 PM, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 13:59:43 +0200 Fernando Fernandez Mancera wrote:
>> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
>> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
>> single nexthops and small Equal-Cost Multi-Path groups, this fixed
>> allocation fails for large nexthop groups like 512+ nexthops.
>
> router_mpath_seed.sh says:
>
> [ 9.366434] WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x181/0x1b0, CPU#0: ip/342
> [ 9.366490] Modules linked in: vrf veth
> [ 9.366519] CPU: 0 UID: 0 PID: 342 Comm: ip Not tainted 7.0.0-rc5-virtme #1 PREEMPT(lazy)
> [ 9.366567] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 9.366610] RIP: 0010:rtm_get_nexthop+0x181/0x1b0
> [ 9.366649] Code: 25 a7 ee ff eb 80 48 c7 c7 a0 ee af ae e8 57 30 f5 ff 4d 85 ed 74 08 49 c7 45 00 a0 ee af ae b8 ea ff ff ff e9 5d ff ff ff 90 <0f> 0b 90 ba 02 00 00 00 4c 89 ee 31 ff e8 2d 84 eb ff b8 a6 ff ff
> [ 9.366754] RSP: 0018:ff5db175808bf9d8 EFLAGS: 00010286
> [ 9.366790] RAX: 00000000ffffffa6 RBX: ff3c7cb941dab700 RCX: 0000000000000000
> [ 9.366835] RDX: 0000000000000003 RSI: 0000000000000000 RDI: ff3c7cb94404a300
> [ 9.366872] RBP: ff3c7cb94404a400 R08: ff3c7cb9413f25a8 R09: ff3c7cb94196cb40
> [ 9.366916] R10: ff3c7cb94196ca00 R11: 000000000000000e R12: ffffffffaf8df6c0
> [ 9.366967] R13: ff3c7cb94404a300 R14: ff3c7cb94525e180 R15: ff3c7cb94404a400
> [ 9.367018] FS: 00007fa1f5261440(0000) GS:ff3c7cb9cf3fb000(0000) knlGS:0000000000000000
> [ 9.367064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 9.367102] CR2: 000000000044f720 CR3: 000000000573f001 CR4: 0000000000771ef0
> [ 9.367149] PKRU: 55555554
> [ 9.367165] Call Trace:
> [ 9.367183] <TASK>
> [ 9.367201] rtnetlink_rcv_msg+0x13a/0x3e0
> [ 9.367227] ? get_page_from_freelist+0x1109/0x16c0
> [ 9.367259] ? rtnl_calcit.isra.0+0x120/0x120
> [ 9.367286] netlink_rcv_skb+0x59/0x100
> [ 9.367310] netlink_unicast+0x255/0x380
> [ 9.367333] netlink_sendmsg+0x1cc/0x3e0
> [ 9.367356] ____sys_sendmsg+0x164/0x260
> [ 9.367390] ___sys_sendmsg+0x99/0xe0
> [ 9.367415] __sys_sendmsg+0x8a/0xe0
> [ 9.367441] do_syscall_64+0x101/0xfc0
> [ 9.367466] ? exc_page_fault+0x6e/0x170
> [ 9.367493] entry_SYSCALL_64_after_hwframe+0x4b/0x53
> [ 9.367528] RIP: 0033:0x7fa1f53bbc5e
> [ 9.367550] Code: 4d 89 d8 e8 34 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa
> [ 9.367653] RSP: 002b:00007ffc00947ff0 EFLAGS: 00000202 ORIG_RAX: 000000000000002e
> [ 9.367700] RAX: ffffffffffffffda RBX: 000000000048ba90 RCX: 00007fa1f53bbc5e
> [ 9.367744] RDX: 0000000000000000 RSI: 00007ffc009480b0 RDI: 0000000000000005
> [ 9.367787] RBP: 00007ffc00948000 R08: 0000000000000000 R09: 0000000000000000
> [ 9.367835] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000049d620
> [ 9.367889] R13: 0000000069cbe823 R14: 0000000000000004 R15: 000000000049d620
>
> decoded:
> https://netdev-ctrl.bots.linux.dev/logs/vmksft/forwarding/results/582821/vm-crash-thr4-1
Hi Jakub,
thanks for sharing. As I replied to Eric this is the main reason why a
V2 is needed. There is also another bug I discovered while fixing this.
When dumping the stats NHA_HW_STATS_ENABLE is being included twice per
group. I am fixing that in another patch that will be included on the V2
series.
Thanks,
Fernando.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 17:40 ` Fernando Fernandez Mancera
@ 2026-03-31 22:41 ` Jakub Kicinski
2026-04-01 7:18 ` Fernando Fernandez Mancera
0 siblings, 1 reply; 9+ messages in thread
From: Jakub Kicinski @ 2026-03-31 22:41 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, edumazet, davem, dsahern, Yiming Qian
On Tue, 31 Mar 2026 19:40:38 +0200 Fernando Fernandez Mancera wrote:
> thanks for sharing. As I replied to Eric this is the main reason why a
> V2 is needed. There is also another bug I discovered while fixing this.
> When dumping the stats NHA_HW_STATS_ENABLE is being included twice per
> group. I am fixing that in another patch that will be included on the V2
> series.
If you remember -- please try to slap a pw-bot: cr on your own reply
when you notice that a follow up is needed, especially if the patch
is breaking selftests. We still lack automation to attribute failures
and bad changes get stuck in the testing branch :(
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
2026-03-31 22:41 ` Jakub Kicinski
@ 2026-04-01 7:18 ` Fernando Fernandez Mancera
0 siblings, 0 replies; 9+ messages in thread
From: Fernando Fernandez Mancera @ 2026-04-01 7:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, horms, pabeni, edumazet, davem, dsahern, Yiming Qian
On 4/1/26 12:41 AM, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 19:40:38 +0200 Fernando Fernandez Mancera wrote:
>> thanks for sharing. As I replied to Eric this is the main reason why a
>> V2 is needed. There is also another bug I discovered while fixing this.
>> When dumping the stats NHA_HW_STATS_ENABLE is being included twice per
>> group. I am fixing that in another patch that will be included on the V2
>> series.
>
> If you remember -- please try to slap a pw-bot: cr on your own reply
> when you notice that a follow up is needed, especially if the patch
> is breaking selftests. We still lack automation to attribute failures
> and bad changes get stuck in the testing branch :(
Oh sure. Will do next time. Thanks Jakub!
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-04-01 7:18 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-31 11:59 [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() Fernando Fernandez Mancera
2026-03-31 12:13 ` Eric Dumazet
2026-03-31 12:50 ` Fernando Fernandez Mancera
2026-03-31 13:38 ` Eric Dumazet
2026-03-31 14:38 ` Fernando Fernandez Mancera
2026-03-31 17:35 ` Jakub Kicinski
2026-03-31 17:40 ` Fernando Fernandez Mancera
2026-03-31 22:41 ` Jakub Kicinski
2026-04-01 7:18 ` Fernando Fernandez Mancera
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox