Message-ID: <bdc4505c-6982-4f47-9ee4-b1f0911da16d@oracle.com>
Date: Wed, 14 Jan 2026 20:57:27 +0530
From: ALOK TIWARI <alok.a.tiwari@...cle.com>
To: "Kamakshi, NelloreX" <nellorex.kamakshi@...el.com>,
        "intel-wired-lan-bounces@...osl.org" <intel-wired-lan-bounces@...osl.org>,
        "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "Lobakin, Aleksander" <aleksander.lobakin@...el.com>
Cc: "pmenzel@...gen.mpg.de" <pmenzel@...gen.mpg.de>,
        "Kitszel, Przemyslaw" <przemyslaw.kitszel@...el.com>,
        "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "horms@...nel.org"
 <horms@...nel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "alok.a.tiwarilinux@...il.com" <alok.a.tiwarilinux@...il.com>
Subject: Re: [Intel-wired-lan] [PATCH v2 net] i40e: fix src IP mask checks and
 memcpy argument names in cloud filter



On 1/7/2026 11:29 AM, Kamakshi, NelloreX wrote:
> -----Original Message-----
> From: Intel-wired-lan<intel-wired-lan-bounces@...osl.org> On Behalf Of Alok Tiwari
> Sent: Tuesday, November 11, 2025 12:44 AM
> To:pmenzel@...gen.mpg.de; Kitszel, Przemyslaw<przemyslaw.kitszel@...el.com>; Lobakin, Aleksander<aleksander.lobakin@...el.com>; Nguyen, Anthony L<anthony.l.nguyen@...el.com>;andrew+netdev@...n.ch;kuba@...nel.org;davem@...emloft.net;edumazet@...gle.com;pabeni@...hat.com;horms@...nel.org;intel-wired-lan@...ts.osuosl.org;netdev@...r.kernel.org
> Cc:alok.a.tiwarilinux@...il.com;alok.a.tiwari@...cle.com
> Subject: [Intel-wired-lan] [PATCH v2 net] i40e: fix src IP mask checks and memcpy argument names in cloud filter
> 
> Fix following issues in the IPv4 and IPv6 cloud filter handling logic in both the add and delete paths:
> 
> - The source-IP mask check incorrectly compares mask.src_ip[0] against
>    tcf.dst_ip[0]. Update it to compare against tcf.src_ip[0]. This likely
>    goes unnoticed because the check is in an "else if" path that only
>    executes when dst_ip is not set, most cloud filter use cases focus on
>    destination-IP matching, and the buggy condition can accidentally
>    evaluate true in some cases.
> 
> - memcpy() for the IPv4 source address incorrectly uses
>    ARRAY_SIZE(tcf.dst_ip) instead of ARRAY_SIZE(tcf.src_ip), although
>    both arrays are the same size.
> 
> - The IPv4 memcpy operations used ARRAY_SIZE(tcf.dst_ip) and ARRAY_SIZE
>    (tcf.src_ip), Update these to use sizeof(cfilter->ip.v4.dst_ip) and
>    sizeof(cfilter->ip.v4.src_ip) to ensure correct and explicit copy size.
> 
> - In the IPv6 delete path, memcmp() uses sizeof(src_ip6) when comparing
>    dst_ip6 fields. Replace this with sizeof(dst_ip6) to make the intent
>    explicit, even though both fields are struct in6_addr.
> 
> Fixes: e284fc280473 ("i40e: Add and delete cloud filter")
> Signed-off-by: Alok Tiwari<alok.a.tiwari@...cle.com>
> Reviewed-by: Aleksandr Loktionov<aleksandr.loktionov@...el.com>
> Reviewed-by: Paul Menzel<pmenzel@...gen.mpg.de>
> ---
> v1 -> v2
> update patch subject line and replace ARRAY_SIZE with sizeof as suggested by Alex and added Reviewed-by Alex and Paul.
> ---
>   drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 14 +++++++-------
>   1 file changed, 7 insertions(+), 7 deletions(-)
> Unable able to create  Ipv4 and Ipv6 filter with src_ip as a match parameter. However filters are getting created with dst_ip.
> 
> Below are the commands I used to create the filters for IPV4 and IPV6.
> 
> tc filter add dev eth0 protocol ip parent ffff:  prio 1 flower dst_ip 1.1.1.1  ip_proto tcp dst_port 5000  skip_sw  hw_tc 2
> 
> tc filter add dev eth0 protocol ip parent ffff:  prio 1 flower src_ip 2.1.1.1  ip_proto tcp dst_port 5000  skip_sw  hw_tc 2
> RTNETLINK answers: Operation not supported
> We have an error talking to the kernel
> 
> tc filter add dev eth0 protocol ipv6 parent ffff: prio 1 flower dst_ip 2001:0db8:0:f101::11 ip_proto tcp dst_port 5200 skip_sw hw_tc 1
> 
> tc filter add dev eth0 protocol ipv6 parent ffff: prio 1 flower src_ip 2001:0db8:0:f101::12 ip_proto tcp dst_port 5200 skip_sw hw_tc 1
> RTNETLINK answers: Operation not supported
> We have an error talking to the kernel
> 
> Dmesg:
> i40e 0000:5e:00.0: Failed to add cloud filter, err -95
> i40e 0000:5e:00.0: Failed to add cloud filter, err -95


as src_ip cloud filter creating fails for ipv4 and ipv6.

While testing cloud filter offload via tc flower, it is observed that
filters using only src_ip fail with -EINVAL, while dst_ip filters
work as expected.

Looking at the add/delete paths, this seems to be related to how IPv4
and IPv6 handle source and destination IP fields.

In the IPv4 path, an if / else if construct is used:

if (mask.dst_ip[0] & tcf.dst_ip[0])
         memcopy dst_ip;
else if (mask.src_ip[0] & tcf.dst_ip[0])
         memcopy src_ip;


This makes the source-IP handling dependent on the destination-IP check,
so valid src_ip-only filters (and combinations of src/dst IPs) don’t
seem to work as expected.

In contrast, the IPv6 path already treats source and destination IPs
independently using separate if statements:

if (mask.dst_ip[3] & tcf.dst_ip[3])
         memcopy dst_ip6;
if (mask.src_ip[3] & tcf.src_ip[3])
         memcopy src_ip6;


Aligning the IPv4 logic with the existing IPv6 approach fixes the IPv4
failures we are seeing and also keeps the behavior consistent across IP
versions.

It looks like cloud filter usage with src_ip might have been broken
for some time. Even though the current change only updates the IPv4
logic and IPv6 already has independent checks, src_ip filters are
still seen failing for both IPv4 and IPv6 during testing.

Also, using sizeof() for the memcpy lengths makes the copy size more
explicit and avoids relying on array dimensions.

Thanks,
Alok

Powered by blists - more mailing lists