Re: [PATCH net-next 0/3] Report netns cookie in FIB lookup tracepoints

[Ferenc Fejes <ferenc@fejes.dev>]

On Tue, 2026-10-06 at 18:54 +0300, Ido Schimmel wrote:
> The fib:fib_table_lookup and fib6:fib6_table_lookup tracepoints do
> not
> report the network namespace in which the lookup was performed, so
> lookups performed in different namespaces cannot be told apart. The
> recorded PID does not help either, as lookups in the receive path are
> performed in softIRQ context.
> 
> This is a problem, for example, for netns-aware tracers [1] and
> multi-ASIC systems where each ASIC and its ports reside in a separate
> network namespace.
> 
> This patchset reports the network namespace cookie in both
> tracepoints,
> as commit 27cb3de7f43a ("net: add net cookie for net device trace
> events") did for the net device tracepoints. This allows filtering
> lookups performed in a specific network namespace, for example:
> 
>  # perf record -a -e fib:fib_table_lookup --filter 'net_cookie == 12'
> 
> The cookie of a given network namespace can be retrieved using "ip
> netns
> cookie" [2].
> 
> Patch #1 reports the cookie in the IPv6 tracepoint, which is already
> passed the network namespace.
> 
> Patch #2 passes the network namespace to fib_table_lookup() and from
> there to the IPv4 tracepoint.
> 
> Patch #3 reports the cookie in the IPv4 tracepoint.
> 
> 

Thank you! With the user-facing changes given net-next is 100%
justified.

I wonder if the parameter passing itself, e.g. the line
+int fib_table_lookup(struct net *net, struct fib_table *tb, ...
can be a standalone change. It would introduce no functional or user-
facing changes and could therefore target the "net" tree, with the
potential to be backported. Pure kfunc/kprobe-based eBPF tracers could
benefit from that, with the downside of introducing an unused variable.
I assume this would be a hard sell, to say the least :-)

For the whole set:
Reviewed-by: Ferenc Fejes <ferenc@fejes.dev>

Best,
Ferenc