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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 12 Mar 2020 00:29:48 +0200
From:   Paul Blakey <paulb@...lanox.com>
To:     Edward Cree <ecree@...arflare.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 19:45, Edward Cree wrote:
> 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?

Yes we didn't expect any other types, it was just the api of mangle.

ill add a else case.

>> +		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/?

yes

thanks will fix

>
> -ed