1. 25 Mar, 2016 1 commit
    • Alexander Potapenko's avatar
      mm, kasan: add GFP flags to KASAN API · 505f5dcb
      Alexander Potapenko authored
      Add GFP flags to KASAN hooks for future patches to use.
      This patch is based on the "mm: kasan: unified support for SLUB and SLAB
      allocators" patch originally prepared by Dmitry Chernenkov.
      Signed-off-by: default avatarAlexander Potapenko <glider@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Andrey Konovalov <adech.fo@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 17 Mar, 2016 1 commit
    • David Rientjes's avatar
      mm, mempool: only set __GFP_NOMEMALLOC if there are free elements · f9054c70
      David Rientjes authored
      If an oom killed thread calls mempool_alloc(), it is possible that it'll
      loop forever if there are no elements on the freelist since
      __GFP_NOMEMALLOC prevents it from accessing needed memory reserves in
      oom conditions.
      Only set __GFP_NOMEMALLOC if there are elements on the freelist.  If
      there are no free elements, allow allocations without the bit set so
      that memory reserves can be accessed if needed.
      Additionally, using mempool_alloc() with __GFP_NOMEMALLOC is not
      supported since the implementation can loop forever without accessing
      memory reserves when needed.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  3. 12 Mar, 2016 1 commit
  4. 07 Nov, 2015 1 commit
    • Mel Gorman's avatar
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep... · d0164adc
      Mel Gorman authored
      mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd
      __GFP_WAIT has been used to identify atomic context in callers that hold
      spinlocks or are in interrupts.  They are expected to be high priority and
      have access one of two watermarks lower than "min" which can be referred
      to as the "atomic reserve".  __GFP_HIGH users get access to the first
      lower watermark and can be called the "high priority reserve".
      Over time, callers had a requirement to not block when fallback options
      were available.  Some have abused __GFP_WAIT leading to a situation where
      an optimisitic allocation with a fallback option can access atomic
      This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
      cannot sleep and have no alternative.  High priority users continue to use
      __GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
      are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
      callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
      redefined as a caller that is willing to enter direct reclaim and wake
      kswapd for background reclaim.
      This patch then converts a number of sites
      o __GFP_ATOMIC is used by callers that are high priority and have memory
        pools for those requests. GFP_ATOMIC uses this flag.
      o Callers that have a limited mempool to guarantee forward progress clear
        __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
        into this category where kswapd will still be woken but atomic reserves
        are not used as there is a one-entry mempool to guarantee progress.
      o Callers that are checking if they are non-blocking should use the
        helper gfpflags_allow_blocking() where possible. This is because
        checking for __GFP_WAIT as was done historically now can trigger false
        positives. Some exceptions like dm-crypt.c exist where the code intent
        is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
        flag manipulations.
      o Callers that built their own GFP flags instead of starting with GFP_KERNEL
        and friends now also need to specify __GFP_KSWAPD_RECLAIM.
      The first key hazard to watch out for is callers that removed __GFP_WAIT
      and was depending on access to atomic reserves for inconspicuous reasons.
      In some cases it may be appropriate for them to use __GFP_HIGH.
      The second key hazard is callers that assembled their own combination of
      GFP flags instead of starting with something like GFP_KERNEL.  They may
      now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
      if it's missed in most cases as other activity will wake kswapd.
      Signed-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Vitaly Wool <vitalywool@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  5. 08 Sep, 2015 1 commit
  6. 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>
  7. 14 Apr, 2015 1 commit
  8. 06 Jun, 2014 1 commit
  9. 04 Jun, 2014 1 commit
  10. 07 Apr, 2014 1 commit
  11. 11 Sep, 2013 1 commit
  12. 25 Jun, 2012 1 commit
  13. 11 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>
  14. 31 Oct, 2011 1 commit
  15. 22 Sep, 2009 1 commit
  16. 10 Aug, 2009 1 commit
  17. 19 Oct, 2007 1 commit
  18. 17 Jul, 2007 1 commit
  19. 16 Jul, 2007 1 commit
  20. 11 Feb, 2007 1 commit
  21. 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>
  22. 26 Mar, 2006 4 commits
  23. 22 Mar, 2006 1 commit
  24. 28 Oct, 2005 1 commit
  25. 08 Oct, 2005 1 commit
  26. 08 Jul, 2005 1 commit
  27. 23 Jun, 2005 2 commits
  28. 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>
  29. 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!