1. 28 Oct, 2022 22 commits
  2. 27 Oct, 2022 18 commits
    • Jakub Kicinski's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 31f1aa4f
      Jakub Kicinski authored
      drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c
        2871edb3 ("can: kvaser_usb: Fix possible completions during init_completion")
        abb86709 ("can: kvaser_usb_leaf: Ignore stale bus-off after start")
        8d21f592 ("can: kvaser_usb_leaf: Fix improved state not being reported")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      31f1aa4f
    • Linus Torvalds's avatar
      Merge tag 'net-6.1-rc3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · 23758867
      Linus Torvalds authored
      Pull networking fixes from Jakub Kicinski:
       "Including fixes from 802.15.4 (Zigbee et al).
      
        Current release - regressions:
      
         - ipa: fix bugs in the register conversion for IPA v3.1 and v3.5.1
      
        Current release - new code bugs:
      
         - mptcp: fix abba deadlock on fastopen
      
         - eth: stmmac: rk3588: allow multiple gmac controllers in one system
      
        Previous releases - regressions:
      
         - ip: rework the fix for dflt addr selection for connected nexthop
      
         - net: couple more fixes for misinterpreting bits in struct page
           after the signature was added
      
        Previous releases - always broken:
      
         - ipv6: ensure sane device mtu in tunnels
      
         - openvswitch: switch from WARN to pr_warn on a user-triggerable path
      
         - ethtool: eeprom: fix null-deref on genl_info in dump
      
         - ieee802154: more return code fixes for corner cases in
           dgram_sendmsg
      
         - mac802154: fix link-quality-indicator recording
      
         - eth: mlx5: fixes for IPsec, PTP timestamps, OvS and conntrack
           offload
      
         - eth: fec: limit register access on i.MX6UL
      
         - eth: bcm4908_enet: update TX stats after actual transmission
      
         - can: rcar_canfd: improve IRQ handling for RZ/G2L
      
        Misc:
      
         - genetlink: piggy back on the newly added resv_op_start to enforce
           more sanity checks on new commands"
      
      * tag 'net-6.1-rc3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (57 commits)
        net: enetc: survive memory pressure without crashing
        kcm: do not sense pfmemalloc status in kcm_sendpage()
        net: do not sense pfmemalloc status in skb_append_pagefrags()
        net/mlx5e: Fix macsec sci endianness at rx sa update
        net/mlx5e: Fix wrong bitwise comparison usage in macsec_fs_rx_add_rule function
        net/mlx5e: Fix macsec rx security association (SA) update/delete
        net/mlx5e: Fix macsec coverity issue at rx sa update
        net/mlx5: Fix crash during sync firmware reset
        net/mlx5: Update fw fatal reporter state on PCI handlers successful recover
        net/mlx5e: TC, Fix cloned flow attr instance dests are not zeroed
        net/mlx5e: TC, Reject forwarding from internal port to internal port
        net/mlx5: Fix possible use-after-free in async command interface
        net/mlx5: ASO, Create the ASO SQ with the correct timestamp format
        net/mlx5e: Update restore chain id for slow path packets
        net/mlx5e: Extend SKB room check to include PTP-SQ
        net/mlx5: DR, Fix matcher disconnect error flow
        net/mlx5: Wait for firmware to enable CRS before pci_restore_state
        net/mlx5e: Do not increment ESN when updating IPsec ESN state
        netdevsim: remove dir in nsim_dev_debugfs_init() when creating ports dir failed
        netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed
        ...
      23758867
    • Linus Torvalds's avatar
      Merge tag 'execve-v6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · 7dd257d0
      Linus Torvalds authored
      Pull execve fixes from Kees Cook:
      
       - Fix an ancient signal action copy race (Bernd Edlinger)
      
       - Fix a memory leak in ELF loader, when under memory pressure (Li
         Zetao)
      
      * tag 'execve-v6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        fs/binfmt_elf: Fix memory leak in load_elf_binary()
        exec: Copy oldsighand->action under spin-lock
      7dd257d0
    • Linus Torvalds's avatar
      Merge tag 'hardening-v6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · 2eb72d85
      Linus Torvalds authored
      Pull hardening fixes from Kees Cook:
      
       - Fix older Clang vs recent overflow KUnit test additions (Nick
         Desaulniers, Kees Cook)
      
       - Fix kern-doc visibility for overflow helpers (Kees Cook)
      
      * tag 'hardening-v6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        overflow: Refactor test skips for Clang-specific issues
        overflow: disable failing tests for older clang versions
        overflow: Fix kern-doc markup for functions
      2eb72d85
    • Linus Torvalds's avatar
      Merge tag 'media/v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 7f9a7cd6
      Linus Torvalds authored
      Pull media fixes from Mauro Carvalho Chehab:
       "A bunch of patches addressing issues in the vivid driver and adding
        new checks in V4L2 to validate the input parameters from some ioctls"
      
      * tag 'media/v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
        media: vivid.rst: loop_video is set on the capture devnode
        media: vivid: set num_in/outputs to 0 if not supported
        media: vivid: drop GFP_DMA32
        media: vivid: fix control handler mutex deadlock
        media: videodev2.h: V4L2_DV_BT_BLANKING_HEIGHT should check 'interlaced'
        media: v4l2-dv-timings: add sanity checks for blanking values
        media: vivid: dev->bitmap_cap wasn't freed in all cases
        media: vivid: s_fbuf: add more sanity checks
      7f9a7cd6
    • Linus Torvalds's avatar
      Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt · 200204f5
      Linus Torvalds authored
      Pull fscrypt fix from Eric Biggers:
       "Fix a memory leak that was introduced by a change that went into -rc1"
      
      * tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt:
        fscrypt: fix keyring memory leak on mount failure
      200204f5
    • Vladimir Oltean's avatar
      net: enetc: survive memory pressure without crashing · 84ce1ca3
      Vladimir Oltean authored
      Under memory pressure, enetc_refill_rx_ring() may fail, and when called
      during the enetc_open() -> enetc_setup_rxbdr() procedure, this is not
      checked for.
      
      An extreme case of memory pressure will result in exactly zero buffers
      being allocated for the RX ring, and in such a case it is expected that
      hardware drops all RX packets due to lack of buffers.
      
      This does not happen, because the reset-default value of the consumer
      and produces index is 0, and this makes the ENETC think that all buffers
      have been initialized and that it owns them (when in reality none were).
      
      The hardware guide explains this best:
      
      | Configure the receive ring producer index register RBaPIR with a value
      | of 0. The producer index is initially configured by software but owned
      | by hardware after the ring has been enabled. Hardware increments the
      | index when a frame is received which may consume one or more BDs.
      | Hardware is not allowed to increment the producer index to match the
      | consumer index since it is used to indicate an empty condition. The ring
      | can hold at most RBLENR[LENGTH]-1 received BDs.
      |
      | Configure the receive ring consumer index register RBaCIR. The
      | consumer index is owned by software and updated during operation of the
      | of the BD ring by software, to indicate that any receive data occupied
      | in the BD has been processed and it has been prepared for new data.
      | - If consumer index and producer index are initialized to the same
      |   value, it indicates that all BDs in the ring have been prepared and
      |   hardware owns all of the entries.
      | - If consumer index is initialized to producer index plus N, it would
      |   indicate N BDs have been prepared. Note that hardware cannot start if
      |   only a single buffer is prepared due to the restrictions described in
      |   (2).
      | - Software may write consumer index to match producer index anytime
      |   while the ring is operational to indicate all received BDs prior have
      |   been processed and new BDs prepared for hardware.
      
      Normally, the value of rx_ring->rcir (consumer index) is brought in sync
      with the rx_ring->next_to_use software index, but this only happens if
      page allocation ever succeeded.
      
      When PI==CI==0, the hardware appears to receive frames and write them to
      DMA address 0x0 (?!), then set the READY bit in the BD.
      
      The enetc_clean_rx_ring() function (and its XDP derivative) is naturally
      not prepared to handle such a condition. It will attempt to process
      those frames using the rx_swbd structure associated with index i of the
      RX ring, but that structure is not fully initialized (enetc_new_page()
      does all of that). So what happens next is undefined behavior.
      
      To operate using no buffer, we must initialize the CI to PI + 1, which
      will block the hardware from advancing the CI any further, and drop
      everything.
      
      The issue was seen while adding support for zero-copy AF_XDP sockets,
      where buffer memory comes from user space, which can even decide to
      supply no buffers at all (example: "xdpsock --txonly"). However, the bug
      is present also with the network stack code, even though it would take a
      very determined person to trigger a page allocation failure at the
      perfect time (a series of ifup/ifdown under memory pressure should
      eventually reproduce it given enough retries).
      
      Fixes: d4fd0404 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarClaudiu Manoil <claudiu.manoil@nxp.com>
      Link: https://lore.kernel.org/r/20221027182925.3256653-1-vladimir.oltean@nxp.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      84ce1ca3
    • Eric Dumazet's avatar
      kcm: do not sense pfmemalloc status in kcm_sendpage() · ee15e1f3
      Eric Dumazet authored
      Similar to changes done in TCP in blamed commit.
      We should not sense pfmemalloc status in sendpage() methods.
      
      Fixes: 32614006 ("tcp: TX zerocopy should not sense pfmemalloc status")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20221027040637.1107703-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ee15e1f3
    • Eric Dumazet's avatar
      net: do not sense pfmemalloc status in skb_append_pagefrags() · 228ebc41
      Eric Dumazet authored
      skb_append_pagefrags() is used by af_unix and udp sendpage()
      implementation so far.
      
      In commit 32614006 ("tcp: TX zerocopy should not sense
      pfmemalloc status") we explained why we should not sense
      pfmemalloc status for pages owned by user space.
      
      We should also use skb_fill_page_desc_noacc()
      in skb_append_pagefrags() to avoid following KCSAN report:
      
      BUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags
      
      write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0:
      __list_add include/linux/list.h:73 [inline]
      list_add include/linux/list.h:88 [inline]
      lruvec_add_folio include/linux/mm_inline.h:323 [inline]
      lru_add_fn+0x327/0x410 mm/swap.c:228
      folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246
      lru_add_drain_cpu+0x73/0x250 mm/swap.c:669
      lru_add_drain+0x21/0x60 mm/swap.c:773
      free_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311
      tlb_batch_pages_flush mm/mmu_gather.c:59 [inline]
      tlb_flush_mmu_free mm/mmu_gather.c:256 [inline]
      tlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263
      tlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363
      exit_mmap+0x190/0x4d0 mm/mmap.c:3098
      __mmput+0x27/0x1b0 kernel/fork.c:1185
      mmput+0x3d/0x50 kernel/fork.c:1207
      copy_process+0x19fc/0x2100 kernel/fork.c:2518
      kernel_clone+0x166/0x550 kernel/fork.c:2671
      __do_sys_clone kernel/fork.c:2812 [inline]
      __se_sys_clone kernel/fork.c:2796 [inline]
      __x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1:
      page_is_pfmemalloc include/linux/mm.h:1817 [inline]
      __skb_fill_page_desc include/linux/skbuff.h:2432 [inline]
      skb_fill_page_desc include/linux/skbuff.h:2453 [inline]
      skb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974
      unix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338
      kernel_sendpage+0x184/0x300 net/socket.c:3561
      sock_sendpage+0x5a/0x70 net/socket.c:1054
      pipe_to_sendpage+0x128/0x160 fs/splice.c:361
      splice_from_pipe_feed fs/splice.c:415 [inline]
      __splice_from_pipe+0x222/0x4d0 fs/splice.c:559
      splice_from_pipe fs/splice.c:594 [inline]
      generic_splice_sendpage+0x89/0xc0 fs/splice.c:743
      do_splice_from fs/splice.c:764 [inline]
      direct_splice_actor+0x80/0xa0 fs/splice.c:931
      splice_direct_to_actor+0x305/0x620 fs/splice.c:886
      do_splice_direct+0xfb/0x180 fs/splice.c:974
      do_sendfile+0x3bf/0x910 fs/read_write.c:1255
      __do_sys_sendfile64 fs/read_write.c:1323 [inline]
      __se_sys_sendfile64 fs/read_write.c:1309 [inline]
      __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309
      do_syscall_x64 arch/x86/entry/common.c:50 [inline]
      do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
      entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      value changed: 0x0000000000000000 -> 0xffffea00058fc188
      
      Reported by Kernel Concurrency Sanitizer on:
      CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895-dirty #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022
      
      Fixes: 32614006 ("tcp: TX zerocopy should not sense pfmemalloc status")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/r/20221027040346.1104204-1-edumazet@google.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      228ebc41
    • Raed Salem's avatar
      net/mlx5e: Fix macsec sci endianness at rx sa update · 12ba40ba
      Raed Salem authored
      The cited commit at rx sa update operation passes the sci object
      attribute, in the wrong endianness and not as expected by the HW
      effectively create malformed hw sa context in case of update rx sa
      consequently, HW produces unexpected MACsec packets which uses this
      sa.
      
      Fix by passing sci to create macsec object with the correct endianness,
      while at it add __force u64 to prevent sparse check error of type
      "sparse: error: incorrect type in assignment".
      
      Fixes: aae3454e ("net/mlx5e: Add MACsec offload Rx command support")
      Signed-off-by: default avatarRaed Salem <raeds@nvidia.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-16-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      12ba40ba
    • Raed Salem's avatar
      net/mlx5e: Fix wrong bitwise comparison usage in macsec_fs_rx_add_rule function · d5509564
      Raed Salem authored
      The cited commit produces a sparse check error of type
      "sparse: error: restricted __be64 degrades to integer". The
      offending line wrongly did a bitwise operation between two different
      storage types one of 64 bit when the other smaller side is 16 bit
      which caused the above sparse error, furthermore bitwise operation
      usage here is wrong in the first place as the constant MACSEC_PORT_ES
      is not a bitwise field.
      
      Fix by using the right mask to get the lower 16 bit if the sci number,
      and use comparison operator '==' instead of bitwise '&' operator.
      
      Fixes: 3b20949c ("net/mlx5e: Add MACsec RX steering rules")
      Signed-off-by: default avatarRaed Salem <raeds@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-15-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d5509564
    • Raed Salem's avatar
      net/mlx5e: Fix macsec rx security association (SA) update/delete · 74573e38
      Raed Salem authored
      The cited commit adds the support for update/delete MACsec Rx SA,
      naturally, these operations need to check if the SA in question exists
      to update/delete the SA and return error code otherwise, however they
      do just the opposite i.e. return with error if the SA exists
      
      Fix by change the check to return error in case the SA in question does
      not exist, adjust error message and code accordingly.
      
      Fixes: aae3454e ("net/mlx5e: Add MACsec offload Rx command support")
      Signed-off-by: default avatarRaed Salem <raeds@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-14-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      74573e38
    • Raed Salem's avatar
      net/mlx5e: Fix macsec coverity issue at rx sa update · d3ecf037
      Raed Salem authored
      The cited commit at update rx sa operation passes object attributes
      to MACsec object create function without initializing/setting all
      attributes fields leaving some of them with garbage values, therefore
      violating the implicit assumption at create object function, which
      assumes that all input object attributes fields are set.
      
      Fix by initializing the object attributes struct to zero, thus leaving
      unset fields with the legal zero value.
      
      Fixes: aae3454e ("net/mlx5e: Add MACsec offload Rx command support")
      Signed-off-by: default avatarRaed Salem <raeds@nvidia.com>
      Reviewed-by: default avatarLior Nahmanson <liorna@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-13-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      d3ecf037
    • Suresh Devarakonda's avatar
      net/mlx5: Fix crash during sync firmware reset · aefb62a9
      Suresh Devarakonda authored
      When setting Bluefield to DPU NIC mode using mlxconfig tool +  sync
      firmware reset flow, we run into scenario where the host was not
      eswitch manager at the time of mlx5 driver load but becomes eswitch manager
      after the sync firmware reset flow. This results in null pointer
      access of mpfs structure during mac filter add. This change prevents null
      pointer access but mpfs table entries will not be added.
      
      Fixes: 5ec69744 ("net/mlx5: Add support for devlink reload action fw activate")
      Signed-off-by: default avatarSuresh Devarakonda <ramad@nvidia.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Reviewed-by: default avatarBodong Wang <bodong@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-12-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      aefb62a9
    • Roy Novich's avatar
      net/mlx5: Update fw fatal reporter state on PCI handlers successful recover · 416ef713
      Roy Novich authored
      Update devlink health fw fatal reporter state to "healthy" is needed by
      strictly calling devlink_health_reporter_state_update() after recovery
      was done by PCI error handler. This is needed when fw_fatal reporter was
      triggered due to PCI error. Poll health is called and set reporter state
      to error. Health recovery failed (since EEH didn't re-enable the PCI).
      PCI handlers keep on recover flow and succeed later without devlink
      acknowledgment. Fix this by adding devlink state update at the end of
      the PCI handler recovery process.
      
      Fixes: 6181e5cb ("devlink: add support for reporter recovery completion")
      Signed-off-by: default avatarRoy Novich <royno@nvidia.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Reviewed-by: default avatarAya Levin <ayal@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-11-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      416ef713
    • Roi Dayan's avatar
      net/mlx5e: TC, Fix cloned flow attr instance dests are not zeroed · 94d65173
      Roi Dayan authored
      On multi table split the driver creates a new attr instance with
      data being copied from prev attr instance zeroing action flags.
      Also need to reset dests properties to avoid incorrect dests per attr.
      
      Fixes: 8300f225 ("net/mlx5e: Create new flow attr for multi table actions")
      Signed-off-by: default avatarRoi Dayan <roid@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-10-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      94d65173
    • Ariel Levkovich's avatar
      net/mlx5e: TC, Reject forwarding from internal port to internal port · f382a241
      Ariel Levkovich authored
      Reject TC rules that forward from internal port to internal port
      as it is not supported.
      
      This include rules that are explicitly have internal port as
      the filter device as well as rules that apply on tunnel interfaces
      as the route device for the tunnel interface can be an internal
      port.
      
      Fixes: 27484f71 ("net/mlx5e: Offload tc rules that redirect to ovs internal port")
      Signed-off-by: default avatarAriel Levkovich <lariel@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-9-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      f382a241
    • Tariq Toukan's avatar
      net/mlx5: Fix possible use-after-free in async command interface · bacd22df
      Tariq Toukan authored
      mlx5_cmd_cleanup_async_ctx should return only after all its callback
      handlers were completed. Before this patch, the below race between
      mlx5_cmd_cleanup_async_ctx and mlx5_cmd_exec_cb_handler was possible and
      lead to a use-after-free:
      
      1. mlx5_cmd_cleanup_async_ctx is called while num_inflight is 2 (i.e.
         elevated by 1, a single inflight callback).
      2. mlx5_cmd_cleanup_async_ctx decreases num_inflight to 1.
      3. mlx5_cmd_exec_cb_handler is called, decreases num_inflight to 0 and
         is about to call wake_up().
      4. mlx5_cmd_cleanup_async_ctx calls wait_event, which returns
         immediately as the condition (num_inflight == 0) holds.
      5. mlx5_cmd_cleanup_async_ctx returns.
      6. The caller of mlx5_cmd_cleanup_async_ctx frees the mlx5_async_ctx
         object.
      7. mlx5_cmd_exec_cb_handler goes on and calls wake_up() on the freed
         object.
      
      Fix it by syncing using a completion object. Mark it completed when
      num_inflight reaches 0.
      
      Trace:
      
      BUG: KASAN: use-after-free in do_raw_spin_lock+0x23d/0x270
      Read of size 4 at addr ffff888139cd12f4 by task swapper/5/0
      
      CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      Call Trace:
       <IRQ>
       dump_stack_lvl+0x57/0x7d
       print_report.cold+0x2d5/0x684
       ? do_raw_spin_lock+0x23d/0x270
       kasan_report+0xb1/0x1a0
       ? do_raw_spin_lock+0x23d/0x270
       do_raw_spin_lock+0x23d/0x270
       ? rwlock_bug.part.0+0x90/0x90
       ? __delete_object+0xb8/0x100
       ? lock_downgrade+0x6e0/0x6e0
       _raw_spin_lock_irqsave+0x43/0x60
       ? __wake_up_common_lock+0xb9/0x140
       __wake_up_common_lock+0xb9/0x140
       ? __wake_up_common+0x650/0x650
       ? destroy_tis_callback+0x53/0x70 [mlx5_core]
       ? kasan_set_track+0x21/0x30
       ? destroy_tis_callback+0x53/0x70 [mlx5_core]
       ? kfree+0x1ba/0x520
       ? do_raw_spin_unlock+0x54/0x220
       mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core]
       ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]
       ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]
       mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core]
       ? dump_command+0xcc0/0xcc0 [mlx5_core]
       ? lockdep_hardirqs_on_prepare+0x400/0x400
       ? cmd_comp_notifier+0x7e/0xb0 [mlx5_core]
       cmd_comp_notifier+0x7e/0xb0 [mlx5_core]
       atomic_notifier_call_chain+0xd7/0x1d0
       mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core]
       atomic_notifier_call_chain+0xd7/0x1d0
       ? irq_release+0x140/0x140 [mlx5_core]
       irq_int_handler+0x19/0x30 [mlx5_core]
       __handle_irq_event_percpu+0x1f2/0x620
       handle_irq_event+0xb2/0x1d0
       handle_edge_irq+0x21e/0xb00
       __common_interrupt+0x79/0x1a0
       common_interrupt+0x78/0xa0
       </IRQ>
       <TASK>
       asm_common_interrupt+0x22/0x40
      RIP: 0010:default_idle+0x42/0x60
      Code: c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0f 00 2d e0 9f 48 00 fb f4 <c3> 48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00
      RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242
      RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110
      RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc
      RBP: 0000000000000005 R08: 0000000000000001 R09: ffff88881dec4ac3
      R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005
      R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000
       ? default_idle_call+0xcc/0x450
       default_idle_call+0xec/0x450
       do_idle+0x394/0x450
       ? arch_cpu_idle_exit+0x40/0x40
       ? do_idle+0x17/0x450
       cpu_startup_entry+0x19/0x20
       start_secondary+0x221/0x2b0
       ? set_cpu_sibling_map+0x2070/0x2070
       secondary_startup_64_no_verify+0xcd/0xdb
       </TASK>
      
      Allocated by task 49502:
       kasan_save_stack+0x1e/0x40
       __kasan_kmalloc+0x81/0xa0
       kvmalloc_node+0x48/0xe0
       mlx5e_bulk_async_init+0x35/0x110 [mlx5_core]
       mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core]
       mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]
       mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]
       mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
       mlx5e_suspend+0xdb/0x140 [mlx5_core]
       mlx5e_remove+0x89/0x190 [mlx5_core]
       auxiliary_bus_remove+0x52/0x70
       device_release_driver_internal+0x40f/0x650
       driver_detach+0xc1/0x180
       bus_remove_driver+0x125/0x2f0
       auxiliary_driver_unregister+0x16/0x50
       mlx5e_cleanup+0x26/0x30 [mlx5_core]
       cleanup+0xc/0x4e [mlx5_core]
       __x64_sys_delete_module+0x2b5/0x450
       do_syscall_64+0x3d/0x90
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
      
      Freed by task 49502:
       kasan_save_stack+0x1e/0x40
       kasan_set_track+0x21/0x30
       kasan_set_free_info+0x20/0x30
       ____kasan_slab_free+0x11d/0x1b0
       kfree+0x1ba/0x520
       mlx5e_tls_priv_tx_list_cleanup+0x2e7/0x3e0 [mlx5_core]
       mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]
       mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]
       mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
       mlx5e_suspend+0xdb/0x140 [mlx5_core]
       mlx5e_remove+0x89/0x190 [mlx5_core]
       auxiliary_bus_remove+0x52/0x70
       device_release_driver_internal+0x40f/0x650
       driver_detach+0xc1/0x180
       bus_remove_driver+0x125/0x2f0
       auxiliary_driver_unregister+0x16/0x50
       mlx5e_cleanup+0x26/0x30 [mlx5_core]
       cleanup+0xc/0x4e [mlx5_core]
       __x64_sys_delete_module+0x2b5/0x450
       do_syscall_64+0x3d/0x90
       entry_SYSCALL_64_after_hwframe+0x46/0xb0
      
      Fixes: e355477e ("net/mlx5: Make mlx5_cmd_exec_cb() a safe API")
      Signed-off-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      Link: https://lore.kernel.org/r/20221026135153.154807-8-saeed@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      bacd22df