1. 19 Aug, 2021 6 commits
  2. 18 Aug, 2021 26 commits
  3. 17 Aug, 2021 8 commits
    • Colin Ian King's avatar
      i40e: Fix spelling mistake "dissable" -> "disable" · 6e9078a6
      Colin Ian King authored
      There is a spelling mistake in a dev_info message. Fix it.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      6e9078a6
    • Stefan Assmann's avatar
      iavf: use mutexes for locking of critical sections · 5ac49f3c
      Stefan Assmann authored
      As follow-up to the discussion with Jakub Kicinski about iavf locking
      being insufficient [1] convert iavf to use mutexes instead of bitops.
      The locking logic is kept as is, just a drop-in replacement of
      enum iavf_critical_section_t with separate mutexes.
      The only difference is that the mutexes will be destroyed before the
      module is unloaded.
      
      [1] https://lwn.net/ml/netdev/20210316150210.00007249%40intel.com/Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Tested-by: default avatarMarek Szlosek <marek.szlosek@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      5ac49f3c
    • Justin Iurman's avatar
      selftests: net: improved IOAM tests · 752be297
      Justin Iurman authored
      As previously discussed with David Ahern, here is a refactored and improved
      version of the IOAM self-test. It is now more complete and more robust. Now,
      all tests are divided into three categories: OUTPUT (evaluates the IOAM
      processing by the sender), INPUT (evaluates the IOAM processing by the receiver)
      and GLOBAL (evaluates wider use cases that do not fall into the other two
      categories). Both OUTPUT and INPUT tests only use a two-node topology (alpha and
      beta), while GLOBAL tests use the entire three-node topology (alpha, beta,
      gamma). Each test is documented inside its own handler in the (bash) script.
      Signed-off-by: default avatarJustin Iurman <justin.iurman@uliege.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      752be297
    • David S. Miller's avatar
      Merge branch 'bridge-vlan-fixes' · 4aefc797
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      net: bridge: vlan: fixes for vlan mcast contexts
      
      These are four fixes for vlan multicast contexts. The first patch enables
      mcast ctx snooping when adding already existing master vlans to be
      consistent with the rest of the code. The second patch accounts for the
      mcast ctx router ports when allocating skb for notification. The third
      one fixes two suspicious rcu usages due to wrong vlan group helper, and
      the fourth updates host vlan mcast state along with port mcast state.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4aefc797
    • Nikolay Aleksandrov's avatar
      net: bridge: mcast: toggle also host vlan state in br_multicast_toggle_vlan · affce9a7
      Nikolay Aleksandrov authored
      When changing vlan mcast state by br_multicast_toggle_vlan it iterates
      over all ports and enables/disables the port mcast ctx based on the new
      state, but I forgot to update the host vlan (bridge master vlan entry)
      with the new state so it will be left out. Also that function is not
      used outside of br_multicast.c, so make it static.
      
      Fixes: f4b7002a ("net: bridge: add vlan mcast snooping knob")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      affce9a7
    • Nikolay Aleksandrov's avatar
      net: bridge: mcast: use the correct vlan group helper · 3f0d14ef
      Nikolay Aleksandrov authored
      When dereferencing the port vlan group we should use the rcu helper
      instead of the one relying on rtnl. In br_multicast_pg_to_port_ctx the
      entry cannot disappear as we hold the multicast lock and rcu as explained
      in the comment above it.
      For the same reason we're ok in br_multicast_start_querier.
      
       =============================
       WARNING: suspicious RCU usage
       5.14.0-rc5+ #429 Tainted: G        W
       -----------------------------
       net/bridge/br_private.h:1478 suspicious rcu_dereference_protected() usage!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 2, debug_locks = 1
       3 locks held by swapper/2/0:
        #0: ffff88822be85eb0 ((&p->timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x2da
        #1: ffff88810b32f260 (&br->multicast_lock){+.-.}-{3:3}, at: br_multicast_port_group_expired+0x28/0x13d [bridge]
        #2: ffffffff824f6c80 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire.constprop.0+0x0/0x22 [bridge]
      
       stack backtrace:
       CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G        W         5.14.0-rc5+ #429
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
       Call Trace:
        <IRQ>
        dump_stack_lvl+0x45/0x59
        nbp_vlan_group+0x3e/0x44 [bridge]
        br_multicast_pg_to_port_ctx+0xd6/0x10d [bridge]
        br_multicast_star_g_handle_mode+0xa1/0x2ce [bridge]
        ? netlink_broadcast+0xf/0x11
        ? nlmsg_notify+0x56/0x99
        ? br_mdb_notify+0x224/0x2e9 [bridge]
        ? br_multicast_del_pg+0x1dc/0x26d [bridge]
        br_multicast_del_pg+0x1dc/0x26d [bridge]
        br_multicast_port_group_expired+0xaa/0x13d [bridge]
        ? __grp_src_delete_marked.isra.0+0x35/0x35 [bridge]
        ? __grp_src_delete_marked.isra.0+0x35/0x35 [bridge]
        call_timer_fn+0x134/0x2da
        __run_timers+0x169/0x193
        run_timer_softirq+0x19/0x2d
        __do_softirq+0x1bc/0x42a
        __irq_exit_rcu+0x5c/0xb3
        irq_exit_rcu+0xa/0x12
        sysvec_apic_timer_interrupt+0x5e/0x75
        </IRQ>
        asm_sysvec_apic_timer_interrupt+0x12/0x20
       RIP: 0010:default_idle+0xc/0xd
       Code: e8 14 40 71 ff e8 10 b3 ff ff 4c 89 e2 48 89 ef 31 f6 5d 41 5c e9 a9 e8 c2 ff cc cc cc cc 0f 1f 44 00 00 e8 7f 55 65 ff fb f4 <c3> 0f 1f 44 00 00 55 65 48 8b 2c 25 40 6f 01 00 53 f0 80 4d 02 20
       RSP: 0018:ffff88810033bf00 EFLAGS: 00000206
       RAX: ffffffff819cf828 RBX: ffff888100328000 RCX: 0000000000000001
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff819cfa2d
       RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
       R10: ffff8881008302c0 R11: 00000000000006db R12: 0000000000000000
       R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000
        ? __sched_text_end+0x4/0x4
        ? default_idle_call+0x15/0x7b
        default_idle_call+0x4d/0x7b
        do_idle+0x124/0x2a2
        cpu_startup_entry+0x1d/0x1f
        secondary_startup_64_no_verify+0xb0/0xbb
      
      Fixes: 74edfd48 ("net: bridge: multicast: add helper to get port mcast context from port group")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3f0d14ef
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan: account for router port lists when notifying · 05d6f38e
      Nikolay Aleksandrov authored
      When sending a global vlan notification we should account for the number
      of router ports when allocating the skb, otherwise we might end up
      losing notifications.
      
      Fixes: dc002875 ("net: bridge: vlan: use br_rports_fill_info() to export mcast router ports")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05d6f38e
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan: enable mcast snooping for existing master vlans · b92dace3
      Nikolay Aleksandrov authored
      We always create a vlan with enabled mcast snooping, so when the user
      turns on per-vlan mcast contexts they'll get consistent behaviour with
      the current situation, but one place wasn't updated when a bridge/master
      vlan which already exists (created due to port vlans) is being added as
      real bridge vlan (BRIDGE_VLAN_INFO_BRENTRY). We need to enable mcast
      snooping for that vlan when that happens.
      
      Fixes: 7b54aaaf ("net: bridge: multicast: add vlan state initialization and control")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b92dace3