Re: [PATCH nf,v2] netfilter: flowtable: tear down flow entries with stale dst from GC

On Sun, Jul 12, 2026 at 07:39:25AM -0600, Ahmed Zaki wrote:
> On Sat, Jul 11, 2026 at 3:02 PM Pablo Neira Ayuso <[email protected]> wrote:
> >
> .
> 
> > > I am testing this patch and keep getting some splats. I am testing
> > > with a MTK7621 hw which
> > > to my understanding, marks the tuple's xmit_type DIRECT (not neigh or XFRM).
> > >
> > > In nft_dev_forward_path(), out.h_source is set and this overrides the
> > > dst_cache (same union)
> > > this seems to be causing the splat when the dst_cache is dereferenced.
> > > (btw, not like his patch,
> > > in the latest HEAD, nf_flow_dst_check() guards tuple->dst_****  by
> > > checks on xmit_type)
> >
> > We have move dst_cache out of the union quite recently so... (see below)
> >
> > > So, to support DIRECT types, we can:
> > > 1 - go back to my v1 patch (no dependency on dst_cache)
> > > 2 - same patch but use dst_check() only for NEIGH/XFRM
> > > 3 - or maybe we can have the dst_cache out of the union and available
> > > for all xmit_types.
> > >
> > > I have some time to work on this, let me know if I can help.
> >
> > ... probably you are missing this series? They got merged quite
> > recently, I am not sure what tree you are using as reference:
> 
> yeah, I was looking at nf-next. These seem to be in nf only as of now.

OK.

> > fa7395c02d95 netfilter: flowtable: support IPIP tunnel with direct xmit
> > 6c5dcab95f4c netfilter: flowtable: IPIP tunnel hardware offload is not yet support
> > c328b90c17fc netfilter: flowtable: use dst in this direction when pushing IPIP header
> >
> > There is also this patch which is needed:
> >
> > https://patchwork.ozlabs.org/project/netfilter-devel/patch/[email protected]/
> >
> > which has been included in the last PR this Friday.
> 
> I have some limitations so I can only test with 6.6 or 6.12. I will
> try to trim down these patches to
> "move dst_cache out of union and use the gc to check all entries" and
> will let you know if I see
> any more problems.

You will have to backport the move of dst_cache out of the union.

> The one thing I believe is still missing is to remove the if condition
> in flow_offload_fill_route()
> when setting  "flow_tuple->dst_cache/dst_cookie":
> 
> - if (route->tuple[!dir].in.num_tuns) {
> 
> We now need "flow_tuple->dst_cache/dst_cookie" for all DIRECT xmit
> even with no tunnels

How so? ->dst_cache is not available when sending packets to a port
behind a master bridge device.