1. 30 May, 2018 1 commit
  2. 25 Apr, 2017 2 commits
  3. 16 Dec, 2014 4 commits
  4. 19 Sep, 2014 1 commit
    • Shawn Bohrer's avatar
      IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get · 87773dd5
      Shawn Bohrer authored
      In debugging an application that receives -ENOMEM from ib_reg_mr(), I
      found that ib_umem_get() can fail because the pinned_vm count has
      wrapped causing it to always be larger than the lock limit even with
      The wrapping of pinned_vm occurs because the process that calls
      ib_reg_mr() will have its mm->pinned_vm count incremented.  Later a
      different process with a different mm_struct than the one that
      allocated the ib_umem struct ends up releasing it which results in
      decrementing the new processes mm->pinned_vm count past zero and
      I'm not entirely sure what circumstances cause a different process to
      release the ib_umem than the one that allocated it but the kernel
      stack trace of the freeing process from my situation looks like the
          Call Trace:
           [<ffffffff814d64b1>] dump_stack+0x19/0x1b
           [<ffffffffa0b522a5>] ib_umem_release+0x1f5/0x200 [ib_core]
           [<ffffffffa0b90681>] mlx4_ib_destroy_qp+0x241/0x440 [mlx4_ib]
           [<ffffffffa0b4d93c>] ib_destroy_qp+0x12c/0x170 [ib_core]
           [<ffffffffa0cc7129>] ib_uverbs_close+0x259/0x4e0 [ib_uverbs]
           [<ffffffff81141cba>] __fput+0xba/0x240
           [<ffffffff81141e4e>] ____fput+0xe/0x10
           [<ffffffff81060894>] task_work_run+0xc4/0xe0
           [<ffffffff810029e5>] do_notify_resume+0x95/0xa0
           [<ffffffff814e3dd0>] int_signal+0x12/0x17
      The following patch fixes the issue by storing the pid struct of the
      process that calls ib_umem_get() so that ib_umem_release and/or
      ib_umem_account() can properly decrement the pinned_vm count of the
      correct mm_struct.
      Signed-off-by: default avatarShawn Bohrer <sbohrer@rgmadvisors.com>
      Reviewed-by: default avatarShachar Raindel <raindel@mellanox.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
  5. 04 Mar, 2014 1 commit
  6. 29 Apr, 2008 1 commit
    • Arthur Kepner's avatar
      IB: expand ib_umem_get() prototype · cb9fbc5c
      Arthur Kepner authored
      Add a new parameter, dmasync, to the ib_umem_get() prototype.  Use dmasync = 1
      when mapping user-allocated CQs with ib_umem_get().
      Signed-off-by: default avatarArthur Kepner <akepner@sgi.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Jes Sorensen <jes@sgi.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Roland Dreier <rdreier@cisco.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 10 Oct, 2007 1 commit
  8. 21 May, 2007 1 commit
    • Alexey Dobriyan's avatar
      Detach sched.h from mm.h · e8edc6e0
      Alexey Dobriyan authored
      First thing mm.h does is including sched.h solely for can_do_mlock() inline
      function which has "current" dereference inside. By dealing with can_do_mlock()
      mm.h can be detached from sched.h which is good. See below, why.
      This patch
      a) removes unconditional inclusion of sched.h from mm.h
      b) makes can_do_mlock() normal function in mm/mlock.c
      c) exports can_do_mlock() to not break compilation
      d) adds sched.h inclusions back to files that were getting it indirectly.
      e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
         getting them indirectly
      Net result is:
      a) mm.h users would get less code to open, read, preprocess, parse, ... if
         they don't need sched.h
      b) sched.h stops being dependency for significant number of files:
         on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
         after patch it's only 3744 (-8.3%).
      Cross-compile tested on
      	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
      	alpha alpha-up
      	i386 i386-up i386-defconfig i386-allnoconfig
      	ia64 ia64-up
      	parisc parisc-up
      	powerpc powerpc-up
      	s390 s390-up
      	sparc sparc-up
      	sparc64 sparc64-up
      	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
      as well as my two usual configs.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  9. 09 May, 2007 2 commits
    • Roland Dreier's avatar
      IB: Put rlimit accounting struct in struct ib_umem · 1bf66a30
      Roland Dreier authored
      When memory pinned with ib_umem_get() is released, ib_umem_release()
      needs to subtract the amount of memory being unpinned from
      mm->locked_vm.  However, ib_umem_release() may be called with
      mm->mmap_sem already held for writing if the memory is being released
      as part of an munmap() call, so it is sometimes necessary to defer
      this accounting into a workqueue.
      However, the work struct used to defer this accounting is dynamically
      allocated before it is queued, so there is the possibility of failing
      that allocation.  If the allocation fails, then ib_umem_release has no
      choice except to bail out and leave the process with a permanently
      elevated locked_vm.
      Fix this by allocating the structure to defer accounting as part of
      the original struct ib_umem, so there's no possibility of failing a
      later allocation if creating the struct ib_umem and pinning memory
      Signed-off-by: default avatarRoland Dreier <rolandd@cisco.com>
    • Roland Dreier's avatar
      IB/uverbs: Export ib_umem_get()/ib_umem_release() to modules · f7c6a7b5
      Roland Dreier authored
      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
      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: default avatarRoland Dreier <rolandd@cisco.com>
  10. 27 Aug, 2005 1 commit
  11. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!