1. 18 7月, 2007 2 次提交
  2. 19 5月, 2007 1 次提交
  3. 09 5月, 2007 1 次提交
    • R
      IB/uverbs: Export ib_umem_get()/ib_umem_release() to modules · f7c6a7b5
      Roland Dreier 提交于
      Export ib_umem_get()/ib_umem_release() and put low-level drivers in
      control of when to call ib_umem_get() to pin and DMA map userspace,
      rather than always calling it in ib_uverbs_reg_mr() before calling the
      low-level driver's reg_user_mr method.
      
      Also move these functions to be in the ib_core module instead of
      ib_uverbs, so that driver modules using them do not depend on
      ib_uverbs.
      
      This has a number of advantages:
       - It is better design from the standpoint of making generic code a
         library that can be used or overridden by device-specific code as
         the details of specific devices dictate.
       - Drivers that do not need to pin userspace memory regions do not
         need to take the performance hit of calling ib_mem_get().  For
         example, although I have not tried to implement it in this patch,
         the ipath driver should be able to avoid pinning memory and just
         use copy_{to,from}_user() to access userspace memory regions.
       - Buffers that need special mapping treatment can be identified by
         the low-level driver.  For example, it may be possible to solve
         some Altix-specific memory ordering issues with mthca CQs in
         userspace by mapping CQ buffers with extra flags.
       - Drivers that need to pin and DMA map userspace memory for things
         other than memory regions can use ib_umem_get() directly, instead
         of hacks using extra parameters to their reg_phys_mr method.  For
         example, the mlx4 driver that is pending being merged needs to pin
         and DMA map QP and CQ buffers, but it does not need to create a
         memory key for these buffers.  So the cleanest solution is for mlx4
         to call ib_umem_get() in the create_qp and create_cq methods.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f7c6a7b5
  4. 12 2月, 2007 1 次提交
  5. 10 1月, 2007 1 次提交
    • H
      IB/ehca: Use proper GFP_ flags for get_zeroed_page() · f2d91361
      Hoang-Nam Nguyen 提交于
      Here is a patch for ehca to use proper flag, ie. GFP_ATOMIC
      resp. GFP_KERNEL, when calling get_zeroed_page() to prevent "Bug:
      scheduling while atomic...". This error does not cause a kernel panic
      but makes ipoib un-usable afterwards.  It is reproducible on
      2.6.20-rc4 if one does ifconfig down during a flood ping test.  I have
      not observed this error in earlier releases incl. 2.6.20-rc1.
      
      This error occurs when a qp event/irq is received and ehca event
      handler allocates a control block/page to obtain HCA error data block.
      Use of GFP_ATOMIC when in interrupt context prevents this issue.
      
      Signed-off-by Hoang-Nam Nguyen <hnguyen@de.ibm.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f2d91361
  6. 08 12月, 2006 1 次提交
  7. 10 11月, 2006 1 次提交
  8. 23 9月, 2006 1 次提交