1. 07 1月, 2006 2 次提交
  2. 30 11月, 2005 1 次提交
  3. 11 11月, 2005 1 次提交
  4. 31 10月, 2005 1 次提交
  5. 29 10月, 2005 1 次提交
  6. 18 10月, 2005 4 次提交
  7. 27 9月, 2005 1 次提交
    • R
      [IB] uverbs: Close some exploitable races · 63c47c28
      Roland Dreier 提交于
      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: NRoland Dreier <rolandd@cisco.com>
      63c47c28
  8. 10 9月, 2005 1 次提交
    • R
      Make sure that userspace does not retrieve stale asynchronous or · 63aaf647
      Roland Dreier 提交于
      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: NRoland Dreier <rolandd@cisco.com>
      63aaf647
  9. 27 8月, 2005 1 次提交
    • R
      [PATCH] IB: userspace SRQ support · f520ba5a
      Roland Dreier 提交于
      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: NRoland Dreier <rolandd@cisco.com>
      f520ba5a
  10. 08 7月, 2005 1 次提交