1. 19 Aug, 2021 2 commits
  2. 18 Aug, 2021 26 commits
  3. 17 Aug, 2021 12 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
    • David S. Miller's avatar
      Merge branch 'octeonx2-mcam-management-rework' · 2cb59424
      David S. Miller authored
      Subbaraya Sundeep says:
      
      ====================
      octeontx2: Rework MCAM flows management for VFs
      
      From Octeontx2 hardware point of view there is no
      difference between PFs and VFs. Hence with refactoring
      in driver the packet classification features or offloads
      can be supported by VFs also. This patchset unifies the
      mcam flows management so that VFs can also support
      ntuple filters. Since there are MCAM allocations by
      all PFs and VFs in the system it is required to have
      the ability to modify number of mcam rules count
      for a PF/VF in runtime. This is achieved by using devlink.
      Below is the summary of patches:
      
      Patch 1,2,3 are trivial patches which helps in debugging
      in case of errors by using custom error codes and
      displaying proper error messages.
      
      Patches 4,5 brings rx-all and ntuple support
      for CGX mapped VFs and LBK VFs.
      
      Patches 6,7,8 brings devlink support to
      PF netdev driver so that mcam entries count
      can be changed at runtime.
      To change mcam rule count at runtime where multiple rule
      allocations are done sorting is required.
      Also both ntuple and TC rules needs to be unified.
      
      Patch 9 is related to AF NPC where a PF
      allocated entries are allocated at bottom(low priority).
      
      On CN10K there is slight change in reading
      NPC counters which is handled by patch 10.
      
      Patch 11 is to allow packets from CPT for
      NPC parsing on CN10K.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2cb59424
    • Vidya's avatar
      octeontx2-af: configure npc for cn10k to allow packets from cpt · aee51224
      Vidya authored
      On CN10K, the higher bits in the channel number represents the CPT
      channel number. Mask out these higher bits in the npc configuration
      to allow packets from cpt for parsing.
      Signed-off-by: default avatarVidya <vvelumuri@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aee51224
    • Hariprasad Kelam's avatar
      octeontx2-af: cn10K: Get NPC counters value · 99b8e547
      Hariprasad Kelam authored
      The way SW can identify the number NPC counters supported by silicon
      has changed for CN10K. This patch addresses this reading appropriate
      registers to find out number of counters available.
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99b8e547
    • Subbaraya Sundeep's avatar
      octeontx2-af: Allocate low priority entries for PF · 7df5b4b2
      Subbaraya Sundeep authored
      If the mcam entry allocation request is from PF
      and NOT a priority allocation request then allocate
      low priority entries so that PF entries always have
      lower priority than its VFs. This is required so
      that entries with (base) MCAM match criteria have lower
      priority compared to entries with (base + additional)
      match criteria. This patch considers only best case
      scenario where PF entries are allocated from low
      priority zone if low priority zone has free space.
      There are worst case scenarios like:
      1. VFs allocating hundreds of MCAM entries leading to VFs
      using all mid priority zone and low priority zone entries
      hence no entries free from low priority zone for PF.
      2. All the PFs and VFs in the system allocating and freeing
      entries causing fragmentation in MCAM space and all the
      entries requested by PF could not fit in low priority
      zone for allocation.
      This patch do not handle worst case scenarios.
      Signed-off-by: default avatarSubbaraya Sundeep <sbhatta@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7df5b4b2