netdev - Re: [PATCH net-next ct-offload v3 13/15] net/mlx5e: CT: Offload established flows

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 for Android: free password hash cracker in your pocket

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

Message-ID: <d883b801-2325-f3b3-c60d-257484dbfff0@solarflare.com>
Date:   Wed, 11 Mar 2020 17:45:01 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Paul Blakey <paulb@...lanox.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Oz Shlomo <ozsh@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Vlad Buslov <vladbu@...lanox.com>,
        "David Miller" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>, Roi Dayan <roid@...lanox.com>
Subject: Re: [PATCH net-next ct-offload v3 13/15] net/mlx5e: CT: Offload
 established flows

On 11/03/2020 14:33, Paul Blakey wrote:
> Register driver callbacks with the nf flow table platform.
> FT add/delete events will create/delete FTE in the CT/CT_NAT tables.
>
> Restoring the CT state on miss will be added in the following patch.
>
> Signed-off-by: Paul Blakey <paulb@...lanox.com>
> Reviewed-by: Oz Shlomo <ozsh@...lanox.com>
> Reviewed-by: Roi Dayan <roid@...lanox.com>
> Reviewed-by: Jiri Pirko <jiri@...lanox.com>
> ---
<snip>
> +static int
> +mlx5_tc_ct_parse_mangle_to_mod_act(struct flow_action_entry *act,
> +				   char *modact)
> +{
> +	u32 offset = act->mangle.offset, field;
> +
> +	switch (act->mangle.htype) {
> +	case FLOW_ACT_MANGLE_HDR_TYPE_IP4:
> +		MLX5_SET(set_action_in, modact, length, 0);
> +		field = offset == offsetof(struct iphdr, saddr) ?
> +			MLX5_ACTION_IN_FIELD_OUT_SIPV4 :
> +			MLX5_ACTION_IN_FIELD_OUT_DIPV4;
Won't this mishandle any mangle of a field other than src/dst addr?

> +		break;
> +
> +	case FLOW_ACT_MANGLE_HDR_TYPE_IP6:
> +		MLX5_SET(set_action_in, modact, length, 0);
> +		if (offset == offsetof(struct ipv6hdr, saddr))
> +			field = MLX5_ACTION_IN_FIELD_OUT_SIPV6_31_0;
> +		else if (offset == offsetof(struct ipv6hdr, saddr) + 4)
> +			field = MLX5_ACTION_IN_FIELD_OUT_SIPV6_63_32;
> +		else if (offset == offsetof(struct ipv6hdr, saddr) + 8)
> +			field = MLX5_ACTION_IN_FIELD_OUT_SIPV6_95_64;
> +		else if (offset == offsetof(struct ipv6hdr, saddr) + 12)
> +			field = MLX5_ACTION_IN_FIELD_OUT_SIPV6_127_96;
> +		else if (offset == offsetof(struct ipv6hdr, daddr))
> +			field = MLX5_ACTION_IN_FIELD_OUT_DIPV6_31_0;
> +		else if (offset == offsetof(struct ipv6hdr, daddr) + 4)
> +			field = MLX5_ACTION_IN_FIELD_OUT_DIPV6_63_32;
> +		else if (offset == offsetof(struct ipv6hdr, daddr) + 8)
> +			field = MLX5_ACTION_IN_FIELD_OUT_DIPV6_95_64;
> +		else if (offset == offsetof(struct ipv6hdr, daddr) + 12)
> +			field = MLX5_ACTION_IN_FIELD_OUT_DIPV6_127_96;
> +		else
> +			return -EOPNOTSUPP;
> +		break;
> +
> +	case FLOW_ACT_MANGLE_HDR_TYPE_TCP:
> +		MLX5_SET(set_action_in, modact, length, 16);
> +		field = offset == offsetof(struct tcphdr, source) ?
> +			MLX5_ACTION_IN_FIELD_OUT_TCP_SPORT :
> +			MLX5_ACTION_IN_FIELD_OUT_TCP_DPORT;
Ditto.

> +		break;
> +
> +	case FLOW_ACT_MANGLE_HDR_TYPE_UDP:
> +		MLX5_SET(set_action_in, modact, length, 16);
> +		field = offset == offsetof(struct udphdr, source) ?
> +			MLX5_ACTION_IN_FIELD_OUT_UDP_SPORT :
> +			MLX5_ACTION_IN_FIELD_OUT_TCP_DPORT;
s/TCP/UDP/?

-ed