Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()

[Fernando Fernandez Mancera <fmancera@suse.de>]

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.