1. 08 Nov, 2022 13 commits
  2. 07 Nov, 2022 13 commits
  3. 05 Nov, 2022 6 commits
  4. 04 Nov, 2022 8 commits
    • Wang Yufen's avatar
      net: tun: Fix memory leaks of napi_get_frags · 1118b204
      Wang Yufen authored
      kmemleak reports after running test_progs:
      
      unreferenced object 0xffff8881b1672dc0 (size 232):
        comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s)
        hex dump (first 32 bytes):
          e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff  .........,g.....
          00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00  .@..............
        backtrace:
          [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150
          [<0000000041c7fc09>] __napi_build_skb+0x15/0x50
          [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540
          [<000000003ecfa30e>] napi_get_frags+0x59/0x140
          [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun]
          [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun]
          [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320
          [<000000008f338ea2>] do_iter_write+0x135/0x630
          [<000000008a3377a4>] vfs_writev+0x12e/0x440
          [<00000000a6b5639a>] do_writev+0x104/0x280
          [<00000000ccf065d8>] do_syscall_64+0x3b/0x90
          [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
      
      The issue occurs in the following scenarios:
      tun_get_user()
        napi_gro_frags()
          napi_frags_finish()
            case GRO_NORMAL:
              gro_normal_one()
                list_add_tail(&skb->list, &napi->rx_list);
                <-- While napi->rx_count < READ_ONCE(gro_normal_batch),
                <-- gro_normal_list() is not called, napi->rx_list is not empty
        <-- not ask to complete the gro work, will cause memory leaks in
        <-- following tun_napi_del()
      ...
      tun_napi_del()
        netif_napi_del()
          __netif_napi_del()
          <-- &napi->rx_list is not empty, which caused memory leaks
      
      To fix, add napi_complete() after napi_gro_frags().
      
      Fixes: 90e33d45 ("tun: enable napi_gro_frags() for TUN/TAP driver")
      Signed-off-by: default avatarWang Yufen <wangyufen@huawei.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1118b204
    • Ratheesh Kannoth's avatar
      octeontx2-pf: NIX TX overwrites SQ_CTX_HW_S[SQ_INT] · 51afe902
      Ratheesh Kannoth authored
      In scenarios where multiple errors have occurred
      for a SQ before SW starts handling error interrupt,
      SQ_CTX[OP_INT] may get overwritten leading to
      NIX_LF_SQ_OP_INT returning incorrect value.
      To workaround this read LMT, MNQ and SQ individual
      error status registers to determine the cause of error.
      
      Fixes: 4ff7d148 ("octeontx2-pf: Error handling support")
      Signed-off-by: default avatarRatheesh Kannoth <rkannoth@marvell.com>
      Reviewed-by: default avatarSunil Kovvuri Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51afe902
    • Roger Quadros's avatar
      net: ethernet: ti: am65-cpsw: Fix segmentation fault at module unload · 1a0c016a
      Roger Quadros authored
      Move am65_cpsw_nuss_phylink_cleanup() call to after
      am65_cpsw_nuss_cleanup_ndev() so phylink is still valid
      to prevent the below Segmentation fault on module remove when
      first slave link is up.
      
      [   31.652944] Unable to handle kernel paging request at virtual address 00040008000005f4
      [   31.684627] Mem abort info:
      [   31.687446]   ESR = 0x0000000096000004
      [   31.704614]   EC = 0x25: DABT (current EL), IL = 32 bits
      [   31.720663]   SET = 0, FnV = 0
      [   31.723729]   EA = 0, S1PTW = 0
      [   31.740617]   FSC = 0x04: level 0 translation fault
      [   31.756624] Data abort info:
      [   31.759508]   ISV = 0, ISS = 0x00000004
      [   31.776705]   CM = 0, WnR = 0
      [   31.779695] [00040008000005f4] address between user and kernel address ranges
      [   31.808644] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
      [   31.814928] Modules linked in: wlcore_sdio wl18xx wlcore mac80211 libarc4 cfg80211 rfkill crct10dif_ce phy_gmii_sel ti_am65_cpsw_nuss(-) sch_fq_codel ipv6
      [   31.828776] CPU: 0 PID: 1026 Comm: modprobe Not tainted 6.1.0-rc2-00012-gfabfcf7dafdb-dirty #160
      [   31.837547] Hardware name: Texas Instruments AM625 (DT)
      [   31.842760] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [   31.849709] pc : phy_stop+0x18/0xf8
      [   31.853202] lr : phylink_stop+0x38/0xf8
      [   31.857031] sp : ffff80000a0839f0
      [   31.860335] x29: ffff80000a0839f0 x28: ffff000000de1c80 x27: 0000000000000000
      [   31.867462] x26: 0000000000000000 x25: 0000000000000000 x24: ffff80000a083b98
      [   31.874589] x23: 0000000000000800 x22: 0000000000000001 x21: ffff000001bfba90
      [   31.881715] x20: ffff0000015ee000 x19: 0004000800000200 x18: 0000000000000000
      [   31.888842] x17: ffff800076c45000 x16: ffff800008004000 x15: 000058e39660b106
      [   31.895969] x14: 0000000000000144 x13: 0000000000000144 x12: 0000000000000000
      [   31.903095] x11: 000000000000275f x10: 00000000000009e0 x9 : ffff80000a0837d0
      [   31.910222] x8 : ffff000000de26c0 x7 : ffff00007fbd6540 x6 : ffff00007fbd64c0
      [   31.917349] x5 : ffff00007fbd0b10 x4 : ffff00007fbd0b10 x3 : ffff00007fbd3920
      [   31.924476] x2 : d0a07fcff8b8d500 x1 : 0000000000000000 x0 : 0004000800000200
      [   31.931603] Call trace:
      [   31.934042]  phy_stop+0x18/0xf8
      [   31.937177]  phylink_stop+0x38/0xf8
      [   31.940657]  am65_cpsw_nuss_ndo_slave_stop+0x28/0x1e0 [ti_am65_cpsw_nuss]
      [   31.947452]  __dev_close_many+0xa4/0x140
      [   31.951371]  dev_close_many+0x84/0x128
      [   31.955115]  unregister_netdevice_many+0x130/0x6d0
      [   31.959897]  unregister_netdevice_queue+0x94/0xd8
      [   31.964591]  unregister_netdev+0x24/0x38
      [   31.968504]  am65_cpsw_nuss_cleanup_ndev.isra.0+0x48/0x70 [ti_am65_cpsw_nuss]
      [   31.975637]  am65_cpsw_nuss_remove+0x58/0xf8 [ti_am65_cpsw_nuss]
      
      Cc: <Stable@vger.kernel.org> # v5.18+
      Fixes: e8609e69 ("net: ethernet: ti: am65-cpsw: Convert to PHYLINK")
      Signed-off-by: default avatarRoger Quadros <rogerq@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1a0c016a
    • David S. Miller's avatar
      Merge branch 'macsec-offload-fixes' · f4e405f5
      David S. Miller authored
      Sabrina Dubroca says:
      
      ====================
      macsec: offload-related fixes
      
      I'm working on a dummy offload for macsec on netdevsim. It just has a
      small SecY and RXSC table so I can trigger failures easily on the
      ndo_* side. It has exposed a couple of issues.
      
      The first patch is a revert of commit c850240b ("net: macsec:
      report real_dev features when HW offloading is enabled"). That commit
      tried to improve the performance of macsec offload by taking advantage
      of some of the NIC's features, but in doing so, broke macsec offload
      when the lower device supports both macsec and ipsec offload, as the
      ipsec offload feature flags were copied from the real device. Since
      the macsec device doesn't provide xdo_* ops, the XFRM core rejects the
      registration of the new macsec device in xfrm_api_check.
      
      I'm working on re-adding those feature flags when offload is
      available, but I haven't fully solved that yet. I think it would be
      safer to do that second part in net-next considering how complex
      feature interactions tend to be.
      
      v2:
       - better describe the issue introduced by commit c850240b (Leon
         Romanovsky)
       - patch #3: drop unnecessary !! (Leon Romanovsky)
      
      v3:
       - patch #3: drop extra newline (Jakub Kicinski)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4e405f5
    • Sabrina Dubroca's avatar
      macsec: clear encryption keys from the stack after setting up offload · aaab73f8
      Sabrina Dubroca authored
      macsec_add_rxsa and macsec_add_txsa copy the key to an on-stack
      offloading context to pass it to the drivers, but leaves it there when
      it's done. Clear it with memzero_explicit as soon as it's not needed
      anymore.
      
      Fixes: 3cf3227a ("net: macsec: hardware offloading infrastructure")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarAntoine Tenart <atenart@kernel.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      aaab73f8
    • Sabrina Dubroca's avatar
      macsec: fix detection of RXSCs when toggling offloading · 80df4706
      Sabrina Dubroca authored
      macsec_is_configured incorrectly uses secy->n_rx_sc to check if some
      RXSCs exist. secy->n_rx_sc only counts the number of active RXSCs, but
      there can also be inactive SCs as well, which may be stored in the
      driver (in case we're disabling offloading), or would have to be
      pushed to the device (in case we're trying to enable offloading).
      
      As long as RXSCs active on creation and never turned off, the issue is
      not visible.
      
      Fixes: dcb780fb ("net: macsec: add nla support for changing the offloading selection")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarAntoine Tenart <atenart@kernel.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      80df4706
    • Sabrina Dubroca's avatar
      macsec: fix secy->n_rx_sc accounting · 73a4b31c
      Sabrina Dubroca authored
      secy->n_rx_sc is supposed to be the number of _active_ rxsc's within a
      secy. This is then used by macsec_send_sci to help decide if we should
      add the SCI to the header or not.
      
      This logic is currently broken when we create a new RXSC and turn it
      off at creation, as create_rx_sc always sets ->active to true (and
      immediately uses that to increment n_rx_sc), and only later
      macsec_add_rxsc sets rx_sc->active.
      
      Fixes: c09440f7 ("macsec: introduce IEEE 802.1AE driver")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarAntoine Tenart <atenart@kernel.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      73a4b31c
    • Sabrina Dubroca's avatar
      macsec: delete new rxsc when offload fails · 93a30947
      Sabrina Dubroca authored
      Currently we get an inconsistent state:
       - netlink returns the error to userspace
       - the RXSC is installed but not offloaded
      
      Then the device could get confused when we try to add an RXSA, because
      the RXSC isn't supposed to exist.
      
      Fixes: 3cf3227a ("net: macsec: hardware offloading infrastructure")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarAntoine Tenart <atenart@kernel.org>
      Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      93a30947