1. 15 Nov, 2022 3 commits
    • Cong Wang's avatar
      kcm: close race conditions on sk_receive_queue · 5121197e
      Cong Wang authored
      sk->sk_receive_queue is protected by skb queue lock, but for KCM
      sockets its RX path takes mux->rx_lock to protect more than just
      skb queue. However, kcm_recvmsg() still only grabs the skb queue
      lock, so race conditions still exist.
      
      We can teach kcm_recvmsg() to grab mux->rx_lock too but this would
      introduce a potential performance regression as struct kcm_mux can
      be shared by multiple KCM sockets.
      
      So we have to enforce skb queue lock in requeue_rx_msgs() and handle
      skb peek case carefully in kcm_wait_data(). Fortunately,
      skb_recv_datagram() already handles it nicely and is widely used by
      other sockets, we can just switch to skb_recv_datagram() after
      getting rid of the unnecessary sock lock in kcm_recvmsg() and
      kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,
      so it is safe to get rid of this check too.
      
      I ran the original syzbot reproducer for 30 min without seeing any
      issue.
      
      Fixes: ab7ac4eb ("kcm: Kernel Connection Multiplexor module")
      Reported-by: syzbot+278279efdd2730dd14bf@syzkaller.appspotmail.com
      Reported-by: default avatarshaozhengchao <shaozhengchao@huawei.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarCong Wang <cong.wang@bytedance.com>
      Link: https://lore.kernel.org/r/20221114005119.597905-1-xiyou.wangcong@gmail.comSigned-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      5121197e
    • Yuan Can's avatar
      net: ionic: Fix error handling in ionic_init_module() · 280c0f7c
      Yuan Can authored
      A problem about ionic create debugfs failed is triggered with the
      following log given:
      
       [  415.799514] debugfs: Directory 'ionic' with parent '/' already present!
      
      The reason is that ionic_init_module() returns ionic_bus_register_driver()
      directly without checking its return value, if ionic_bus_register_driver()
      failed, it returns without destroy the newly created debugfs, resulting
      the debugfs of ionic can never be created later.
      
       ionic_init_module()
         ionic_debugfs_create() # create debugfs directory
         ionic_bus_register_driver()
           pci_register_driver()
             driver_register()
               bus_add_driver()
                 priv = kzalloc(...) # OOM happened
         # return without destroy debugfs directory
      
      Fix by removing debugfs when ionic_bus_register_driver() returns error.
      
      Fixes: fbfb8031 ("ionic: Add hardware init and device commands")
      Signed-off-by: default avatarYuan Can <yuancan@huawei.com>
      Acked-by: default avatarShannon Nelson <snelson@pensando.io>
      Link: https://lore.kernel.org/r/20221113092929.19161-1-yuancan@huawei.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      280c0f7c
    • Amit Cohen's avatar
      mlxsw: Avoid warnings when not offloaded FDB entry with IPv6 is removed · 30f5312d
      Amit Cohen authored
      FDB entries that perform VXLAN encapsulation with an IPv6 underlay hold
      a reference on a resource - the KVDL entry where the IPv6 underlay
      destination IP is stored. For that, the driver maintains two hash tables:
      1. Maps IPv6 to KVDL index
      2. Maps {MAC, FID index} to IPv6 address
      
      When a FDB entry is removed, the second table is used to find the relevant
      IPv6 address and the first table is used to remove the reference count and
      free the index if is not used anymore.
      
      In order for a packet to be forwarded to a single remote VTEP, FDB
      entries need to be configured at both the bridge and VXLAN devices' FDB
      tables. Both entries are squashed into one {MAC, VLAN/VNI} -> IP entry
      in the hardware. Therefore, in case one entry is removed, the entry will
      be removed from the hardware and the remaining entry will be unmarked
      with 'offload' flag since it is not offloaded anymore.
      
      For example, the two FDB entries should be added to allow packets to be
      forwarded via vx10:
      $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff self static dst 2001:db8:5::1
      $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff master static vlan 10
      
      When one entry will be removed, the second one will not be offloaded
      anymore. When the first entry (in VXLAN FDB) will be removed / will not be
      offloaded anymore, the two mappings in IPv6 hash tables will be removed.
      
      In case that the second entry is removed before the first one, unexpected
      warnings[1][2] will be shown in user space as a result of removing the
      first entry. The issue is that not offloaded entry is removed, the driver
      tries to search the relevant entries in the hash tables, does not find them
      and therefore warns.
      
      Do not handle removing of not offloaded VXLAN FDB entries, as they were
      already removed when the offload flag was removed.
      
      [1]:
      WARNING: CPU: 1 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum_nve.c:914 mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum]
      ...
      Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015
      Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum]
      RIP: 0010:mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum]
      ...
      Call Trace:
        <TASK>
        mlxsw_sp_port_fdb_tunnel_uc_op+0x6cf/0x7b0 [mlxsw_spectrum]
        mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum]
        ? finish_task_switch.isra.0+0x8c/0x290
        process_one_work+0x1cd/0x390
        worker_thread+0x48/0x3c0
        ? process_one_work+0x390/0x390
        kthread+0xe0/0x110
        ? kthread_complete_and_exit+0x20/0x20
        ret_from_fork+0x1f/0x30
        </TASK>
      
      [2]:
      WARNING: CPU: 0 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3035 mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum]
      ...
      Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015
      Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum]
      RIP: 0010:mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum]
      ...
      Call Trace:
        <TASK>
        ? mlxsw_sp_port_fdb_tun_uc_op6_sfd_write+0x5c1/0x610 [mlxsw_spectrum]
        mlxsw_sp_port_fdb_tunnel_uc_op+0x6ec/0x7b0 [mlxsw_spectrum]
        mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum]
        ? finish_task_switch.isra.0+0x8c/0x290
        process_one_work+0x1cd/0x390
        worker_thread+0x48/0x3c0
        ? process_one_work+0x390/0x390
        kthread+0xe0/0x110
        ? kthread_complete_and_exit+0x20/0x20
        ret_from_fork+0x1f/0x30
        </TASK>
      
      Fixes: 0860c764 ("mlxsw: spectrum_nve: Keep track of IPv6 addresses used by FDB entries")
      Signed-off-by: default avatarAmit Cohen <amcohen@nvidia.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarPetr Machata <petrm@nvidia.com>
      Link: https://lore.kernel.org/r/c186de8cbd28e3eb661e06f31f7f2f2dff30020f.1668184350.git.petrm@nvidia.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      30f5312d
  2. 14 Nov, 2022 12 commits
  3. 12 Nov, 2022 8 commits
  4. 11 Nov, 2022 10 commits
  5. 10 Nov, 2022 7 commits