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

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

[Ido Schimmel]

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.

[1] https://lore.kernel.org/netdev/c28ded3224734ca62187ed9a41f7ab39ceecb610.camel@fejes.dev/
[2] https://lore.kernel.org/netdev/20260923161756.2914560-1-idosch@nvidia.com/

Ido Schimmel (3):
  ipv6: Report netns cookie in fib6_table_lookup tracepoint
  ipv4: Pass netns to fib_table_lookup()
  ipv4: Report netns cookie in fib_table_lookup tracepoint

 include/net/ip_fib.h        | 12 +++++++-----
 include/trace/events/fib.h  | 12 ++++++++----
 include/trace/events/fib6.h |  8 ++++++--
 net/core/filter.c           |  2 +-
 net/ipv4/devinet.c          |  3 ++-
 net/ipv4/fib_frontend.c     |  6 ++++--
 net/ipv4/fib_rules.c        |  2 +-
 net/ipv4/fib_semantics.c    |  2 +-
 net/ipv4/fib_trie.c         | 16 +++++++++-------
 9 files changed, 39 insertions(+), 24 deletions(-)

-- 
2.55.0

[PATCH net-next 1/3] ipv6: Report netns cookie in fib6_table_lookup tracepoint

[Ido Schimmel]

The first argument of the tracepoint is a pointer to the network
namespace in which the FIB lookup was performed, but the tracepoint does
not report information about it in the associated trace record, making
it impossible to tell apart lookups performed in different namespaces.

Report the network namespace cookie, as commit 27cb3de7f43a ("net: add
net cookie for net device trace events") did for the net device
tracepoints.

Assisted-by: LLM
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 include/trace/events/fib6.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/fib6.h b/include/trace/events/fib6.h
index 8d22b2e98d48..e58facd2d7d4 100644
--- a/include/trace/events/fib6.h
+++ b/include/trace/events/fib6.h
@@ -34,6 +34,7 @@ TRACE_EVENT(fib6_table_lookup,
 		__field(        u8,	rt_type		)
 		__array(		char,	name,	IFNAMSIZ )
 		__array(		__u8,	gw,	16	 )
+		__field(	u64,	net_cookie	)
 	),
 
 	TP_fast_assign(
@@ -76,13 +77,16 @@ TRACE_EVENT(fib6_table_lookup,
 			in6 = (struct in6_addr *)__entry->gw;
 			*in6 = res->nh->fib_nh_gw6;
 		}
+
+		__entry->net_cookie = net->net_cookie;
 	),
 
-	TP_printk("table %3u oif %d iif %d proto %u %pI6c/%u -> %pI6c/%u flowlabel %#x tos %d scope %d flags %x ==> dev %s gw %pI6c err %d",
+	TP_printk("table %3u oif %d iif %d proto %u %pI6c/%u -> %pI6c/%u flowlabel %#x tos %d scope %d flags %x ==> dev %s gw %pI6c err %d net_cookie %llu",
 		  __entry->tb_id, __entry->oif, __entry->iif, __entry->proto,
 		  __entry->src, __entry->sport, __entry->dst, __entry->dport,
 		  __entry->flowlabel, __entry->tos, __entry->scope,
-		  __entry->flags, __entry->name, __entry->gw, __entry->err)
+		  __entry->flags, __entry->name, __entry->gw, __entry->err,
+		  __entry->net_cookie)
 );
 
 #endif /* _TRACE_FIB6_H */
-- 
2.55.0

[PATCH net-next 2/3] ipv4: Pass netns to fib_table_lookup()

[Ido Schimmel]

The next patch will report the network namespace cookie in the
fib_table_lookup tracepoint. As a preparation, pass the namespace to
fib_table_lookup() and from there to the tracepoint, like the
fib6_table_lookup tracepoint. All the callers already have the namespace
at hand.

Note that this changes the tracepoint prototype, so raw tracepoint BPF
programs that access the arguments by position need to be adjusted.

No functional changes intended.

Assisted-by: LLM
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 include/net/ip_fib.h       | 12 +++++++-----
 include/trace/events/fib.h |  4 ++--
 net/core/filter.c          |  2 +-
 net/ipv4/devinet.c         |  3 ++-
 net/ipv4/fib_frontend.c    |  6 ++++--
 net/ipv4/fib_rules.c       |  2 +-
 net/ipv4/fib_semantics.c   |  2 +-
 net/ipv4/fib_trie.c        | 16 +++++++++-------
 8 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index 0a35355fb0f3..fb446f01a65d 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -275,8 +275,9 @@ struct fib_dump_filter {
 	struct net_device	*dev;
 };
 
-int fib_table_lookup(struct fib_table *tb, const struct flowi4 *flp,
-		     struct fib_result *res, int fib_flags);
+int fib_table_lookup(struct net *net, struct fib_table *tb,
+		     const struct flowi4 *flp, struct fib_result *res,
+		     int fib_flags);
 int fib_table_insert(struct net *, struct fib_table *, struct fib_config *,
 		     struct netlink_ext_ack *extack);
 int fib_table_delete(struct net *, struct fib_table *, struct fib_config *,
@@ -323,7 +324,8 @@ static inline int fib_lookup(struct net *net, const struct flowi4 *flp,
 
 	tb = fib_get_table(net, RT_TABLE_MAIN);
 	if (tb)
-		err = fib_table_lookup(tb, flp, res, flags | FIB_LOOKUP_NOREF);
+		err = fib_table_lookup(net, tb, flp, res,
+				       flags | FIB_LOOKUP_NOREF);
 
 	if (err == -EAGAIN)
 		err = -ENETUNREACH;
@@ -387,14 +389,14 @@ static inline int fib_lookup(struct net *net, struct flowi4 *flp,
 
 	tb = rcu_dereference_rtnl(net->ipv4.fib_main);
 	if (tb)
-		err = fib_table_lookup(tb, flp, res, flags);
+		err = fib_table_lookup(net, tb, flp, res, flags);
 
 	if (err != -EAGAIN)
 		goto out;
 
 	tb = rcu_dereference_rtnl(net->ipv4.fib_default);
 	if (tb)
-		err = fib_table_lookup(tb, flp, res, flags);
+		err = fib_table_lookup(net, tb, flp, res, flags);
 
 	if (err == -EAGAIN)
 		err = -ENETUNREACH;
diff --git a/include/trace/events/fib.h b/include/trace/events/fib.h
index feb28b359eff..9a88060aa92e 100644
--- a/include/trace/events/fib.h
+++ b/include/trace/events/fib.h
@@ -14,10 +14,10 @@
 
 TRACE_EVENT(fib_table_lookup,
 
-	TP_PROTO(u32 tb_id, const struct flowi4 *flp,
+	TP_PROTO(const struct net *net, u32 tb_id, const struct flowi4 *flp,
 		 const struct fib_nh_common *nhc, int err),
 
-	TP_ARGS(tb_id, flp, nhc, err),
+	TP_ARGS(net, tb_id, flp, nhc, err),
 
 	TP_STRUCT__entry(
 		__field(	u32,	tb_id		)
diff --git a/net/core/filter.c b/net/core/filter.c
index 70dc621672f2..3ee1a093337e 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -6413,7 +6413,7 @@ static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params,
 		if (unlikely(!tb))
 			return BPF_FIB_LKUP_RET_NOT_FWDED;
 
-		err = fib_table_lookup(tb, &fl4, &res, FIB_LOOKUP_NOREF);
+		err = fib_table_lookup(net, tb, &fl4, &res, FIB_LOOKUP_NOREF);
 	} else {
 		if (flags & BPF_FIB_LOOKUP_MARK)
 			fl4.flowi4_mark = params->mark;
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index e84d3cf92247..efcd9fc88139 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -157,7 +157,8 @@ struct net_device *__ip_dev_find(struct net *net, __be32 addr, bool devref)
 		 */
 		local = fib_get_table(net, RT_TABLE_LOCAL);
 		if (local &&
-		    !fib_table_lookup(local, &fl4, &res, FIB_LOOKUP_NOREF) &&
+		    !fib_table_lookup(net, local, &fl4, &res,
+				      FIB_LOOKUP_NOREF) &&
 		    res.type == RTN_LOCAL)
 			result = FIB_RES_DEV(res);
 	} else {
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 8a3dc04e8cac..c80c1b36f1fd 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -243,7 +243,8 @@ static inline unsigned int __inet_dev_addr_type(struct net *net,
 	table = fib_get_table(net, tb_id);
 	if (table) {
 		ret = RTN_UNICAST;
-		if (!fib_table_lookup(table, &fl4, &res, FIB_LOOKUP_NOREF)) {
+		if (!fib_table_lookup(net, table, &fl4, &res,
+				      FIB_LOOKUP_NOREF)) {
 			struct fib_nh_common *nhc = fib_info_nhc(res.fi, 0);
 
 			if (!dev || dev == nhc->nhc_dev)
@@ -1400,7 +1401,8 @@ static void nl_fib_lookup(struct net *net, struct fib_result_nl *frn)
 		local_bh_disable();
 
 		frn->tb_id = tb->tb_id;
-		frn->err = fib_table_lookup(tb, &fl4, &res, FIB_LOOKUP_NOREF);
+		frn->err = fib_table_lookup(net, tb, &fl4, &res,
+					    FIB_LOOKUP_NOREF);
 
 		if (!frn->err) {
 			frn->prefixlen = res.prefixlen;
diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index 060501b376a8..28ba35125383 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -136,7 +136,7 @@ INDIRECT_CALLABLE_SCOPE int fib4_rule_action(struct fib_rule *rule,
 	tb_id = fib_rule_get_table(rule, arg);
 	tbl = fib_get_table(rule->fr_net, tb_id);
 	if (tbl)
-		err = fib_table_lookup(tbl, &flp->u.ip4,
+		err = fib_table_lookup(rule->fr_net, tbl, &flp->u.ip4,
 				       (struct fib_result *)arg->result,
 				       arg->flags);
 
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index e3bcc25229b0..f064bee79806 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1222,7 +1222,7 @@ static int fib_check_nh_v4_gw(struct net *net, struct fib_nh *nh, u32 table,
 			tbl = fib_get_table(net, table);
 
 		if (tbl)
-			err = fib_table_lookup(tbl, &fl4, &res,
+			err = fib_table_lookup(net, tbl, &fl4, &res,
 					       FIB_LOOKUP_IGNORE_LINKSTATE |
 					       FIB_LOOKUP_NOREF);
 
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index acb1e4385914..6ab95e19b3cf 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1417,8 +1417,9 @@ bool fib_lookup_good_nhc(const struct fib_nh_common *nhc, int fib_flags,
 }
 
 /* should be called with rcu_read_lock */
-int fib_table_lookup(struct fib_table *tb, const struct flowi4 *flp,
-		     struct fib_result *res, int fib_flags)
+int fib_table_lookup(struct net *net, struct fib_table *tb,
+		     const struct flowi4 *flp, struct fib_result *res,
+		     int fib_flags)
 {
 	struct trie *t = (struct trie *) tb->tb_data;
 #ifdef CONFIG_IP_FIB_TRIE_STATS
@@ -1435,7 +1436,7 @@ int fib_table_lookup(struct fib_table *tb, const struct flowi4 *flp,
 
 	n = get_child_rcu(pn, cindex);
 	if (!n) {
-		trace_fib_table_lookup(tb->tb_id, flp, NULL, -EAGAIN);
+		trace_fib_table_lookup(net, tb->tb_id, flp, NULL, -EAGAIN);
 		return -EAGAIN;
 	}
 
@@ -1521,8 +1522,9 @@ int fib_table_lookup(struct fib_table *tb, const struct flowi4 *flp,
 				 * further nodes to parse.
 				 */
 				if (IS_TRIE(pn)) {
-					trace_fib_table_lookup(tb->tb_id, flp,
-							       NULL, -EAGAIN);
+					trace_fib_table_lookup(net, tb->tb_id,
+							       flp, NULL,
+							       -EAGAIN);
 					return -EAGAIN;
 				}
 #ifdef CONFIG_IP_FIB_TRIE_STATS
@@ -1569,7 +1571,7 @@ int fib_table_lookup(struct fib_table *tb, const struct flowi4 *flp,
 #ifdef CONFIG_IP_FIB_TRIE_STATS
 			this_cpu_inc(stats->semantic_match_passed);
 #endif
-			trace_fib_table_lookup(tb->tb_id, flp, NULL, err);
+			trace_fib_table_lookup(net, tb->tb_id, flp, NULL, err);
 			return err;
 		}
 		if (fi->fib_flags & RTNH_F_DEAD)
@@ -1610,7 +1612,7 @@ int fib_table_lookup(struct fib_table *tb, const struct flowi4 *flp,
 #ifdef CONFIG_IP_FIB_TRIE_STATS
 			this_cpu_inc(stats->semantic_match_passed);
 #endif
-			trace_fib_table_lookup(tb->tb_id, flp, nhc, err);
+			trace_fib_table_lookup(net, tb->tb_id, flp, nhc, err);
 
 			return err;
 		}
-- 
2.55.0

Re: [PATCH net-next 2/3] ipv4: Pass netns to fib_table_lookup()

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0 (1)

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] This patch adds `const struct net *net` as the new first
  argument of the fib_table_lookup tracepoint.

Pre-existing issues:
- [Low] This problem wasn't introduced by this patch, but the
  fib_table_lookup trace event's TP_fast_assign leaves `__entry->gw4` (4…

--

ipv4: Pass netns to fib_table_lookup()

This commit adds a struct net argument to fib_table_lookup(). It passes
that argument as the new first argument of the fib_table_lookup
tracepoint and updates all callers. The next patch will use it to report
the netns cookie in the tracepoint.

> diff --git a/include/trace/events/fib.h b/include/trace/events/fib.h
> index feb28b359eff2..9a88060aa92e1 100644
> --- a/include/trace/events/fib.h
> +++ b/include/trace/events/fib.h
> @@ -14,10 +14,10 @@
>  
>  TRACE_EVENT(fib_table_lookup,
>  
> -	TP_PROTO(u32 tb_id, const struct flowi4 *flp,
> +	TP_PROTO(const struct net *net, u32 tb_id, const struct flowi4 *flp,
>  		 const struct fib_nh_common *nhc, int err),
>  
> -	TP_ARGS(tb_id, flp, nhc, err),
> +	TP_ARGS(net, tb_id, flp, nhc, err),

[Severity: Medium]
Does the raw_tp_null_args[] table in kernel/bpf/btf.c need to change
along with this prototype? It still has:

kernel/bpf/btf.c:raw_tp_null_args[] {
    ...
	/* fib */
	{ "fib_table_lookup", 0x100 },
    ...
}

btf_ctx_access() applies this mask by argument position. It does this
after skipping the hidden __data argument:

	if (raw_tp_null_args[i].mask & (0x1ULL << (arg * 4)))
		info->reg_type |= PTR_MAYBE_NULL;

Now that net sits at position 0, 0x100 marks arg 2 (flp) as
PTR_MAYBE_NULL. nhc has moved to arg 3 and is no longer marked nullable.

nhc can be NULL at runtime. fib_table_lookup() in net/ipv4/fib_trie.c
passes NULL for it on both -EAGAIN paths and on the out_reject path:

	trace_fib_table_lookup(net, tb->tb_id, flp, NULL, -EAGAIN);

For tp_btf programs, the verifier would then treat nhc as a trusted
non-NULL pointer. It would accept code that uses nhc without a NULL
check.

The verifier would also reject valid programs that read flp fields
directly. check_mem_access() only allows direct PTR_TO_BTF_ID access when
!type_may_be_null(reg->type). Programs would be rejected even after they
are updated for the new argument order, as the commit message asks.

Should the entry become { "fib_table_lookup", 0x1000 } in this patch?

The later "ipv4: Report netns cookie in fib_table_lookup tracepoint"
patch in the series does not seem to change it. This also seems to
contradict the "No functional changes intended" line in the commit
message.

>  
>  	TP_STRUCT__entry(
>  		__field(	u32,	tb_id		)

[Severity: Low]
This is a pre-existing issue and was not introduced by this patch. In
this event, TP_fast_assign() seems to leave gw4 and gw6 unset when nhc
is non-NULL and its gateway family is neither AF_INET nor AF_INET6:

	if (nhc) {
		if (nhc->nhc_gw_family == AF_INET) {
			...
		} else if (nhc->nhc_gw_family == AF_INET6) {
			...
		}
	} else {
		p32 = (__be32 *) __entry->gw4;
		*p32 = 0;
		...
	}

This happens for gateway-less routes, such as the local and connected
routes that fib_magic() sets up. For those routes, fib_nh_init() copies
a gateway family of 0 into the nexthop.

TP_printk() always prints both arrays with "gw %pI4/%pI6c". The event
payload is not cleared when it is reserved, so can this print stale bytes
left by earlier events?

trace_buffered_event_enable() also allocates its per-CPU buffered-event
page without __GFP_ZERO. Can up to 20 bytes of old page contents reach
trace readers that way?

Would it make sense to zero gw4 and gw6 before the family-specific
assignments?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261006155454.853588-1-idosch%40nvidia.com

Re: [PATCH net-next 2/3] ipv4: Pass netns to fib_table_lookup()

[Ido Schimmel]

On Wed, Oct 07, 2026 at 11:16:47PM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 0 (1)
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] This patch adds `const struct net *net` as the new first
>   argument of the fib_table_lookup tracepoint.
> 
> Pre-existing issues:
> - [Low] This problem wasn't introduced by this patch, but the
>   fib_table_lookup trace event's TP_fast_assign leaves `__entry->gw4` (4…
> 
> --
> 
> ipv4: Pass netns to fib_table_lookup()
> 
> This commit adds a struct net argument to fib_table_lookup(). It passes
> that argument as the new first argument of the fib_table_lookup
> tracepoint and updates all callers. The next patch will use it to report
> the netns cookie in the tracepoint.
> 
> > diff --git a/include/trace/events/fib.h b/include/trace/events/fib.h
> > index feb28b359eff2..9a88060aa92e1 100644
> > --- a/include/trace/events/fib.h
> > +++ b/include/trace/events/fib.h
> > @@ -14,10 +14,10 @@
> >  
> >  TRACE_EVENT(fib_table_lookup,
> >  
> > -	TP_PROTO(u32 tb_id, const struct flowi4 *flp,
> > +	TP_PROTO(const struct net *net, u32 tb_id, const struct flowi4 *flp,
> >  		 const struct fib_nh_common *nhc, int err),
> >  
> > -	TP_ARGS(tb_id, flp, nhc, err),
> > +	TP_ARGS(net, tb_id, flp, nhc, err),
> 
> [Severity: Medium]
> Does the raw_tp_null_args[] table in kernel/bpf/btf.c need to change
> along with this prototype? It still has:
> 
> kernel/bpf/btf.c:raw_tp_null_args[] {
>     ...
> 	/* fib */
> 	{ "fib_table_lookup", 0x100 },
>     ...
> }
> 
> btf_ctx_access() applies this mask by argument position. It does this
> after skipping the hidden __data argument:
> 
> 	if (raw_tp_null_args[i].mask & (0x1ULL << (arg * 4)))
> 		info->reg_type |= PTR_MAYBE_NULL;
> 
> Now that net sits at position 0, 0x100 marks arg 2 (flp) as
> PTR_MAYBE_NULL. nhc has moved to arg 3 and is no longer marked nullable.
> 
> nhc can be NULL at runtime. fib_table_lookup() in net/ipv4/fib_trie.c
> passes NULL for it on both -EAGAIN paths and on the out_reject path:
> 
> 	trace_fib_table_lookup(net, tb->tb_id, flp, NULL, -EAGAIN);
> 
> For tp_btf programs, the verifier would then treat nhc as a trusted
> non-NULL pointer. It would accept code that uses nhc without a NULL
> check.
> 
> The verifier would also reject valid programs that read flp fields
> directly. check_mem_access() only allows direct PTR_TO_BTF_ID access when
> !type_may_be_null(reg->type). Programs would be rejected even after they
> are updated for the new argument order, as the commit message asks.
> 
> Should the entry become { "fib_table_lookup", 0x1000 } in this patch?

I will simply make 'net' the last tracepoint argument. It will be
inconsistent with the IPv6 tracepoint, but it will avoid this problem
and won't break BPF programs that attach to the raw tracepoint.

> 
> The later "ipv4: Report netns cookie in fib_table_lookup tracepoint"
> patch in the series does not seem to change it. This also seems to
> contradict the "No functional changes intended" line in the commit
> message.
> 
> >  
> >  	TP_STRUCT__entry(
> >  		__field(	u32,	tb_id		)
> 
> [Severity: Low]
> This is a pre-existing issue and was not introduced by this patch. In
> this event, TP_fast_assign() seems to leave gw4 and gw6 unset when nhc
> is non-NULL and its gateway family is neither AF_INET nor AF_INET6:
> 
> 	if (nhc) {
> 		if (nhc->nhc_gw_family == AF_INET) {
> 			...
> 		} else if (nhc->nhc_gw_family == AF_INET6) {
> 			...
> 		}
> 	} else {
> 		p32 = (__be32 *) __entry->gw4;
> 		*p32 = 0;
> 		...
> 	}
> 
> This happens for gateway-less routes, such as the local and connected
> routes that fib_magic() sets up. For those routes, fib_nh_init() copies
> a gateway family of 0 into the nexthop.
> 
> TP_printk() always prints both arrays with "gw %pI4/%pI6c". The event
> payload is not cleared when it is reserved, so can this print stale bytes
> left by earlier events?
> 
> trace_buffered_event_enable() also allocates its per-CPU buffered-event
> page without __GFP_ZERO. Can up to 20 bytes of old page contents reach
> trace readers that way?
> 
> Would it make sense to zero gw4 and gw6 before the family-specific
> assignments?

Pre-existing. I will take care of it separately.

pw-bot: cr

> 
> -- 
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261006155454.853588-1-idosch%40nvidia.com

[PATCH net-next 3/3] ipv4: Report netns cookie in fib_table_lookup tracepoint

[Ido Schimmel]

The fib_table_lookup tracepoint does not report the network namespace in
which the lookup was performed, making it impossible to tell apart
lookups performed in different namespaces.

Report the network namespace cookie now that the namespace is passed to
the tracepoint.

Assisted-by: LLM
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 include/trace/events/fib.h | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/fib.h b/include/trace/events/fib.h
index 9a88060aa92e..7852e9ba3861 100644
--- a/include/trace/events/fib.h
+++ b/include/trace/events/fib.h
@@ -35,6 +35,7 @@ TRACE_EVENT(fib_table_lookup,
 		__field(	u16,	sport		)
 		__field(	u16,	dport		)
 		__array(char,  name,   IFNAMSIZ )
+		__field(	u64,	net_cookie	)
 	),
 
 	TP_fast_assign(
@@ -90,13 +91,16 @@ TRACE_EVENT(fib_table_lookup,
 			in6 = (struct in6_addr *)__entry->gw6;
 			*in6 = in6addr_any;
 		}
+
+		__entry->net_cookie = net->net_cookie;
 	),
 
-	TP_printk("table %u oif %d iif %d proto %u %pI4/%u -> %pI4/%u tos %d scope %d flags %x ==> dev %s gw %pI4/%pI6c err %d",
+	TP_printk("table %u oif %d iif %d proto %u %pI4/%u -> %pI4/%u tos %d scope %d flags %x ==> dev %s gw %pI4/%pI6c err %d net_cookie %llu",
 		  __entry->tb_id, __entry->oif, __entry->iif, __entry->proto,
 		  __entry->src, __entry->sport, __entry->dst, __entry->dport,
 		  __entry->tos, __entry->scope, __entry->flags,
-		  __entry->name, __entry->gw4, __entry->gw6, __entry->err)
+		  __entry->name, __entry->gw4, __entry->gw6, __entry->err,
+		  __entry->net_cookie)
 );
 #endif /* _TRACE_FIB_H */
 
-- 
2.55.0

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

[Ferenc Fejes]

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

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

[Ido Schimmel]

On Wed, Oct 07, 2026 at 02:34:51PM +0200, Ferenc Fejes wrote:
> 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 :-)

Linus is asking maintainers to limit the rc pull requests to regression
/ security fixes, so it's unlikely that such a change would be routed
via the "net" tree.

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

Thanks!