lkml.org 
[lkml]   [2017]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 4.10 61/93] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC
    Date
    4.10-stable review patch.  If anyone has any objections, please let me know.

    ------------------

    From: Vlastimil Babka <vbabka@suse.cz>

    commit 62be1511b1db8066220b18b7d4da2e6b9fdc69fb upstream.

    Patch series "more robust PF_MEMALLOC handling"

    This series aims to unify the setting and clearing of PF_MEMALLOC, which
    prevents recursive reclaim. There are some places that clear the flag
    unconditionally from current->flags, which may result in clearing a
    pre-existing flag. This already resulted in a bug report that Patch 1
    fixes (without the new helpers, to make backporting easier). Patch 2
    introduces the new helpers, modelled after existing memalloc_noio_* and
    memalloc_nofs_* helpers, and converts mm core to use them. Patches 3
    and 4 convert non-mm code.

    This patch (of 4):

    __alloc_pages_direct_compact() sets PF_MEMALLOC to prevent deadlock
    during page migration by lock_page() (see the comment in
    __unmap_and_move()). Then it unconditionally clears the flag, which can
    clear a pre-existing PF_MEMALLOC flag and result in recursive reclaim.
    This was not a problem until commit a8161d1ed609 ("mm, page_alloc:
    restructure direct compaction handling in slowpath"), because direct
    compation was called only after direct reclaim, which was skipped when
    PF_MEMALLOC flag was set.

    Even now it's only a theoretical issue, as the new callsite of
    __alloc_pages_direct_compact() is reached only for costly orders and
    when gfp_pfmemalloc_allowed() is true, which means either
    __GFP_NOMEMALLOC is in gfp_flags or in_interrupt() is true. There is no
    such known context, but let's play it safe and make
    __alloc_pages_direct_compact() robust for cases where PF_MEMALLOC is
    already set.

    Fixes: a8161d1ed609 ("mm, page_alloc: restructure direct compaction handling in slowpath")
    Link: http://lkml.kernel.org/r/20170405074700.29871-2-vbabka@suse.cz
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Johannes Weiner <hannes@cmpxchg.org>
    Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
    Cc: Chris Leech <cleech@redhat.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Josef Bacik <jbacik@fb.com>
    Cc: Lee Duncan <lduncan@suse.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Richard Weinberger <richard@nod.at>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    ---
    mm/page_alloc.c | 3 ++-
    1 file changed, 2 insertions(+), 1 deletion(-)

    --- a/mm/page_alloc.c
    +++ b/mm/page_alloc.c
    @@ -3144,6 +3144,7 @@ __alloc_pages_direct_compact(gfp_t gfp_m
    enum compact_priority prio, enum compact_result *compact_result)
    {
    struct page *page;
    + unsigned int noreclaim_flag = current->flags & PF_MEMALLOC;

    if (!order)
    return NULL;
    @@ -3151,7 +3152,7 @@ __alloc_pages_direct_compact(gfp_t gfp_m
    current->flags |= PF_MEMALLOC;
    *compact_result = try_to_compact_pages(gfp_mask, order, alloc_flags, ac,
    prio);
    - current->flags &= ~PF_MEMALLOC;
    + current->flags = (current->flags & ~PF_MEMALLOC) | noreclaim_flag;

    if (*compact_result <= COMPACT_INACTIVE)
    return NULL;

    \
     
     \ /
      Last update: 2017-05-18 13:41    [W:4.241 / U:25.768 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site