1. 27 Jan, 2020 1 commit
    • Håkon Bugge's avatar
      IB/mlx4: Fix leak in id_map_find_del · ea660ad7
      Håkon Bugge authored
      Using CX-3 virtual functions, either from a bare-metal machine or
      pass-through from a VM, MAD packets are proxied through the PF driver.
      
      Since the VF drivers have separate name spaces for MAD Transaction Ids
      (TIDs), the PF driver has to re-map the TIDs and keep the book keeping in
      a cache.
      
      Following the RDMA Connection Manager (CM) protocol, it is clear when an
      entry has to evicted from the cache. When a DREP is sent from
      mlx4_ib_multiplex_cm_handler(), id_map_find_del() is called. Similar when
      a REJ is received by the mlx4_ib_demux_cm_handler(), id_map_find_del() is
      called.
      
      This function wipes out the TID in use from the IDR or XArray and removes
      the id_map_entry from the table.
      
      In short, it does everything except the topping of the cake, which is to
      remove the entry from the list and free it. In other words, for the REJ
      case enumerated above, one id_map_entry will be leaked.
      
      For the other case above, a DREQ has been received first. The reception of
      the DREQ will trigger queuing of a delayed work to delete the
      id_map_entry, for the case where the VM doesn't send back a DREP.
      
      In the normal case, the VM _will_ send back a DREP, and id_map_find_del()
      will be called.
      
      But this scenario introduces a secondary leak. First, when the DREQ is
      received, a delayed work is queued. The VM will then return a DREP, which
      will call id_map_find_del(). As stated above, this will free the TID used
      from the XArray or IDR. Now, there is window where that particular TID can
      be re-allocated, lets say by an outgoing REQ. This TID will later be wiped
      out by the delayed work, when the function id_map_ent_timeout() is
      called. But the id_map_entry allocated by the outgoing REQ will not be
      de-allocated, and we have a leak.
      
      Both leaks are fixed by removing the id_map_find_del() function and only
      using schedule_delayed(). Of course, a check in schedule_delayed() to see
      if the work already has been queued, has been added.
      
      Another benefit of always using the delayed version for deleting entries,
      is that we do get a TimeWait effect; a TID no longer in use, will occupy
      the XArray or IDR for CM_CLEANUP_CACHE_TIMEOUT time, without any ability
      of being re-used for that time period.
      
      Fixes: 3cf69cc8 ("IB/mlx4: Add CM paravirtualization")
      Link: https://lore.kernel.org/r/20200123155521.1212288-1-haakon.bugge@oracle.comSigned-off-by: default avatarHåkon Bugge <haakon.bugge@oracle.com>
      Signed-off-by: default avatarManjunath Patil <manjunath.b.patil@oracle.com>
      Reviewed-by: default avatarRama Nichanamatlu <rama.nichanamatlu@oracle.com>
      Reviewed-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      ea660ad7
  2. 25 Jan, 2020 11 commits
  3. 21 Jan, 2020 1 commit
    • Jason Gunthorpe's avatar
      Merge tag 'rds-odp-for-5.5' into rdma.git for-next · e8b3a426
      Jason Gunthorpe authored
      From https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma
      
      Leon Romanovsky says:
      
      ====================
      Use ODP MRs for kernel ULPs
      
      The following series extends MR creation routines to allow creation of
      user MRs through kernel ULPs as a proxy. The immediate use case is to
      allow RDS to work over FS-DAX, which requires ODP (on-demand-paging)
      MRs to be created and such MRs were not possible to create prior this
      series.
      
      The first part of this patchset extends RDMA to have special verb
      ib_reg_user_mr(). The common use case that uses this function is a
      userspace application that allocates memory for HCA access but the
      responsibility to register the memory at the HCA is on an kernel ULP.
      This ULP acts as an agent for the userspace application.
      
      The second part provides advise MR functionality for ULPs. This is
      integral part of ODP flows and used to trigger pagefaults in advance
      to prepare memory before running working set.
      
      The third part is actual user of those in-kernel APIs.
      ====================
      
      * tag 'rds-odp-for-5.5':
        net/rds: Use prefetch for On-Demand-Paging MR
        net/rds: Handle ODP mr registration/unregistration
        net/rds: Detect need of On-Demand-Paging memory registration
        RDMA/mlx5: Fix handling of IOVA != user_va in ODP paths
        IB/mlx5: Mask out unsupported ODP capabilities for kernel QPs
        RDMA/mlx5: Don't fake udata for kernel path
        IB/mlx5: Add ODP WQE handlers for kernel QPs
        IB/core: Add interface to advise_mr for kernel users
        IB/core: Introduce ib_reg_user_mr
        IB: Allow calls to ib_umem_get from kernel ULPs
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      e8b3a426
  4. 18 Jan, 2020 2 commits
  5. 16 Jan, 2020 22 commits
  6. 15 Jan, 2020 3 commits