diff options
author | Roland Dreier <rolandd@cisco.com> | 2007-04-18 20:20:28 -0700 |
---|---|---|
committer | Roland Dreier <rolandd@cisco.com> | 2007-05-08 18:00:37 -0700 |
commit | 1bf66a30421ca772820f489d88c16d0c430d6a67 (patch) | |
tree | b1ab223e6908d772bcad7f9bc3382c33ad5a4490 /drivers/net/Kconfig | |
parent | f7c6a7b5d59980b076abbf2ceeb8735591290285 (diff) | |
download | kernel-crypto-1bf66a30421ca772820f489d88c16d0c430d6a67.tar.gz kernel-crypto-1bf66a30421ca772820f489d88c16d0c430d6a67.tar.xz kernel-crypto-1bf66a30421ca772820f489d88c16d0c430d6a67.zip |
IB: Put rlimit accounting struct in struct ib_umem
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
succeeds.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'drivers/net/Kconfig')
0 files changed, 0 insertions, 0 deletions