1. 30 7月, 2020 4 次提交
    • I
      mlxsw: spectrum: Use different trap group for externally routed packets · ec4f5b36
      Ido Schimmel 提交于
      Cited commit mistakenly removed the trap group for externally routed
      packets (e.g., via the management interface) and grouped locally routed
      and externally routed packet traps under the same group, thereby
      subjecting them to the same policer.
      
      This can result in problems, for example, when FRR is restarted and
      suddenly all transient traffic is trapped to the CPU because of a
      default route through the management interface. Locally routed packets
      required to re-establish a BGP connection will never reach the CPU and
      the routing tables will not be re-populated.
      
      Fix this by using a different trap group for externally routed packets.
      
      Fixes: 8110668e ("mlxsw: spectrum_trap: Register layer 3 control traps")
      Reported-by: NAlex Veber <alexve@mellanox.com>
      Tested-by: NAlex Veber <alexve@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec4f5b36
    • I
      mlxsw: spectrum_router: Allow programming link-local host routes · 89ab5331
      Ido Schimmel 提交于
      Cited commit added the ability to program link-local prefix routes to
      the ASIC so that relevant packets are routed and trapped correctly.
      
      However, host routes were not included in the change and thus not
      programmed to the ASIC. This can result in packets being trapped via an
      external route trap instead of a local route trap as in IPv4.
      
      Fix this by programming all the link-local routes to the ASIC.
      
      Fixes: 10d3757f ("mlxsw: spectrum_router: Allow programming link-local prefix routes")
      Reported-by: NAlex Veber <alexve@mellanox.com>
      Tested-by: NAlex Veber <alexve@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89ab5331
    • I
      ipv4: Silence suspicious RCU usage warning · 83f35228
      Ido Schimmel 提交于
      fib_trie_unmerge() is called with RTNL held, but not from an RCU
      read-side critical section. This leads to the following warning [1] when
      the FIB alias list in a leaf is traversed with
      hlist_for_each_entry_rcu().
      
      Since the function is always called with RTNL held and since
      modification of the list is protected by RTNL, simply use
      hlist_for_each_entry() and silence the warning.
      
      [1]
      WARNING: suspicious RCU usage
      5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
      -----------------------------
      net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by ip/164:
       #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
      
      stack backtrace:
      CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
      Call Trace:
       dump_stack+0x100/0x184
       lockdep_rcu_suspicious+0x153/0x15d
       fib_trie_unmerge+0x608/0xdb0
       fib_unmerge+0x44/0x360
       fib4_rule_configure+0xc8/0xad0
       fib_nl_newrule+0x37a/0x1dd0
       rtnetlink_rcv_msg+0x4f7/0xbd0
       netlink_rcv_skb+0x17a/0x480
       rtnetlink_rcv+0x22/0x30
       netlink_unicast+0x5ae/0x890
       netlink_sendmsg+0x98a/0xf40
       ____sys_sendmsg+0x879/0xa00
       ___sys_sendmsg+0x122/0x190
       __sys_sendmsg+0x103/0x1d0
       __x64_sys_sendmsg+0x7d/0xb0
       do_syscall_64+0x54/0xa0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fc80a234e97
      Code: Bad RIP value.
      RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97
      RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003
      RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000
      R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001
      R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020
      
      Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83f35228
    • I
      vxlan: Ensure FDB dump is performed under RCU · b5141915
      Ido Schimmel 提交于
      The commit cited below removed the RCU read-side critical section from
      rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
      without RCU protection.
      
      This results in the following warning [1] in the VXLAN driver, which
      relied on the callback being invoked from an RCU read-side critical
      section.
      
      Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
      in the bridge driver.
      
      [1]
      WARNING: suspicious RCU usage
      5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
      -----------------------------
      drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by bridge/166:
       #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090
      
      stack backtrace:
      CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
      Call Trace:
       dump_stack+0x100/0x184
       lockdep_rcu_suspicious+0x153/0x15d
       vxlan_fdb_dump+0x51e/0x6d0
       rtnl_fdb_dump+0x4dc/0xad0
       netlink_dump+0x540/0x1090
       __netlink_dump_start+0x695/0x950
       rtnetlink_rcv_msg+0x802/0xbd0
       netlink_rcv_skb+0x17a/0x480
       rtnetlink_rcv+0x22/0x30
       netlink_unicast+0x5ae/0x890
       netlink_sendmsg+0x98a/0xf40
       __sys_sendto+0x279/0x3b0
       __x64_sys_sendto+0xe6/0x1a0
       do_syscall_64+0x54/0xa0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7fe14fa2ade0
      Code: Bad RIP value.
      RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
      RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0
      RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003
      RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160
      R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      
      Fixes: 5e6d2435 ("bridge: netlink dump interface at par with brctl")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5141915
  2. 29 7月, 2020 35 次提交
  3. 28 7月, 2020 1 次提交