1. 18 Aug, 2017 1 commit
  2. 28 Jun, 2017 2 commits
  3. 20 May, 2017 1 commit
  4. 04 Apr, 2017 3 commits
  5. 16 Mar, 2017 1 commit
  6. 22 Feb, 2017 2 commits
  7. 26 Jan, 2017 1 commit
  8. 14 Dec, 2016 1 commit
  9. 06 Dec, 2016 2 commits
  10. 14 Nov, 2016 3 commits
  11. 23 Sep, 2016 1 commit
  12. 18 Aug, 2016 1 commit
  13. 16 Aug, 2016 1 commit
  14. 04 Aug, 2016 2 commits
    • Sagi Grimberg's avatar
      nvmet-rdma: Don't use the inline buffer in order to avoid allocation for small reads · 40e64e07
      Sagi Grimberg authored
      Under extreme conditions this might cause data corruptions. By doing that
      we we repost the buffer and then post this buffer for the device to send.
      If we happen to use shared receive queues the device might write to the
      buffer before it sends it (there is no ordering between send and recv
      queues). Without SRQs we probably won't get that if the host doesn't
      mis-behave and send more than we allowed it, but relying on that is not
      really a good idea.
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
    • Sagi Grimberg's avatar
      nvmet-rdma: Correctly handle RDMA device hot removal · d8f7750a
      Sagi Grimberg authored
      When configuring a device attached listener, we may
      see device removal events. In this case we return a
      non-zero return code from the cm event handler which
      implicitly destroys the cm_id. It is possible that in
      the future the user will remove this listener and by
      that trigger a second call to rdma_destroy_id on an
      already destroyed cm_id -> BUG.
      In addition, when a queue bound (active session) cm_id
      generates a DEVICE_REMOVAL event we must guarantee all
      resources are cleaned up by the time we return from the
      event handler.
      Introduce nvmet_rdma_device_removal which addresses
      (or at least attempts to) both scenarios.
      Signed-off-by: default avatarSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
  15. 08 Jul, 2016 1 commit