netdev - Re: [PATCH v11 nf-next 6/6] netfilter: nft_flow_offload: Add bridgeflow to nft_flow_offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250411105751.GA1156507@horms.kernel.org>
Date: Fri, 11 Apr 2025 11:57:51 +0100
From: Simon Horman <horms@...nel.org>
To: Eric Woudstra <ericwouds@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	Jozsef Kadlecsik <kadlec@...filter.org>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	Ido Schimmel <idosch@...dia.com>,
	Kuniyuki Iwashima <kuniyu@...zon.com>,
	Stanislav Fomichev <sdf@...ichev.me>,
	Ahmed Zaki <ahmed.zaki@...el.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
	bridge@...ts.linux.dev
Subject: Re: [PATCH v11 nf-next 6/6] netfilter: nft_flow_offload: Add
 bridgeflow to nft_flow_offload_eval()

On Tue, Apr 08, 2025 at 04:28:02PM +0200, Eric Woudstra wrote:
> Edit nft_flow_offload_eval() to make it possible to handle a flowtable of
> the nft bridge family.
> 
> Use nft_flow_offload_bridge_init() to fill the flow tuples. It uses
> nft_dev_fill_bridge_path() in each direction.
> 
> Signed-off-by: Eric Woudstra <ericwouds@...il.com>
> ---
>  net/netfilter/nft_flow_offload.c | 148 +++++++++++++++++++++++++++++--
>  1 file changed, 143 insertions(+), 5 deletions(-)
> 
> diff --git a/net/netfilter/nft_flow_offload.c b/net/netfilter/nft_flow_offload.c

...

> +static int nft_dev_fill_bridge_path(struct flow_offload *flow,
> +				    struct nft_flowtable *ft,
> +				    enum ip_conntrack_dir dir,
> +				    const struct net_device *src_dev,
> +				    const struct net_device *dst_dev,
> +				    unsigned char *src_ha,
> +				    unsigned char *dst_ha)
> +{
> +	struct flow_offload_tuple_rhash *th = flow->tuplehash;
> +	struct net_device_path_ctx ctx = {};
> +	struct net_device_path_stack stack;
> +	struct nft_forward_info info = {};
> +	int i, j = 0;
> +
> +	for (i = th[dir].tuple.encap_num - 1; i >= 0 ; i--) {
> +		if (info.num_encaps >= NF_FLOW_TABLE_ENCAP_MAX)
> +			return -1;
> +
> +		if (th[dir].tuple.in_vlan_ingress & BIT(i))
> +			continue;
> +
> +		info.encap[info.num_encaps].id = th[dir].tuple.encap[i].id;
> +		info.encap[info.num_encaps].proto = th[dir].tuple.encap[i].proto;
> +		info.num_encaps++;
> +
> +		if (th[dir].tuple.encap[i].proto == htons(ETH_P_PPP_SES))
> +			continue;
> +
> +		if (ctx.num_vlans >= NET_DEVICE_PATH_VLAN_MAX)
> +			return -1;
> +		ctx.vlan[ctx.num_vlans].id = th[dir].tuple.encap[i].id;
> +		ctx.vlan[ctx.num_vlans].proto = th[dir].tuple.encap[i].proto;
> +		ctx.num_vlans++;
> +	}
> +	ctx.dev = src_dev;
> +	ether_addr_copy(ctx.daddr, dst_ha);
> +
> +	if (dev_fill_bridge_path(&ctx, &stack) < 0)
> +		return -1;
> +
> +	nft_dev_path_info(&stack, &info, dst_ha, &ft->data);
> +
> +	if (!info.indev || info.indev != dst_dev)
> +		return -1;
> +
> +	th[!dir].tuple.iifidx = info.indev->ifindex;
> +	for (i = info.num_encaps - 1; i >= 0; i--) {
> +		th[!dir].tuple.encap[j].id = info.encap[i].id;
> +		th[!dir].tuple.encap[j].proto = info.encap[i].proto;
> +		if (info.ingress_vlans & BIT(i))
> +			th[!dir].tuple.in_vlan_ingress |= BIT(j);
> +		j++;
> +	}
> +	th[!dir].tuple.encap_num = info.num_encaps;
> +
> +	th[dir].tuple.mtu = dst_dev->mtu;
> +	ether_addr_copy(th[dir].tuple.out.h_source, src_ha);
> +	ether_addr_copy(th[dir].tuple.out.h_dest, dst_ha);
> +	th[dir].tuple.out.ifidx = info.outdev->ifindex;
> +	th[dir].tuple.out.hw_ifidx = info.hw_outdev->ifindex;
> +	th[dir].tuple.out.bridge_vid = info.bridge_vid;

Hi Eric,

I guess I am doing something daft.
But with this patchset applied on top of nf-next I see
the following with allmodconfig builds on x86_64.:

  CC [M]  net/netfilter/nft_flow_offload.o
net/netfilter/nft_flow_offload.c: In function 'nft_dev_fill_bridge_path':
net/netfilter/nft_flow_offload.c:248:26: error: 'struct <anonymous>' has no member named 'bridge_vid'
  248 |         th[dir].tuple.out.bridge_vid = info.bridge_vid;
      |                          ^
net/netfilter/nft_flow_offload.c:248:44: error: 'struct nft_forward_info' has no member named 'bridge_vid'
  248 |         th[dir].tuple.out.bridge_vid = info.bridge_vid;
      |                                            ^

> +	th[dir].tuple.xmit_type = FLOW_OFFLOAD_XMIT_DIRECT;
> +
> +	return 0;
> +}

...