linux/net/hsr
Sebastian Andrzej Siewior 06afd2c31d hsr: Synchronize sending frames to have always incremented outgoing seq nr.
Sending frames via the hsr (master) device requires a sequence number
which is tracked in hsr_priv::sequence_nr and protected by
hsr_priv::seqnr_lock. Each time a new frame is sent, it will obtain a
new id and then send it via the slave devices.
Each time a packet is sent (via hsr_forward_do()) the sequence number is
checked via hsr_register_frame_out() to ensure that a frame is not
handled twice. This make sense for the receiving side to ensure that the
frame is not injected into the stack twice after it has been received
from both slave ports.

There is no locking to cover the sending path which means the following
scenario is possible:

  CPU0				CPU1
  hsr_dev_xmit(skb1)		hsr_dev_xmit(skb2)
   fill_frame_info()             fill_frame_info()
    hsr_fill_frame_info()         hsr_fill_frame_info()
     handle_std_frame()            handle_std_frame()
      skb1's sequence_nr = 1
                                    skb2's sequence_nr = 2
   hsr_forward_do()              hsr_forward_do()

                                   hsr_register_frame_out(, 2)  // okay, send)

    hsr_register_frame_out(, 1) // stop, lower seq duplicate

Both skbs (or their struct hsr_frame_info) received an unique id.
However since skb2 was sent before skb1, the higher sequence number was
recorded in hsr_register_frame_out() and the late arriving skb1 was
dropped and never sent.

This scenario has been observed in a three node HSR setup, with node1 +
node2 having ping and iperf running in parallel. From time to time ping
reported a missing packet. Based on tracing that missing ping packet did
not leave the system.

It might be possible (didn't check) to drop the sequence number check on
the sending side. But if the higher sequence number leaves on wire
before the lower does and the destination receives them in that order
and it will drop the packet with the lower sequence number and never
inject into the stack.
Therefore it seems the only way is to lock the whole path from obtaining
the sequence number and sending via dev_queue_xmit() and assuming the
packets leave on wire in the same order (and don't get reordered by the
NIC).

Cover the whole path for the master interface from obtaining the ID
until after it has been forwarded via hsr_forward_skb() to ensure the
skbs are sent to the NIC in the order of the assigned sequence numbers.

Fixes: f421436a59 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-01 20:26:21 -08:00
..
hsr_debugfs.c Revert "net: hsr: use hlist_head instead of list_head for mac addresses" 2022-12-01 20:26:20 -08:00
hsr_device.c hsr: Synchronize sending frames to have always incremented outgoing seq nr. 2022-12-01 20:26:21 -08:00
hsr_device.h net: hsr: add offloading support 2021-02-11 13:24:44 -08:00
hsr_forward.c hsr: Synchronize sending frames to have always incremented outgoing seq nr. 2022-12-01 20:26:21 -08:00
hsr_forward.h net: hsr: fix mac_len checks 2021-05-24 14:10:28 -07:00
hsr_framereg.c hsr: Avoid double remove of a node. 2022-12-01 20:26:21 -08:00
hsr_framereg.h hsr: Avoid double remove of a node. 2022-12-01 20:26:21 -08:00
hsr_main.c net: use eth_hw_addr_set() instead of ether_addr_copy() 2021-10-02 14:18:25 +01:00
hsr_main.h Revert "net: hsr: use hlist_head instead of list_head for mac addresses" 2022-12-01 20:26:20 -08:00
hsr_netlink.c Revert "net: hsr: use hlist_head instead of list_head for mac addresses" 2022-12-01 20:26:20 -08:00
hsr_netlink.h hsr: enhance netlink socket interface to support PRP 2020-07-27 12:20:40 -07:00
hsr_slave.c net: hsr: fix mac_len checks 2021-05-24 14:10:28 -07:00
hsr_slave.h net: prp: add packet handling support 2020-07-27 12:20:40 -07:00
Kconfig hsr: enhance netlink socket interface to support PRP 2020-07-27 12:20:40 -07:00
Makefile treewide: Add SPDX license identifier - Makefile/Kconfig 2019-05-21 10:50:46 +02:00