An error occurred fetching the project authors.
  1. 30 Apr, 2024 1 commit
    • Eric Dumazet's avatar
      net: hsr: init prune_proxy_timer sooner · 3c668cef
      Eric Dumazet authored
      We must initialize prune_proxy_timer before we attempt
      a del_timer_sync() on it.
      
      syzbot reported the following splat:
      
      INFO: trying to register non-static key.
      The code is fine but needs lockdep annotation, or maybe
      you didn't initialize this object before use?
      turning off the locking correctness validator.
      CPU: 1 PID: 11 Comm: kworker/u8:1 Not tainted 6.9.0-rc5-syzkaller-01199-gfc48de77 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
      Workqueue: netns cleanup_net
      Call Trace:
       <TASK>
        __dump_stack lib/dump_stack.c:88 [inline]
        dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
        assign_lock_key+0x238/0x270 kernel/locking/lockdep.c:976
        register_lock_class+0x1cf/0x980 kernel/locking/lockdep.c:1289
        __lock_acquire+0xda/0x1fd0 kernel/locking/lockdep.c:5014
        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
        __timer_delete_sync+0x148/0x310 kernel/time/timer.c:1648
        del_timer_sync include/linux/timer.h:185 [inline]
        hsr_dellink+0x33/0x80 net/hsr/hsr_netlink.c:132
        default_device_exit_batch+0x956/0xa90 net/core/dev.c:11737
        ops_exit_list net/core/net_namespace.c:175 [inline]
        cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:637
        process_one_work kernel/workqueue.c:3254 [inline]
        process_scheduled_works+0xa10/0x17c0 kernel/workqueue.c:3335
        worker_thread+0x86d/0xd70 kernel/workqueue.c:3416
        kthread+0x2f0/0x390 kernel/kthread.c:388
        ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
        ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
       </TASK>
      ODEBUG: assert_init not available (active state 0) object: ffff88806d3fcd88 object type: timer_list hint: 0x0
       WARNING: CPU: 1 PID: 11 at lib/debugobjects.c:517 debug_print_object+0x17a/0x1f0 lib/debugobjects.c:514
      
      Fixes: 5055cccf ("net: hsr: Provide RedBox support (HSR-SAN)")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Lukasz Majewski <lukma@denx.de>
      Reviewed-by: default avatarSimon Horman <horms@kernel.org>
      Link: https://lore.kernel.org/r/20240426163355.2613767-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      3c668cef
  2. 26 Apr, 2024 1 commit
    • Lukasz Majewski's avatar
      net: hsr: Provide RedBox support (HSR-SAN) · 5055cccf
      Lukasz Majewski authored
      Introduce RedBox support (HSR-SAN to be more precise) for HSR networks.
      Following traffic reduction optimizations have been implemented:
      - Do not send HSR supervisory frames to Port C (interlink)
      - Do not forward to HSR ring frames addressed to Port C
      - Do not forward to Port C frames from HSR ring
      - Do not send duplicate HSR frame to HSR ring when destination is Port C
      
      The corresponding patch to modify iptable2 sources has already been sent:
      https://lore.kernel.org/netdev/20240308145729.490863-1-lukma@denx.de/T/
      
      Testing procedure (veth and netns):
      -----------------------------------
      One shall run:
      linux-vanila/tools/testing/selftests/net/hsr/hsr_redbox.sh
      (Detailed description of the setup one can find in the test
      script file).
      
      Testing procedure (real hardware):
      ----------------------------------
      The EVB-KSZ9477 has been used for testing on net-next branch
      (SHA1: 5fc68320).
      
      Ports 4/5 were used for SW managed HSR (hsr1) as first hsr0 for ports 1/2
      (with HW offloading for ksz9477) was created. Port 3 has been used as
      interlink port (single USB-ETH dongle).
      
      Configuration - RedBox (EVB-KSZ9477):
      if link set lan1 down;ip link set lan2 down
      ip link add name hsr0 type hsr slave1 lan1 slave2 lan2 supervision 45 version 1
      ip link add name hsr1 type hsr slave1 lan4 slave2 lan5 interlink lan3 supervision 45 version 1
      ip link set lan4 up;ip link set lan5 up
      ip link set lan3 up
      ip addr add 192.168.0.11/24 dev hsr1
      ip link set hsr1 up
      
      Configuration - DAN-H (EVB-KSZ9477):
      
      ip link set lan1 down;ip link set lan2 down
      ip link add name hsr0 type hsr slave1 lan1 slave2 lan2 supervision 45 version 1
      ip link add name hsr1 type hsr slave1 lan4 slave2 lan5 supervision 45 version 1
      ip link set lan4 up;ip link set lan5 up
      ip addr add 192.168.0.12/24 dev hsr1
      ip link set hsr1 up
      
      This approach uses only SW based HSR devices (hsr1).
      
      --------------          -----------------       ------------
      DAN-H  Port5 | <------> | Port5         |       |
             Port4 | <------> | Port4   Port3 | <---> | PC
                   |          | (RedBox)      |       | (USB-ETH)
      EVB-KSZ9477  |          | EVB-KSZ9477   |       |
      --------------          -----------------       ------------
      Signed-off-by: default avatarLukasz Majewski <lukma@denx.de>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      5055cccf
  3. 29 Mar, 2024 1 commit
  4. 21 Feb, 2024 1 commit
  5. 14 Feb, 2024 2 commits
  6. 29 Jan, 2024 1 commit
    • Nikita Zhandarovich's avatar
      net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() · 37e8c97e
      Nikita Zhandarovich authored
      Syzkaller reported [1] hitting a warning after failing to allocate
      resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
      not help much in this case, it might be prudent to switch to
      netdev_warn_once(). At the very least it will suppress syzkaller
      reports such as [1].
      
      Just in case, use netdev_warn_once() in send_prp_supervision_frame()
      for similar reasons.
      
      [1]
      HSR: Could not send supervision frame
      WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
      RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
      ...
      Call Trace:
       <IRQ>
       hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
       call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
       expire_timers kernel/time/timer.c:1751 [inline]
       __run_timers+0x764/0xb20 kernel/time/timer.c:2022
       run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
       __do_softirq+0x21a/0x8de kernel/softirq.c:553
       invoke_softirq kernel/softirq.c:427 [inline]
       __irq_exit_rcu kernel/softirq.c:632 [inline]
       irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
       sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
       </IRQ>
       <TASK>
       asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
      ...
      
      This issue is also found in older kernels (at least up to 5.10).
      
      Cc: stable@vger.kernel.org
      Reported-by: syzbot+3ae0a3f42c84074b7c8e@syzkaller.appspotmail.com
      Fixes: 121c33b0 ("net: hsr: introduce common code for skb initialization")
      Signed-off-by: default avatarNikita Zhandarovich <n.zhandarovich@fintech.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      37e8c97e
  7. 22 Nov, 2023 1 commit
  8. 21 Jun, 2023 1 commit
  9. 02 Dec, 2022 4 commits
    • Sebastian Andrzej Siewior's avatar
      hsr: Use a single struct for self_node. · 20d3c1e9
      Sebastian Andrzej Siewior authored
      self_node_db is a list_head with one entry of struct hsr_node. The
      purpose is to hold the two MAC addresses of the node itself.
      It is convenient to recycle the structure. However having a list_head
      and fetching always the first entry is not really optimal.
      
      Created a new data strucure contaning the two MAC addresses named
      hsr_self_node. Access that structure like an RCU protected pointer so
      it can be replaced on the fly without blocking the reader.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Reviewed-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      20d3c1e9
    • Sebastian Andrzej Siewior's avatar
      hsr: Synchronize sending frames to have always incremented outgoing seq nr. · 06afd2c3
      Sebastian Andrzej Siewior authored
      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: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      06afd2c3
    • Sebastian Andrzej Siewior's avatar
      hsr: Disable netpoll. · d5c7652e
      Sebastian Andrzej Siewior authored
      The hsr device is a software device. Its
      net_device_ops::ndo_start_xmit() routine will process the packet and
      then pass the resulting skb to dev_queue_xmit().
      During processing, hsr acquires a lock with spin_lock_bh()
      (hsr_add_node()) which needs to be promoted to the _irq() suffix in
      order to avoid a potential deadlock.
      Then there are the warnings in dev_queue_xmit() (due to
      local_bh_disable() with disabled interrupts) left.
      
      Instead trying to address those (there is qdisc and…) for netpoll sake,
      just disable netpoll on hsr.
      
      Disable netpoll on hsr and replace the _irqsave() locking with _bh().
      
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d5c7652e
    • Sebastian Andrzej Siewior's avatar
      Revert "net: hsr: use hlist_head instead of list_head for mac addresses" · e012764c
      Sebastian Andrzej Siewior authored
      The hlist optimisation (which not only uses hlist_head instead of
      list_head but also splits hsr_priv::node_db into an array of 256 slots)
      does not consider the "node merge":
      Upon starting the hsr network (with three nodes) a packet that is
      sent from node1 to node3 will also be sent from node1 to node2 and then
      forwarded to node3.
      As a result node3 will receive 2 packets because it is not able
      to filter out the duplicate. Each packet received will create a new
      struct hsr_node with macaddress_A only set the MAC address it received
      from (the two MAC addesses from node1).
      At some point (early in the process) two supervision frames will be
      received from node1. They will be processed by hsr_handle_sup_frame()
      and one frame will leave early ("Node has already been merged") and does
      nothing. The other frame will be merged as portB and have its MAC
      address written to macaddress_B and the hsr_node (that was created for
      it as macaddress_A) will be removed.
      From now on HSR is able to identify a duplicate because both packets
      sent from one node will result in the same struct hsr_node because
      hsr_get_node() will find the MAC address either on macaddress_A or
      macaddress_B.
      
      Things get tricky with the optimisation: If sender's MAC address is
      saved as macaddress_A then the lookup will work as usual. If the MAC
      address has been merged into macaddress_B of another hsr_node then the
      lookup won't work because it is likely that the data structure is in
      another bucket. This results in creating a new struct hsr_node and not
      recognising a possible duplicate.
      
      A way around it would be to add another hsr_node::mac_list_B and attach
      it to the other bucket to ensure that this hsr_node will be looked up
      either via macaddress_A _or_ macaddress_B.
      
      I however prefer to revert it because it sounds like an academic problem
      rather than real life workload plus it adds complexity. I'm not an HSR
      expert with what is usual size of a network but I would guess 40 to 60
      nodes. With 10.000 nodes and assuming 60us for pass-through (from node
      to node) then it would take almost 600ms for a packet to almost wrap
      around which sounds a lot.
      
      Revert the hash MAC addresses optimisation.
      
      Fixes: 4acc45db ("net: hsr: use hlist_head instead of list_head for mac addresses")
      Cc: Juhee Kang <claudiajkang@gmail.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e012764c
  10. 12 Mar, 2022 1 commit
  11. 06 Feb, 2022 1 commit
    • Juhee Kang's avatar
      net: hsr: use hlist_head instead of list_head for mac addresses · 4acc45db
      Juhee Kang authored
      Currently, HSR manages mac addresses of known HSR nodes by using list_head.
      It takes a lot of time when there are a lot of registered nodes due to
      finding specific mac address nodes by using linear search. We can be
      reducing the time by using hlist. Thus, this patch moves list_head to
      hlist_head for mac addresses and this allows for further improvement of
      network performance.
      
          Condition: registered 10,000 known HSR nodes
          Before:
          # iperf3 -c 192.168.10.1 -i 1 -t 10
          Connecting to host 192.168.10.1, port 5201
          [  5] local 192.168.10.2 port 59442 connected to 192.168.10.1 port 5201
          [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
          [  5]   0.00-1.49   sec  3.75 MBytes  21.1 Mbits/sec    0    158 KBytes
          [  5]   1.49-2.05   sec  1.25 MBytes  18.7 Mbits/sec    0    166 KBytes
          [  5]   2.05-3.06   sec  2.44 MBytes  20.3 Mbits/sec   56   16.9 KBytes
          [  5]   3.06-4.08   sec  1.43 MBytes  11.7 Mbits/sec   11   38.0 KBytes
          [  5]   4.08-5.00   sec   951 KBytes  8.49 Mbits/sec    0   56.3 KBytes
      
          After:
          # iperf3 -c 192.168.10.1 -i 1 -t 10
          Connecting to host 192.168.10.1, port 5201
          [  5] local 192.168.10.2 port 36460 connected to 192.168.10.1 port 5201
          [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
          [  5]   0.00-1.00   sec  7.39 MBytes  62.0 Mbits/sec    3    130 KBytes
          [  5]   1.00-2.00   sec  5.06 MBytes  42.4 Mbits/sec   16    113 KBytes
          [  5]   2.00-3.00   sec  8.58 MBytes  72.0 Mbits/sec   42   94.3 KBytes
          [  5]   3.00-4.00   sec  7.44 MBytes  62.4 Mbits/sec    2    131 KBytes
          [  5]   4.00-5.07   sec  8.13 MBytes  63.5 Mbits/sec   38   92.9 KBytes
      Signed-off-by: default avatarJuhee Kang <claudiajkang@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4acc45db
  12. 29 Nov, 2021 1 commit
    • Sebastian Andrzej Siewior's avatar
      net: Write lock dev_base_lock without disabling bottom halves. · fd888e85
      Sebastian Andrzej Siewior authored
      The writer acquires dev_base_lock with disabled bottom halves.
      The reader can acquire dev_base_lock without disabling bottom halves
      because there is no writer in softirq context.
      
      On PREEMPT_RT the softirqs are preemptible and local_bh_disable() acts
      as a lock to ensure that resources, that are protected by disabling
      bottom halves, remain protected.
      This leads to a circular locking dependency if the lock acquired with
      disabled bottom halves (as in write_lock_bh()) and somewhere else with
      enabled bottom halves (as by read_lock() in netstat_show()) followed by
      disabling bottom halves (cxgb_get_stats() -> t4_wr_mbox_meat_timeout()
      -> spin_lock_bh()). This is the reverse locking order.
      
      All read_lock() invocation are from sysfs callback which are not invoked
      from softirq context. Therefore there is no need to disable bottom
      halves while acquiring a write lock.
      
      Acquire the write lock of dev_base_lock without disabling bottom halves.
      Reported-by: default avatarPei Zhang <pezhang@redhat.com>
      Reported-by: default avatarLuis Claudio R. Goncalves <lgoncalv@redhat.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fd888e85
  13. 26 Oct, 2021 1 commit
  14. 02 Oct, 2021 1 commit
  15. 24 May, 2021 1 commit
    • George McCollister's avatar
      net: hsr: fix mac_len checks · 48b491a5
      George McCollister authored
      Commit 2e9f6093 ("net: hsr: check skb can contain struct hsr_ethhdr
      in fill_frame_info") added the following which resulted in -EINVAL
      always being returned:
      	if (skb->mac_len < sizeof(struct hsr_ethhdr))
      		return -EINVAL;
      
      mac_len was not being set correctly so this check completely broke
      HSR/PRP since it was always 14, not 20.
      
      Set mac_len correctly and modify the mac_len checks to test in the
      correct places since sometimes it is legitimately 14.
      
      Fixes: 2e9f6093 ("net: hsr: check skb can contain struct hsr_ethhdr in fill_frame_info")
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48b491a5
  16. 07 Apr, 2021 1 commit
    • Kurt Kanzenbach's avatar
      net: hsr: Reset MAC header for Tx path · 9d680392
      Kurt Kanzenbach authored
      Reset MAC header in HSR Tx path. This is needed, because direct packet
      transmission, e.g. by specifying PACKET_QDISC_BYPASS does not reset the MAC
      header.
      
      This has been observed using the following setup:
      
      |$ ip link add name hsr0 type hsr slave1 lan0 slave2 lan1 supervision 45 version 1
      |$ ifconfig hsr0 up
      |$ ./test hsr0
      
      The test binary is using mmap'ed sockets and is specifying the
      PACKET_QDISC_BYPASS socket option.
      
      This patch resolves the following warning on a non-patched kernel:
      
      |[  112.725394] ------------[ cut here ]------------
      |[  112.731418] WARNING: CPU: 1 PID: 257 at net/hsr/hsr_forward.c:560 hsr_forward_skb+0x484/0x568
      |[  112.739962] net/hsr/hsr_forward.c:560: Malformed frame (port_src hsr0)
      
      The warning can be safely removed, because the other call sites of
      hsr_forward_skb() make sure that the skb is prepared correctly.
      
      Fixes: d346a3fa ("packet: introduce PACKET_QDISC_BYPASS socket option")
      Signed-off-by: Kurt Kanzenbach's avatarKurt Kanzenbach <kurt@linutronix.de>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d680392
  17. 11 Feb, 2021 2 commits
    • George McCollister's avatar
      net: hsr: add offloading support · dcf0cd1c
      George McCollister authored
      Add support for offloading of HSR/PRP (IEC 62439-3) tag insertion
      tag removal, duplicate generation and forwarding.
      
      For HSR, insertion involves the switch adding a 6 byte HSR header after
      the 14 byte Ethernet header. For PRP it adds a 6 byte trailer.
      
      Tag removal involves automatically stripping the HSR/PRP header/trailer
      in the switch. This is possible when the switch also performs auto
      deduplication using the HSR/PRP header/trailer (making it no longer
      required).
      
      Forwarding involves automatically forwarding between redundant ports in
      an HSR. This is crucial because delay is accumulated as a frame passes
      through each node in the ring.
      
      Duplication involves the switch automatically sending a single frame
      from the CPU port to both redundant ports. This is required because the
      inserted HSR/PRP header/trailer must contain the same sequence number
      on the frames sent out both redundant ports.
      
      Export is_hsr_master so DSA can tell them apart from other devices in
      dsa_slave_changeupper.
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dcf0cd1c
    • George McCollister's avatar
      net: hsr: generate supervision frame without HSR/PRP tag · 78be9217
      George McCollister authored
      For a switch to offload insertion of HSR/PRP tags, frames must not be
      sent to the CPU facing switch port with a tag. Generate supervision frames
      (eth type ETH_P_PRP) without HSR v1 (ETH_P_HSR)/PRP tag and rely on
      create_tagged_frame which inserts it later. This will allow skipping the
      tag insertion for all outgoing frames in the future which is required for
      HSR v1/PRP tag insertions to be offloaded.
      
      HSR v0 supervision frames always contain tag information so insertion of
      the tag can't be offloaded. IEC 62439-3 Ed.2.0 (HSR v1) specifically
      notes that this was changed since v0 to allow offloading.
      Signed-off-by: default avatarGeorge McCollister <george.mccollister@gmail.com>
      Reviewed-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Tested-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78be9217
  18. 27 Jul, 2020 6 commits
    • Murali Karicheri's avatar
      net: prp: add packet handling support · 451d8123
      Murali Karicheri authored
      DAN-P (Dual Attached Nodes PRP) nodes are expected to receive
      traditional IP packets as well as PRP (Parallel Redundancy
      Protocol) tagged (trailer) packets. PRP trailer is 6 bytes
      of PRP protocol unit called RCT, Redundancy Control Trailer
      (RCT) similar to HSR tag. PRP network can have traditional
      devices such as bridges/switches or PC attached to it and
      should be able to communicate. Regular Ethernet devices treat
      the RCT as pads.  This patch adds logic to format L2 frames
      from network stack to add a trailer (RCT) and send it as
      duplicates over the slave interfaces when the protocol is
      PRP as per IEC 62439-3. At the ingress, it strips the trailer,
      do duplicate detection and rejection and forward a stripped
      frame up the network stack. PRP device should accept frames
      from Singly Attached Nodes (SAN) and thus the driver mark
      the link where the frame came from in the node table.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      451d8123
    • Murali Karicheri's avatar
      net: hsr: define and use proto_ops ptrs to handle hsr specific frames · fa4dc895
      Murali Karicheri authored
      As a preparatory patch to introduce PRP, refactor the code specific to
      handling HSR frames into separate functions and call them through
      proto_ops function pointers.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa4dc895
    • Murali Karicheri's avatar
      net: prp: add supervision frame generation utility function · c643ff03
      Murali Karicheri authored
      Add support for generation of PRP supervision frames. For PRP,
      supervision frame format is similar to HSR version 0, but have
      a PRP Redundancy Control Trailer (RCT) added and uses a different
      message type, PRP_TLV_LIFE_CHECK_DD. Also update
      is_supervision_frame() to include the new message type used for
      PRP supervision frame.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c643ff03
    • Murali Karicheri's avatar
      net: hsr: introduce protocol specific function pointers · 28e458e0
      Murali Karicheri authored
      As a preparatory patch to introduce support for PRP protocol, add a
      protocol ops ptr in the private hsr structure to hold function
      pointers as some of the functions at protocol level packet
      handling is different for HSR vs PRP. It is expected that PRP will
      add its of set of functions for protocol handling. Modify existing
      hsr_announce() function to call proto_ops->send_sv_frame() to send
      supervision frame for HSR. This is expected to be different for PRP.
      So introduce a ops function ptr, send_sv_frame() for the same and
      initialize it to send_hsr_supervsion_frame(). Modify hsr_announce()
      to call proto_ops->send_sv_frame().
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28e458e0
    • Murali Karicheri's avatar
      net: hsr: introduce common code for skb initialization · 121c33b0
      Murali Karicheri authored
      As a preparatory patch to introduce PRP protocol support in the
      driver, refactor the skb init code to a separate function.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      121c33b0
    • Murali Karicheri's avatar
      hsr: enhance netlink socket interface to support PRP · 8f4c0e01
      Murali Karicheri authored
      Parallel Redundancy Protocol (PRP) is another redundancy protocol
      introduced by IEC 63439 standard. It is similar to HSR in many
      aspects:-
      
       - Use a pair of Ethernet interfaces to created the PRP device
       - Use a 6 byte redundancy protocol part (RCT, Redundancy Check
         Trailer) similar to HSR Tag.
       - Has Link Redundancy Entity (LRE) that works with RCT to implement
         redundancy.
      
      Key difference is that the protocol unit is a trailer instead of a
      prefix as in HSR. That makes it inter-operable with tradition network
      components such as bridges/switches which treat it as pad bytes,
      whereas HSR nodes requires some kind of translators (Called redbox) to
      talk to regular network devices. This features allows regular linux box
      to be converted to a DAN-P box. DAN-P stands for Dual Attached Node - PRP
      similar to DAN-H (Dual Attached Node - HSR).
      
      Add a comment at the header/source code to explicitly state that the
      driver files also handles PRP protocol as well.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f4c0e01
  19. 05 Jul, 2020 1 commit
    • Taehee Yoo's avatar
      hsr: fix interface leak in error path of hsr_dev_finalize() · ccfc9df1
      Taehee Yoo authored
      To release hsr(upper) interface, it should release
      its own lower interfaces first.
      Then, hsr(upper) interface can be released safely.
      In the current code of error path of hsr_dev_finalize(), it releases hsr
      interface before releasing a lower interface.
      So, a warning occurs, which warns about the leak of lower interfaces.
      In order to fix this problem, changing the ordering of the error path of
      hsr_dev_finalize() is needed.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          ip link add dummy2 type dummy
          ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1
          ip link add hsr1 type hsr slave1 dummy2 slave2 dummy0
      
      Splat looks like:
      [  214.923127][    C2] WARNING: CPU: 2 PID: 1093 at net/core/dev.c:8992 rollback_registered_many+0x986/0xcf0
      [  214.923129][    C2] Modules linked in: hsr dummy openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipx
      [  214.923154][    C2] CPU: 2 PID: 1093 Comm: ip Not tainted 5.8.0-rc2+ #623
      [  214.923156][    C2] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  214.923157][    C2] RIP: 0010:rollback_registered_many+0x986/0xcf0
      [  214.923160][    C2] Code: 41 8b 4e cc 45 31 c0 31 d2 4c 89 ee 48 89 df e8 e0 47 ff ff 85 c0 0f 84 cd fc ff ff 5
      [  214.923162][    C2] RSP: 0018:ffff8880c5156f28 EFLAGS: 00010287
      [  214.923165][    C2] RAX: ffff8880d1dad458 RBX: ffff8880bd1b9000 RCX: ffffffffb929d243
      [  214.923167][    C2] RDX: 1ffffffff77e63f0 RSI: 0000000000000008 RDI: ffffffffbbf31f80
      [  214.923168][    C2] RBP: dffffc0000000000 R08: fffffbfff77e63f1 R09: fffffbfff77e63f1
      [  214.923170][    C2] R10: ffffffffbbf31f87 R11: 0000000000000001 R12: ffff8880c51570a0
      [  214.923172][    C2] R13: ffff8880bd1b90b8 R14: ffff8880c5157048 R15: ffff8880d1dacc40
      [  214.923174][    C2] FS:  00007fdd257a20c0(0000) GS:ffff8880da200000(0000) knlGS:0000000000000000
      [  214.923175][    C2] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  214.923177][    C2] CR2: 00007ffd78beb038 CR3: 00000000be544005 CR4: 00000000000606e0
      [  214.923179][    C2] Call Trace:
      [  214.923180][    C2]  ? netif_set_real_num_tx_queues+0x780/0x780
      [  214.923182][    C2]  ? dev_validate_mtu+0x140/0x140
      [  214.923183][    C2]  ? synchronize_rcu.part.79+0x85/0xd0
      [  214.923185][    C2]  ? synchronize_rcu_expedited+0xbb0/0xbb0
      [  214.923187][    C2]  rollback_registered+0xc8/0x170
      [  214.923188][    C2]  ? rollback_registered_many+0xcf0/0xcf0
      [  214.923190][    C2]  unregister_netdevice_queue+0x18b/0x240
      [  214.923191][    C2]  hsr_dev_finalize+0x56e/0x6e0 [hsr]
      [  214.923192][    C2]  hsr_newlink+0x36b/0x450 [hsr]
      [  214.923194][    C2]  ? hsr_dellink+0x70/0x70 [hsr]
      [  214.923195][    C2]  ? rtnl_create_link+0x2e4/0xb00
      [  214.923197][    C2]  ? __netlink_ns_capable+0xc3/0xf0
      [  214.923198][    C2]  __rtnl_newlink+0xbdb/0x1270
      [ ... ]
      
      Fixes: e0a4b997 ("hsr: use upper/lower device infrastructure")
      Reported-by: syzbot+7f1c020f68dab95aab59@syzkaller.appspotmail.com
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ccfc9df1
  20. 29 Jun, 2020 1 commit
  21. 23 Jun, 2020 1 commit
    • Taehee Yoo's avatar
      hsr: avoid to create proc file after unregister · de0083c7
      Taehee Yoo authored
      When an interface is being deleted, "/proc/net/dev_snmp6/<interface name>"
      is deleted.
      The function for this is addrconf_ifdown() in the addrconf_notify() and
      it is called by notification, which is NETDEV_UNREGISTER.
      But, if NETDEV_CHANGEMTU is triggered after NETDEV_UNREGISTER,
      this proc file will be created again.
      This recreated proc file will be deleted by netdev_wati_allrefs().
      Before netdev_wait_allrefs() is called, creating a new HSR interface
      routine can be executed and It tries to create a proc file but it will
      find an un-deleted proc file.
      At this point, it warns about it.
      
      To avoid this situation, it can use ->dellink() instead of
      ->ndo_uninit() to release resources because ->dellink() is called
      before NETDEV_UNREGISTER.
      So, a proc file will not be recreated.
      
      Test commands
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          ip link set dummy0 mtu 1300
      
          #SHELL1
          while :
          do
              ip link add hsr0 type hsr slave1 dummy0 slave2 dummy1
          done
      
          #SHELL2
          while :
          do
              ip link del hsr0
          done
      
      Splat looks like:
      [ 9888.980852][ T2752] proc_dir_entry 'dev_snmp6/hsr0' already registered
      [ 9888.981797][    C2] WARNING: CPU: 2 PID: 2752 at fs/proc/generic.c:372 proc_register+0x2d5/0x430
      [ 9888.981798][    C2] Modules linked in: hsr dummy veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6x
      [ 9888.981814][    C2] CPU: 2 PID: 2752 Comm: ip Tainted: G        W         5.8.0-rc1+ #616
      [ 9888.981815][    C2] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [ 9888.981816][    C2] RIP: 0010:proc_register+0x2d5/0x430
      [ 9888.981818][    C2] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 65 01 00 00 49 8b b5 e0 00 00 00 48 89 ea 40
      [ 9888.981819][    C2] RSP: 0018:ffff8880628dedf0 EFLAGS: 00010286
      [ 9888.981821][    C2] RAX: dffffc0000000008 RBX: ffff888028c69170 RCX: ffffffffaae09a62
      [ 9888.981822][    C2] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88806c9f75ac
      [ 9888.981823][    C2] RBP: ffff888028c693f4 R08: ffffed100d9401bd R09: ffffed100d9401bd
      [ 9888.981824][    C2] R10: ffffffffaddf406f R11: 0000000000000001 R12: ffff888028c69308
      [ 9888.981825][    C2] R13: ffff8880663584c8 R14: dffffc0000000000 R15: ffffed100518d27e
      [ 9888.981827][    C2] FS:  00007f3876b3b0c0(0000) GS:ffff88806c800000(0000) knlGS:0000000000000000
      [ 9888.981828][    C2] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 9888.981829][    C2] CR2: 00007f387601a8c0 CR3: 000000004101a002 CR4: 00000000000606e0
      [ 9888.981830][    C2] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 9888.981831][    C2] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [ 9888.981832][    C2] Call Trace:
      [ 9888.981833][    C2]  ? snmp6_seq_show+0x180/0x180
      [ 9888.981834][    C2]  proc_create_single_data+0x7c/0xa0
      [ 9888.981835][    C2]  snmp6_register_dev+0xb0/0x130
      [ 9888.981836][    C2]  ipv6_add_dev+0x4b7/0xf60
      [ 9888.981837][    C2]  addrconf_notify+0x684/0x1ca0
      [ 9888.981838][    C2]  ? __mutex_unlock_slowpath+0xd0/0x670
      [ 9888.981839][    C2]  ? kasan_unpoison_shadow+0x30/0x40
      [ 9888.981840][    C2]  ? wait_for_completion+0x250/0x250
      [ 9888.981841][    C2]  ? inet6_ifinfo_notify+0x100/0x100
      [ 9888.981842][    C2]  ? dropmon_net_event+0x227/0x410
      [ 9888.981843][    C2]  ? notifier_call_chain+0x90/0x160
      [ 9888.981844][    C2]  ? inet6_ifinfo_notify+0x100/0x100
      [ 9888.981845][    C2]  notifier_call_chain+0x90/0x160
      [ 9888.981846][    C2]  register_netdevice+0xbe5/0x1070
      [ ... ]
      
      Reported-by: syzbot+1d51c8b74efa4c44adeb@syzkaller.appspotmail.com
      Fixes: e0a4b997 ("hsr: use upper/lower device infrastructure")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de0083c7
  22. 26 Apr, 2020 1 commit
  23. 01 Mar, 2020 3 commits
  24. 26 Dec, 2019 3 commits
    • Taehee Yoo's avatar
      hsr: reset network header when supervision frame is created · 3ed0a1d5
      Taehee Yoo authored
      The supervision frame is L2 frame.
      When supervision frame is created, hsr module doesn't set network header.
      If tap routine is enabled, dev_queue_xmit_nit() is called and it checks
      network_header. If network_header pointer wasn't set(or invalid),
      it resets network_header and warns.
      In order to avoid unnecessary warning message, resetting network_header
      is needed.
      
      Test commands:
          ip netns add nst
          ip link add veth0 type veth peer name veth1
          ip link add veth2 type veth peer name veth3
          ip link set veth1 netns nst
          ip link set veth3 netns nst
          ip link set veth0 up
          ip link set veth2 up
          ip link add hsr0 type hsr slave1 veth0 slave2 veth2
          ip a a 192.168.100.1/24 dev hsr0
          ip link set hsr0 up
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip link set veth3 up
          ip netns exec nst ip link add hsr1 type hsr slave1 veth1 slave2 veth3
          ip netns exec nst ip a a 192.168.100.2/24 dev hsr1
          ip netns exec nst ip link set hsr1 up
          tcpdump -nei veth0
      
      Splat looks like:
      [  175.852292][    C3] protocol 88fb is buggy, dev veth0
      
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ed0a1d5
    • Taehee Yoo's avatar
      hsr: fix a race condition in node list insertion and deletion · 92a35678
      Taehee Yoo authored
      hsr nodes are protected by RCU and there is no write side lock.
      But node insertions and deletions could be being operated concurrently.
      So write side locking is needed.
      
      Test commands:
          ip netns add nst
          ip link add veth0 type veth peer name veth1
          ip link add veth2 type veth peer name veth3
          ip link set veth1 netns nst
          ip link set veth3 netns nst
          ip link set veth0 up
          ip link set veth2 up
          ip link add hsr0 type hsr slave1 veth0 slave2 veth2
          ip a a 192.168.100.1/24 dev hsr0
          ip link set hsr0 up
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip link set veth3 up
          ip netns exec nst ip link add hsr1 type hsr slave1 veth1 slave2 veth3
          ip netns exec nst ip a a 192.168.100.2/24 dev hsr1
          ip netns exec nst ip link set hsr1 up
      
          for i in {0..9}
          do
              for j in {0..9}
      	do
      	    for k in {0..9}
      	    do
      	        for l in {0..9}
      		do
      	        arping 192.168.100.2 -I hsr0 -s 00:01:3$i:4$j:5$k:6$l -c1 &
      		done
      	    done
      	done
          done
      
      Splat looks like:
      [  236.066091][ T3286] list_add corruption. next->prev should be prev (ffff8880a5940300), but was ffff8880a5940d0.
      [  236.069617][ T3286] ------------[ cut here ]------------
      [  236.070545][ T3286] kernel BUG at lib/list_debug.c:25!
      [  236.071391][ T3286] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  236.072343][ T3286] CPU: 0 PID: 3286 Comm: arping Tainted: G        W         5.5.0-rc1+ #209
      [  236.073463][ T3286] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  236.074695][ T3286] RIP: 0010:__list_add_valid+0x74/0xd0
      [  236.075499][ T3286] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 b
      [  236.078277][ T3286] RSP: 0018:ffff8880aaa97648 EFLAGS: 00010286
      [  236.086991][ T3286] RAX: 0000000000000075 RBX: ffff8880d4624c20 RCX: 0000000000000000
      [  236.088000][ T3286] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed1015552ebf
      [  236.098897][ T3286] RBP: ffff88809b53d200 R08: ffffed101b3c04f9 R09: ffffed101b3c04f9
      [  236.099960][ T3286] R10: 00000000308769a1 R11: ffffed101b3c04f8 R12: ffff8880d4624c28
      [  236.100974][ T3286] R13: ffff8880d4624c20 R14: 0000000040310100 R15: ffff8880ce17ee02
      [  236.138967][ T3286] FS:  00007f23479fa680(0000) GS:ffff8880d9c00000(0000) knlGS:0000000000000000
      [  236.144852][ T3286] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  236.145720][ T3286] CR2: 00007f4a14bab210 CR3: 00000000a61c6001 CR4: 00000000000606f0
      [  236.146776][ T3286] Call Trace:
      [  236.147222][ T3286]  hsr_add_node+0x314/0x490 [hsr]
      [  236.153633][ T3286]  hsr_forward_skb+0x2b6/0x1bc0 [hsr]
      [  236.154362][ T3286]  ? rcu_read_lock_sched_held+0x90/0xc0
      [  236.155091][ T3286]  ? rcu_read_lock_bh_held+0xa0/0xa0
      [  236.156607][ T3286]  hsr_dev_xmit+0x70/0xd0 [hsr]
      [  236.157254][ T3286]  dev_hard_start_xmit+0x160/0x740
      [  236.157941][ T3286]  __dev_queue_xmit+0x1961/0x2e10
      [  236.158565][ T3286]  ? netdev_core_pick_tx+0x2e0/0x2e0
      [ ... ]
      
      Reported-by: syzbot+3924327f9ad5f4d2b343@syzkaller.appspotmail.com
      Fixes: f421436a ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92a35678
    • Taehee Yoo's avatar
      hsr: fix error handling routine in hsr_dev_finalize() · 1d19e2d5
      Taehee Yoo authored
      hsr_dev_finalize() is called to create new hsr interface.
      There are some wrong error handling codes.
      
      1. wrong checking return value of debugfs_create_{dir/file}.
      These function doesn't return NULL. If error occurs in there,
      it returns error pointer.
      So, it should check error pointer instead of NULL.
      
      2. It doesn't unregister interface if it fails to setup hsr interface.
      If it fails to initialize hsr interface after register_netdevice(),
      it should call unregister_netdevice().
      
      3. Ignore failure of creation of debugfs
      If creating of debugfs dir and file is failed, creating hsr interface
      will be failed. But debugfs doesn't affect actual logic of hsr module.
      So, ignoring this is more correct and this behavior is more general.
      
      Fixes: c5a75911 ("net/hsr: Use list_head (and rcu) instead of array for slave devices.")
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1d19e2d5
  25. 05 Dec, 2019 1 commit
    • Taehee Yoo's avatar
      hsr: fix a NULL pointer dereference in hsr_dev_xmit() · df95467b
      Taehee Yoo authored
      hsr_dev_xmit() calls hsr_port_get_hsr() to find master node and that would
      return NULL if master node is not existing in the list.
      But hsr_dev_xmit() doesn't check return pointer so a NULL dereference
      could occur.
      
      Test commands:
          ip netns add nst
          ip link add veth0 type veth peer name veth1
          ip link add veth2 type veth peer name veth3
          ip link set veth1 netns nst
          ip link set veth3 netns nst
          ip link set veth0 up
          ip link set veth2 up
          ip link add hsr0 type hsr slave1 veth0 slave2 veth2
          ip a a 192.168.100.1/24 dev hsr0
          ip link set hsr0 up
          ip netns exec nst ip link set veth1 up
          ip netns exec nst ip link set veth3 up
          ip netns exec nst ip link add hsr1 type hsr slave1 veth1 slave2 veth3
          ip netns exec nst ip a a 192.168.100.2/24 dev hsr1
          ip netns exec nst ip link set hsr1 up
          hping3 192.168.100.2 -2 --flood &
          modprobe -rv hsr
      
      Splat looks like:
      [  217.351122][ T1635] kasan: CONFIG_KASAN_INLINE enabled
      [  217.352969][ T1635] kasan: GPF could be caused by NULL-ptr deref or user memory access
      [  217.354297][ T1635] general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
      [  217.355507][ T1635] CPU: 1 PID: 1635 Comm: hping3 Not tainted 5.4.0+ #192
      [  217.356472][ T1635] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  217.357804][ T1635] RIP: 0010:hsr_dev_xmit+0x34/0x90 [hsr]
      [  217.373010][ T1635] Code: 48 8d be 00 0c 00 00 be 04 00 00 00 48 83 ec 08 e8 21 be ff ff 48 8d 78 10 48 ba 00 b
      [  217.376919][ T1635] RSP: 0018:ffff8880cd8af058 EFLAGS: 00010202
      [  217.377571][ T1635] RAX: 0000000000000000 RBX: ffff8880acde6840 RCX: 0000000000000002
      [  217.379465][ T1635] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: 0000000000000010
      [  217.380274][ T1635] RBP: ffff8880acde6840 R08: ffffed101b440d5d R09: 0000000000000001
      [  217.381078][ T1635] R10: 0000000000000001 R11: ffffed101b440d5c R12: ffff8880bffcc000
      [  217.382023][ T1635] R13: ffff8880bffcc088 R14: 0000000000000000 R15: ffff8880ca675c00
      [  217.383094][ T1635] FS:  00007f060d9d1740(0000) GS:ffff8880da000000(0000) knlGS:0000000000000000
      [  217.384289][ T1635] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  217.385009][ T1635] CR2: 00007faf15381dd0 CR3: 00000000d523c001 CR4: 00000000000606e0
      [  217.385940][ T1635] Call Trace:
      [  217.386544][ T1635]  dev_hard_start_xmit+0x160/0x740
      [  217.387114][ T1635]  __dev_queue_xmit+0x1961/0x2e10
      [  217.388118][ T1635]  ? check_object+0xaf/0x260
      [  217.391466][ T1635]  ? __alloc_skb+0xb9/0x500
      [  217.392017][ T1635]  ? init_object+0x6b/0x80
      [  217.392629][ T1635]  ? netdev_core_pick_tx+0x2e0/0x2e0
      [  217.393175][ T1635]  ? __alloc_skb+0xb9/0x500
      [  217.393727][ T1635]  ? rcu_read_lock_sched_held+0x90/0xc0
      [  217.394331][ T1635]  ? rcu_read_lock_bh_held+0xa0/0xa0
      [  217.395013][ T1635]  ? kasan_unpoison_shadow+0x30/0x40
      [  217.395668][ T1635]  ? __kasan_kmalloc.constprop.4+0xa0/0xd0
      [  217.396280][ T1635]  ? __kmalloc_node_track_caller+0x3a8/0x3f0
      [  217.399007][ T1635]  ? __kasan_kmalloc.constprop.4+0xa0/0xd0
      [  217.400093][ T1635]  ? __kmalloc_reserve.isra.46+0x2e/0xb0
      [  217.401118][ T1635]  ? memset+0x1f/0x40
      [  217.402529][ T1635]  ? __alloc_skb+0x317/0x500
      [  217.404915][ T1635]  ? arp_xmit+0xca/0x2c0
      [ ... ]
      
      Fixes: 311633b6 ("hsr: switch ->dellink() to ->ndo_uninit()")
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df95467b
  26. 11 Jul, 2019 1 commit
    • Cong Wang's avatar
      hsr: switch ->dellink() to ->ndo_uninit() · 311633b6
      Cong Wang authored
      Switching from ->priv_destructor to dellink() has an unexpected
      consequence: existing RCU readers, that is, hsr_port_get_hsr()
      callers, may still be able to read the port list.
      
      Instead of checking the return value of each hsr_port_get_hsr(),
      we can just move it to ->ndo_uninit() which is called after
      device unregister and synchronize_net(), and we still have RTNL
      lock there.
      
      Fixes: b9a1e627 ("hsr: implement dellink to clean up resources")
      Fixes: edf070a0 ("hsr: fix a NULL pointer deref in hsr_dev_xmit()")
      Reported-by: syzbot+097ef84cdc95843fbaa8@syzkaller.appspotmail.com
      Cc: Arvid Brodin <arvid.brodin@alten.se>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      311633b6