Re: [PATCH nf,v2] netfilter: flowtable: tear down flow entries with stale dst from GC
Pablo Neira Ayuso <[email protected]>
| Newsgroups | gmane.comp.security.firewalls.netfilter.devel |
|---|---|
| Message-ID | <alKvX-Q_v6ez4fV3@chamomile> |
Hi, On Fri, Jul 10, 2026 at 01:55:59PM -0600, Ahmed Zaki wrote: > On Fri, Jul 10, 2026 at 1:54 AM Pablo Neira Ayuso <[email protected]> wrote: > > > > In case of route updates, tear down flow entries with stale dst to give > > them a chance to obtain a fresh route. > > > > This is specifically useful for hardware offloaded entries, where the > > flowtable software dataplane sees no packet, where the existing check > > for stale dst entries does not help. > > > > Signed-off-by: Pablo Neira Ayuso <[email protected]> > > --- > > v2: - reuse nf_flow_dst_check(), move it to .h file > > - use correct logic in nf_flow_dst_check() from GC step > > > > This patch has been repurposed to the nf.git tree, because net-next.git is > > still missing a recent fix and I would like sashiko kicks it for review. > > So I am still leaning towards including this in nf-next. > > > > include/net/netfilter/nf_flow_table.h | 8 ++++++++ > > net/netfilter/nf_flow_table_core.c | 2 ++ > > net/netfilter/nf_flow_table_ip.c | 8 -------- > > 3 files changed, 10 insertions(+), 8 deletions(-) > > > > diff --git a/include/net/netfilter/nf_flow_table.h b/include/net/netfilter/nf_flow_table.h > > index ce414118962f..a090ec3ffef2 100644 > > --- a/include/net/netfilter/nf_flow_table.h > > +++ b/include/net/netfilter/nf_flow_table.h > > @@ -310,6 +310,14 @@ int flow_offload_add(struct nf_flowtable *flow_table, struct flow_offload *flow) > > void flow_offload_refresh(struct nf_flowtable *flow_table, > > struct flow_offload *flow, bool force); > > > > +static inline bool nf_flow_dst_check(struct flow_offload_tuple *tuple) > > +{ > > + if (!tuple->dst_cache) > > + return true; > > + > > + return dst_check(tuple->dst_cache, tuple->dst_cookie); > > +} > > 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: 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.