1. 15 Apr, 2015 3 commits
    • Andrey Ryabinin's avatar
      mm/mempool.c: kasan: poison mempool elements · 92393615
      Andrey Ryabinin authored
      Mempools keep allocated objects in reserved for situations when ordinary
      allocation may not be possible to satisfy.  These objects shouldn't be
      accessed before they leave the pool.
      This patch poison elements when get into the pool and unpoison when they
      leave it.  This will let KASan to detect use-after-free of mempool's
      Signed-off-by: default avatarAndrey Ryabinin <a.ryabinin@samsung.com>
      Tested-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dmitry Chernenkov <drcheren@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • David Rientjes's avatar
      mm, mempool: poison elements backed by slab allocator · bdfedb76
      David Rientjes authored
      Mempools keep elements in a reserved pool for contexts in which allocation
      may not be possible.  When an element is allocated from the reserved pool,
      its memory contents is the same as when it was added to the reserved pool.
      Because of this, elements lack any free poisoning to detect use-after-free
      This patch adds free poisoning for elements backed by the slab allocator.
      This is possible because the mempool layer knows the object size of each
      When an element is added to the reserved pool, it is poisoned with
      POISON_FREE.  When it is removed from the reserved pool, the contents are
      checked for POISON_FREE.  If there is a mismatch, a warning is emitted to
      the kernel log.
      This is only effective for configs with CONFIG_DEBUG_SLAB or
      [fabio.estevam@freescale.com: use '%zu' for printing 'size_t' variable]
      [arnd@arndb.de: add missing include]
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Dave Kleikamp <shaggy@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: Mikulas Patocka <mpatocka@redhat.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • David Rientjes's avatar
      mm, mempool: disallow mempools based on slab caches with constructors · e244c9e6
      David Rientjes authored
      All occurrences of mempools based on slab caches with object constructors
      have been removed from the tree, so disallow creating them.
      We can only dereference mem->ctor in mm/mempool.c without including
      mm/slab.h in include/linux/mempool.h.  So simply note the restriction,
      just like the comment restricting usage of __GFP_ZERO, and warn on kernels
      with CONFIG_DEBUG_VM() if such a mempool is allocated from.
      We don't want to incur this check on every element allocation, so use
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Dave Kleikamp <shaggy@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: Mikulas Patocka <mpatocka@redhat.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 14 Apr, 2015 1 commit
  3. 06 Jun, 2014 1 commit
  4. 04 Jun, 2014 1 commit
  5. 07 Apr, 2014 1 commit
  6. 11 Sep, 2013 1 commit
  7. 25 Jun, 2012 1 commit
  8. 10 Jan, 2012 3 commits
    • Tejun Heo's avatar
      mempool: fix first round failure behavior · 1ebb7044
      Tejun Heo authored
      mempool modifies gfp_mask so that the backing allocator doesn't try too
      hard or trigger warning message when there's pool to fall back on.  In
      addition, for the first try, it removes __GFP_WAIT and IO, so that it
      doesn't trigger reclaim or wait when allocation can be fulfilled from
      pool; however, when that allocation fails and pool is empty too, it waits
      for the pool to be replenished before retrying.
      Allocation which could have succeeded after a bit of reclaim has to wait
      on the reserved items and it's not like mempool doesn't retry with
      __GFP_WAIT and IO.  It just does that *after* someone returns an element,
      pointlessly delaying things.
      Fix it by retrying immediately if the first round of allocation attempts
      w/o __GFP_WAIT and IO fails.
      [akpm@linux-foundation.org: shorten the lock hold time]
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Tejun Heo's avatar
      mempool: drop unnecessary and incorrect BUG_ON() from mempool_destroy() · 0565d317
      Tejun Heo authored
      mempool_destroy() is a thin wrapper around free_pool().  The only thing it
      adds is BUG_ON(pool->curr_nr != pool->min_nr).  The intention seems to be
      to enforce that all allocated elements are freed; however, the BUG_ON()
      can't achieve that (it doesn't know anything about objects above min_nr)
      and incorrect as mempool_resize() is allowed to leave the pool extended
      but not filled.  Furthermore, panicking is way worse than any memory leak
      and there are better debug tools to track memory leaks.
      Drop the BUG_ON() from mempool_destory() and as that leaves the function
      identical to free_pool(), replace it.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Tejun Heo's avatar
      mempool: fix and document synchronization and memory barrier usage · 5b990546
      Tejun Heo authored
      mempool_alloc/free() use undocumented smp_mb()'s.  The code is slightly
      broken and misleading.
      The lockless part is in mempool_free().  It wants to determine whether the
      item being freed needs to be returned to the pool or backing allocator
      without grabbing pool->lock.  Two things need to be guaranteed for correct
      1. pool->curr_nr + #allocated should never dip below pool->min_nr.
      2. Waiters shouldn't be left dangling.
      For #1, The only necessary condition is that curr_nr visible at free is
      from after the allocation of the element being freed (details in the
      comment).  For most cases, this is true without any barrier but there can
      be fringe cases where the allocated pointer is passed to the freeing task
      without going through memory barriers.  To cover this case, wmb is
      necessary before returning from allocation and rmb is necessary before
      reading curr_nr.  IOW,
      	update pool state after alloc;
      	pass pointer to freeing task;
      					read pointer;
      					read pool state to free;
      The current code doesn't have wmb after pool update during allocation and
      may theoretically, on machines where unlock doesn't behave as full wmb,
      lead to pool depletion and deadlock.  smp_wmb() needs to be added after
      successful allocation from reserved elements and smp_mb() in
      mempool_free() can be replaced with smp_rmb().
      For #2, the waiter needs to add itself to waitqueue and then check the
      wait condition and the waker needs to update the wait condition and then
      wake up.  Because waitqueue operations always go through full spinlock
      synchronization, there is no need for extra memory barriers.
      Furthermore, mempool_alloc() is already holding pool->lock when it decides
      that it needs to wait.  There is no reason to do unlock - add waitqueue -
      test condition again.  It can simply add itself to waitqueue while holding
      pool->lock and then unlock and sleep.
      This patch adds smp_wmb() after successful allocation from reserved pool,
      replaces smp_mb() in mempool_free() with smp_rmb() and extend pool->lock
      over waitqueue addition.  More importantly, it explains what memory
      barriers do and how the lockless testing is correct.
      -v2: Oleg pointed out that unlock doesn't imply wmb.  Added explicit
           smp_wmb() after successful allocation from reserved pool and
           updated comments accordingly.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  9. 31 Oct, 2011 1 commit
  10. 22 Sep, 2009 1 commit
  11. 10 Aug, 2009 1 commit
  12. 19 Oct, 2007 1 commit
  13. 17 Jul, 2007 1 commit
  14. 16 Jul, 2007 1 commit
  15. 11 Feb, 2007 1 commit
  16. 01 Sep, 2006 1 commit
    • Pavel Mironchik's avatar
      [PATCH] dm: work around mempool_alloc, bio_alloc_bioset deadlocks · 0b1d647a
      Pavel Mironchik authored
      This patch works around a complex dm-related deadlock/livelock down in the
      mempool allocator.
      Alasdair said:
        Several dm targets suffer from this.
        Mempools are not yet used correctly everywhere in device-mapper: they can
        get shared when devices are stacked, and some targets share them across
        multiple instances.  I made fixing this one of the prerequisites for this
        which in some cases makes people more likely to hit the problem.
        There's been some progress on this recently with (unfinished) dm-crypt
        patches at:
            (dm-crypt-move-io-to-workqueue.patch plus dependencies)
        I've no problems with a temporary workaround like that, but Milan Broz (a
        new Redhat developer in the Czech Republic) has started reviewing all the
        mempool usage in device-mapper so I'm expecting we'll soon have a proper fix
        for this associated problems.  [He's back from holiday at the start of next
      For now, this sad-but-safe little patch will allow the machine to recover.
      [akpm@osdl.org: rewrote changelog]
      Cc: Alasdair G Kergon <agk@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  17. 26 Mar, 2006 4 commits
  18. 22 Mar, 2006 1 commit
  19. 28 Oct, 2005 1 commit
  20. 08 Oct, 2005 1 commit
  21. 07 Jul, 2005 1 commit
  22. 23 Jun, 2005 2 commits
  23. 01 May, 2005 3 commits
    • akpm@osdl.org's avatar
      [PATCH] use smp_mb/wmb/rmb where possible · d59dd462
      akpm@osdl.org authored
      Replace a number of memory barriers with smp_ variants.  This means we won't
      take the unnecessary hit on UP machines.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Nick Piggin's avatar
      [PATCH] mempool: simplify alloc · 20a77776
      Nick Piggin authored
      Mempool is pretty clever.  Looks too clever for its own good :) It
      shouldn't really know so much about page reclaim internals.
      - don't guess about what effective page reclaim might involve.
      - don't randomly flush out all dirty data if some unlikely thing
        happens (alloc returns NULL). page reclaim can (sort of :P) handle
      I think the main motivation is trying to avoid pool->lock at all costs.
      However the first allocation is attempted with __GFP_WAIT cleared, so it
      will be 'can_try_harder' if it hits the page allocator.  So if allocation
      still fails, then we can probably afford to hit the pool->lock - and what's
      the alternative?  Try page reclaim and hit zone->lru_lock?
      A nice upshot is that we don't need to do any fancy memory barriers or do
      (intentionally) racy access to pool-> fields outside the lock.
      Signed-off-by: default avatarNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Nick Piggin's avatar
      [PATCH] mempool: NOMEMALLOC and NORETRY · b84a35be
      Nick Piggin authored
      Mempools have 2 problems.
      The first is that mempool_alloc can possibly get stuck in __alloc_pages
      when they should opt to fail, and take an element from their reserved pool.
      The second is that it will happily eat emergency PF_MEMALLOC reserves
      instead of going to their reserved pools.
      Fix the first by passing __GFP_NORETRY in the allocation calls in
      mempool_alloc.  Fix the second by introducing a __GFP_MEMPOOL flag which
      directs the page allocator not to allocate from the reserve pool.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  24. 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!