Skip to content

Commit 92f6248

Browse files
vladimirolteandavem330
authored andcommitted
net: dsa: felix: fix broken VLAN-tagged PTP under VLAN-aware bridge
Normally it is expected that the dsa_device_ops :: rcv() method finishes parsing the DSA tag and consumes it, then never looks at it again. But commit c0bcf53 ("net: dsa: ocelot: add hardware timestamping support for Felix") added support for RX timestamping in a very unconventional way. On this switch, a partial timestamp is available in the DSA header, but the driver got away with not parsing that timestamp right away, but instead delayed that parsing for a little longer: dsa_switch_rcv(): nskb = cpu_dp->rcv(skb, dev); <------------- not here -> ocelot_rcv() ... skb = nskb; skb_push(skb, ETH_HLEN); skb->pkt_type = PACKET_HOST; skb->protocol = eth_type_trans(skb, skb->dev); ... if (dsa_skb_defer_rx_timestamp(p, skb)) <--- but here -> felix_rxtstamp() return 0; When in felix_rxtstamp(), this driver accounted for the fact that eth_type_trans() happened in the meanwhile, so it got a hold of the extraction header again by subtracting (ETH_HLEN + OCELOT_TAG_LEN) bytes from the current skb->data. This worked for quite some time but was quite fragile from the very beginning. Not to mention that having DSA tag parsing split in two different files, under different folders (net/dsa/tag_ocelot.c vs drivers/net/dsa/ocelot/felix.c) made it quite non-obvious for patches to come that they might break this. Finally, the blamed commit does the following: at the end of ocelot_rcv(), it checks whether the skb payload contains a VLAN header. If it does, and this port is under a VLAN-aware bridge, that VLAN ID might not be correct in the sense that the packet might have suffered VLAN rewriting due to TCAM rules (VCAP IS1). So we consume the VLAN ID from the skb payload using __skb_vlan_pop(), and take the classified VLAN ID from the DSA tag, and construct a hwaccel VLAN tag with the classified VLAN, and the skb payload is VLAN-untagged. The big problem is that __skb_vlan_pop() does: memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN); __skb_pull(skb, VLAN_HLEN); aka it moves the Ethernet header 4 bytes to the right, and pulls 4 bytes from the skb headroom (effectively also moving skb->data, by definition). So for felix_rxtstamp()'s fragile logic, all bets are off now. Instead of having the "extraction" pointer point to the DSA header, it actually points to 4 bytes _inside_ the extraction header. Corollary, the last 4 bytes of the "extraction" header are in fact 4 stale bytes of the destination MAC address from the Ethernet header, from prior to the __skb_vlan_pop() movement. So of course, RX timestamps are completely bogus when the system is configured in this way. The fix is actually very simple: just don't structure the code like that. For better or worse, the DSA PTP timestamping API does not offer a straightforward way for drivers to present their RX timestamps, but other drivers (sja1105) have established a simple mechanism to carry their RX timestamp from dsa_device_ops :: rcv() all the way to dsa_switch_ops :: port_rxtstamp() and even later. That mechanism is to simply save the partial timestamp to the skb->cb, and complete it later. Question: why don't we simply populate the skb's struct skb_shared_hwtstamps from ocelot_rcv(), and bother with this complication of propagating the timestamp to felix_rxtstamp()? Answer: dsa_switch_ops :: port_rxtstamp() answers the question whether PTP packets need sleepable context to retrieve the full RX timestamp. Currently felix_rxtstamp() answers "no, thanks" to that question, and calls ocelot_ptp_gettime64() from softirq atomic context. This is understandable, since Felix VSC9959 is a PCIe memory-mapped switch, so hardware access does not require sleeping. But the felix driver is preparing for the introduction of other switches where hardware access is over a slow bus like SPI or MDIO: https://lore.kernel.org/lkml/[email protected]/ So I would like to keep this code structure, so the rework needed when that driver will need PTP support will be minimal (answer "yes, I need deferred context for this skb's RX timestamp", then the partial timestamp will still be found in the skb->cb. Fixes: ea440cd ("net: dsa: tag_ocelot: use VLAN information from tagging header when available") Reported-by: Po Liu <[email protected]> Cc: Yangbo Lu <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
1 parent 5f15d39 commit 92f6248

File tree

3 files changed

+7
-6
lines changed

3 files changed

+7
-6
lines changed

drivers/net/dsa/ocelot/felix.c

Lines changed: 3 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1370,12 +1370,12 @@ static bool felix_check_xtr_pkt(struct ocelot *ocelot, unsigned int ptp_type)
13701370
static bool felix_rxtstamp(struct dsa_switch *ds, int port,
13711371
struct sk_buff *skb, unsigned int type)
13721372
{
1373-
u8 *extraction = skb->data - ETH_HLEN - OCELOT_TAG_LEN;
1373+
u32 tstamp_lo = OCELOT_SKB_CB(skb)->tstamp_lo;
13741374
struct skb_shared_hwtstamps *shhwtstamps;
13751375
struct ocelot *ocelot = ds->priv;
1376-
u32 tstamp_lo, tstamp_hi;
13771376
struct timespec64 ts;
1378-
u64 tstamp, val;
1377+
u32 tstamp_hi;
1378+
u64 tstamp;
13791379

13801380
/* If the "no XTR IRQ" workaround is in use, tell DSA to defer this skb
13811381
* for RX timestamping. Then free it, and poll for its copy through
@@ -1390,9 +1390,6 @@ static bool felix_rxtstamp(struct dsa_switch *ds, int port,
13901390
ocelot_ptp_gettime64(&ocelot->ptp_info, &ts);
13911391
tstamp = ktime_set(ts.tv_sec, ts.tv_nsec);
13921392

1393-
ocelot_xfh_get_rew_val(extraction, &val);
1394-
tstamp_lo = (u32)val;
1395-
13961393
tstamp_hi = tstamp >> 32;
13971394
if ((tstamp & 0xffffffff) < tstamp_lo)
13981395
tstamp_hi--;

include/linux/dsa/ocelot.h

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,7 @@
1212
struct ocelot_skb_cb {
1313
struct sk_buff *clone;
1414
unsigned int ptp_class; /* valid only for clones */
15+
u32 tstamp_lo;
1516
u8 ptp_cmd;
1617
u8 ts_id;
1718
};

net/dsa/tag_ocelot.c

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -101,6 +101,7 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
101101
struct dsa_port *dp;
102102
u8 *extraction;
103103
u16 vlan_tpid;
104+
u64 rew_val;
104105

105106
/* Revert skb->data by the amount consumed by the DSA master,
106107
* so it points to the beginning of the frame.
@@ -130,6 +131,7 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
130131
ocelot_xfh_get_qos_class(extraction, &qos_class);
131132
ocelot_xfh_get_tag_type(extraction, &tag_type);
132133
ocelot_xfh_get_vlan_tci(extraction, &vlan_tci);
134+
ocelot_xfh_get_rew_val(extraction, &rew_val);
133135

134136
skb->dev = dsa_master_find_slave(netdev, 0, src_port);
135137
if (!skb->dev)
@@ -143,6 +145,7 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
143145

144146
dsa_default_offload_fwd_mark(skb);
145147
skb->priority = qos_class;
148+
OCELOT_SKB_CB(skb)->tstamp_lo = rew_val;
146149

147150
/* Ocelot switches copy frames unmodified to the CPU. However, it is
148151
* possible for the user to request a VLAN modification through

0 commit comments

Comments
 (0)