1. 30 Jun, 2006 1 commit
  2. 22 Jun, 2006 1 commit
  3. 17 Jun, 2006 4 commits
    • Roland Dreier's avatar
      IB/uverbs: Don't serialize with ib_uverbs_idr_mutex · 9ead190b
      Roland Dreier authored
      
      
      Currently, all userspace verbs operations that call into the kernel
      are serialized by ib_uverbs_idr_mutex.  This can be a scalability
      issue for some workloads, especially for devices driven by the ipath
      driver, which needs to call into the kernel even for datapath
      operations.
      
      Fix this by adding reference counts to the userspace objects, and then
      converting ib_uverbs_idr_mutex into a spinlock that only protects the
      idrs long enough to take a reference on the object being looked up.
      Because remove operations may fail, we have to do a slightly funky
      two-step deletion, which is described in the comments at the top of
      uverbs_cmd.c.
      
      This also still leaves ib_uverbs_idr_lock as a single lock that is
      possibly subject to contention.  However, the lock hold time will only
      be a single idr operation, so multiple threads should still be able to
      make progress, even if ib_uverbs_idr_lock is being ping-ponged.
      
      Surprisingly, these changes even shrink the object code:
      
      add/remove: 23/5 grow/shrink: 4/21 up/down: 633/-693 (-60)
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      9ead190b
    • Roland Dreier's avatar
      IB/uverbs: Factor out common idr code · 3463175d
      Roland Dreier authored
      
      
      Factor out common code for adding a userspace object to an idr into a
      function idr_add_uobj().  This shrinks both the source and object code:
      
      add/remove: 1/0 grow/shrink: 0/6 up/down: 57/-220 (-163)
      function                                     old     new   delta
      idr_add_uobj                                   -      57     +57
      ib_uverbs_create_ah                          543     512     -31
      ib_uverbs_create_srq                         662     630     -32
      ib_uverbs_reg_mr                             737     699     -38
      ib_uverbs_create_cq                          639     600     -39
      ib_uverbs_alloc_pd                           485     446     -39
      ib_uverbs_create_qp                         1020     979     -41
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      3463175d
    • Roland Dreier's avatar
      IB/uverbs: Don't decrement usecnt on error paths · 92b15822
      Roland Dreier authored
      
      
      In error paths when destroying an object, uverbs should not decrement
      associated objects' usecnt, since ib_dereg_mr(), ib_destroy_qp(),
      etc. already do that.
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      92b15822
    • Ganapathi CH's avatar
      IB/uverbs: Release lock on error path · 77f76013
      Ganapathi CH authored
      
      
      If ibdev->alloc_ucontext() fails then ib_uverbs_get_context() does not
      unlock file->mutex before returning error.
      
      Signed-off by: Ganapathi CH <cganapathi@novell.com>
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      77f76013
  4. 20 Mar, 2006 7 commits
  5. 13 Jan, 2006 1 commit
  6. 10 Jan, 2006 1 commit
  7. 06 Jan, 2006 3 commits
  8. 29 Nov, 2005 1 commit
  9. 10 Nov, 2005 1 commit
  10. 31 Oct, 2005 1 commit
  11. 28 Oct, 2005 1 commit
  12. 17 Oct, 2005 4 commits
  13. 26 Sep, 2005 1 commit
    • Roland Dreier's avatar
      [IB] uverbs: Close some exploitable races · 63c47c28
      Roland Dreier authored
      
      
      Al Viro pointed out that the current IB userspace verbs interface
      allows userspace to cause mischief by closing file descriptors before
      we're ready, or issuing the same command twice at the same time.  This
      patch closes those races, and fixes other obvious problems such as a
      module reference leak.
      
      Some other interface bogosities will require an ABI change to fix
      properly, so I'm deferring those fixes until 2.6.15.
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      63c47c28
  14. 09 Sep, 2005 1 commit
    • Roland Dreier's avatar
      Make sure that userspace does not retrieve stale asynchronous or · 63aaf647
      Roland Dreier authored
      
      completion events after destroying a CQ, QP or SRQ.  We do this by
      sweeping the event lists before returning from a destroy calls, and
      then return the number of events already reported before the destroy
      call.  This allows userspace wait until it has processed all events
      for an object returned from the kernel before it frees its context for
      the object.
      
      The ABI of the destroy CQ, destroy QP and destroy SRQ commands has to
      change to return the event count, so bump the ABI version from 1 to 2.
      The userspace libibverbs library has already been updated to handle
      both the old and new ABI versions.
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      63aaf647
  15. 26 Aug, 2005 1 commit
    • Roland Dreier's avatar
      [PATCH] IB: userspace SRQ support · f520ba5a
      Roland Dreier authored
      
      
      Add SRQ support to userspace verbs module.  This adds several commands
      and associated structures, but it's OK to do this without bumping the
      ABI version because the commands are added at the end of the list so
      they don't change the existing numbering.  There are two cases to
      worry about:
      
      1. New kernel, old userspace.  This is OK because old userspace simply
         won't try to use the new SRQ commands.  None of the old commands are
         changed.
      
      2. Old kernel, new userspace.  This works perfectly as long as
         userspace doesn't try to use SRQ commands.  If userspace tries to
         use SRQ commands, it will get EINVAL, which is perfectly
         reasonable: the kernel doesn't support SRQs, so we couldn't do any
         better.
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
      f520ba5a
  16. 07 Jul, 2005 1 commit