[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+OFbz7iZ/8wEIZq@corigine.com>
Date: Wed, 8 Feb 2023 12:20:15 +0100
From: Simon Horman <simon.horman@...igine.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Claudiu Manoil <claudiu.manoil@....com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
UNGLinuxDriver@...rochip.com, linux-kernel@...r.kernel.org,
Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Colin Foster <colin.foster@...advantage.com>,
Xiaoliang Yang <xiaoliang.yang_1@....com>,
Richie Pearn <richard.pearn@....com>
Subject: Re: [PATCH net] net: mscc: ocelot: fix all IPv6 getting trapped to
CPU when PTP timestamping is used
On Tue, Feb 07, 2023 at 08:31:17PM +0200, Vladimir Oltean wrote:
> While running this selftest which usually passes:
>
> ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0
> TEST: swp0: Unicast IPv4 to primary MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ]
> TEST: swp0: Multicast IPv4 to joined group [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ]
> TEST: swp0: Multicast IPv6 to joined group [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ]
>
> if I start PTP timestamping then run it again (debug prints added by me),
> the unknown IPv6 MC traffic is seen by the CPU port even when it should
> have been dropped:
>
> ~/selftests/drivers/net/dsa# ptp4l -i swp0 -2 -P -m
> ptp4l[225.410]: selected /dev/ptp1 as PTP clock
> [ 225.445746] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_add: port 0 adding L2 PTP trap
> [ 225.453815] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP event trap
> [ 225.462703] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_add: port 0 adding IPv4 PTP general trap
> [ 225.471768] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP event trap
> [ 225.480651] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_add: port 0 adding IPv6 PTP general trap
> ptp4l[225.488]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
> ptp4l[225.488]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
> ^C
> ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0
> TEST: swp0: Unicast IPv4 to primary MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ]
> TEST: swp0: Multicast IPv4 to joined group [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ]
> TEST: swp0: Multicast IPv6 to joined group [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group [FAIL]
> reception succeeded, but should have failed
> TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ]
>
> The PGID_MCIPV6 is configured correctly to not flood to the CPU,
> I checked that.
>
> Furthermore, when I disable back PTP RX timestamping (ptp4l doesn't do
> that when it exists), packets are RX filtered again as they should be:
>
> ~/selftests/drivers/net/dsa# hwstamp_ctl -i swp0 -r 0
> [ 218.202854] mscc_felix 0000:00:00.5: ocelot_l2_ptp_trap_del: port 0 removing L2 PTP trap
> [ 218.212656] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP event trap
> [ 218.222975] mscc_felix 0000:00:00.5: ocelot_ipv4_ptp_trap_del: port 0 removing IPv4 PTP general trap
> [ 218.233133] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP event trap
> [ 218.242251] mscc_felix 0000:00:00.5: ocelot_ipv6_ptp_trap_del: port 0 removing IPv6 PTP general trap
> current settings:
> tx_type 1
> rx_filter 12
> new settings:
> tx_type 1
> rx_filter 0
> ~/selftests/drivers/net/dsa# ./local_termination.sh eno0 swp0
> TEST: swp0: Unicast IPv4 to primary MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to macvlan MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address, promisc [ OK ]
> TEST: swp0: Unicast IPv4 to unknown MAC address, allmulti [ OK ]
> TEST: swp0: Multicast IPv4 to joined group [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group, promisc [ OK ]
> TEST: swp0: Multicast IPv4 to unknown group, allmulti [ OK ]
> TEST: swp0: Multicast IPv6 to joined group [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group, promisc [ OK ]
> TEST: swp0: Multicast IPv6 to unknown group, allmulti [ OK ]
>
> So it's clear that something in the PTP RX trapping logic went wrong.
>
> Looking a bit at the code, I can see that there are 4 typos, which
> populate "ipv4" VCAP IS2 key filter fields for IPv6 keys.
>
> VCAP IS2 keys of type OCELOT_VCAP_KEY_IPV4 and OCELOT_VCAP_KEY_IPV6 are
> handled by is2_entry_set(). OCELOT_VCAP_KEY_IPV4 looks at
> &filter->key.ipv4, and OCELOT_VCAP_KEY_IPV6 at &filter->key.ipv6.
> Simply put, when we populate the wrong key field, &filter->key.ipv6
> fields "proto.mask" and "proto.value" remain all zeroes (or "don't care").
> So is2_entry_set() will enter the "else" of this "if" condition:
>
> if (msk == 0xff && (val == IPPROTO_TCP || val == IPPROTO_UDP))
>
> and proceed to ignore the "proto" field. The resulting rule will match
> on all IPv6 traffic, trapping it to the CPU.
>
> This is the reason why the local_termination.sh selftest sees it,
> because control traps are stronger than the PGID_MCIPV6 used for
> flooding (from the forwarding data path).
>
> But the problem is in fact much deeper. We trap all IPv6 traffic to the
> CPU, but if we're bridged, we set skb->offload_fwd_mark = 1, so software
> forwarding will not take place and IPv6 traffic will never reach its
> destination.
>
> The fix is simple - correct the typos.
>
> I was intentionally inaccurate in the commit message about the breakage
> occurring when any PTP timestamping is enabled. In fact it only happens
> when L4 timestamping is requested (HWTSTAMP_FILTER_PTP_V2_EVENT or
> HWTSTAMP_FILTER_PTP_V2_L4_EVENT). But ptp4l requests a larger RX
> timestamping filter than it needs for "-2": HWTSTAMP_FILTER_PTP_V2_EVENT.
> I wanted people skimming through git logs to not think that the bug
> doesn't affect them because they only use ptp4l in L2 mode.
>
> Fixes: 96ca08c05838 ("net: mscc: ocelot: set up traps for PTP packets")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
Reviewed-by: Simon Horman <simon.horman@...igine.com>
Powered by blists - more mailing lists