On 2021-07-11 1:59 PM, Roi Dayan wrote:

On 2021-07-07 5:50 PM, patchwork-bot+netdevbpf@kernel.org wrote:

quoted

Hello:

This patch was applied to iproute2/iproute2.git (refs/heads/main):

On Wed,  7 Jul 2021 15:22:01 +0300 you wrote:

quoted

We started to use in-kernel filtering feature which allows to get only
needed tables (see iproute_dump_filter()). From the kernel side it's
implemented in net/ipv4/fib_frontend.c (inet_dump_fib), 
net/ipv6/ip6_fib.c
(inet6_dump_fib). The problem here is that behaviour of "ip route save"
was changed after
c7e6371bc ("ip route: Add protocol, table id and device to dump 
request").
If filters are used, then kernel returns ENOENT error if requested table
is absent, but in newly created net namespace even RT_TABLE_MAIN table
doesn't exist. It is really allocated, for instance, after issuing
"ip l set lo up".

[...]

Here is the summary with links:
   - [PATCHv5,iproute2] ip route: ignore ENOENT during save if 
RT_TABLE_MAIN is being dumped
     
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=459ce6e3d792 


You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Hi,

I didn't get a chance to check but after this commit the utility ss
is crashing from libnetlink.c

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000418980 in rtnl_dump_done (a=0x7fffffffdc00, h=0x449c80) 
at libnetlink.c:734
#2  rtnl_dump_filter_l (rth=rth@entry=0x7fffffffdcf0, 
arg=arg@entry=0x7fffffffdc00) at libnetlink.c:893
#3  0x00000000004197a2 in rtnl_dump_filter_nc 
(rth=rth@entry=0x7fffffffdcf0, filter=filter@entry=0x40cdf0 
<show_one_inet_sock>,
     arg1=arg1@entry=0x7fffffffdca0, nc_flags=nc_flags@entry=0) at 
libnetlink.c:957
#4  0x0000000000406dc7 in inet_show_netlink (dump_fp=dump_fp@entry=0x0, 
protocol=protocol@entry=255, f=0x42e900 <current_filter>) at ss.c:3638
#5  0x0000000000404db3 in raw_show (f=0x42e900 <current_filter>) at 
ss.c:3939


if I revert this commit I can run the ss utility ok.

Thanks,
Roi

I found for me ss crashed using a->errhndlr but it could be null
in rtnl_dump_done()

I see a second usage of a->errhndlr in rtnl_dump_error()