All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	<linux-block@vger.kernel.org>,
	<nbd-general@lists.sourceforge.net>,
	<open-iscsi@googlegroups.com>, <linux-scsi@vger.kernel.org>,
	<netdev@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC
Date: Wed, 5 Apr 2017 14:40:43 +0300	[thread overview]
Message-ID: <1f26f654-abaf-3878-6abb-5e27ff3a289e@virtuozzo.com> (raw)
In-Reply-To: <20170405074700.29871-2-vbabka@suse.cz>

On 04/05/2017 10:46 AM, Vlastimil Babka wrote:
> The function __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
                           is false			

> 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")
> Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Cc: <stable@vger.kernel.org>
> ---
>  mm/page_alloc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3589f8be53be..b84e6ffbe756 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3288,6 +3288,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>  		enum compact_priority prio, enum compact_result *compact_result)
>  {
>  	struct page *page;
> +	unsigned int noreclaim_flag = current->flags & PF_MEMALLOC;
>  
>  	if (!order)
>  		return NULL;
> @@ -3295,7 +3296,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>  	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;

Perhaps this would look better:

	tsk_restore_flags(current, noreclaim_flag, PF_MEMALLOC);

?

>  	if (*compact_result <= COMPACT_INACTIVE)
>  		return NULL;
> 

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	<linux-block@vger.kernel.org>,
	<nbd-general@lists.sourceforge.net>,
	<open-iscsi@googlegroups.com>, <linux-scsi@vger.kernel.org>,
	<netdev@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC
Date: Wed, 5 Apr 2017 14:40:43 +0300	[thread overview]
Message-ID: <1f26f654-abaf-3878-6abb-5e27ff3a289e@virtuozzo.com> (raw)
In-Reply-To: <20170405074700.29871-2-vbabka@suse.cz>

On 04/05/2017 10:46 AM, Vlastimil Babka wrote:
> The function __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
                           is false			

> 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")
> Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Cc: <stable@vger.kernel.org>
> ---
>  mm/page_alloc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3589f8be53be..b84e6ffbe756 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3288,6 +3288,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>  		enum compact_priority prio, enum compact_result *compact_result)
>  {
>  	struct page *page;
> +	unsigned int noreclaim_flag = current->flags & PF_MEMALLOC;
>  
>  	if (!order)
>  		return NULL;
> @@ -3295,7 +3296,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>  	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;

Perhaps this would look better:

	tsk_restore_flags(current, noreclaim_flag, PF_MEMALLOC);

?

>  	if (*compact_result <= COMPACT_INACTIVE)
>  		return NULL;
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Michal Hocko <mhocko@kernel.org>,
	Mel Gorman <mgorman@techsingularity.net>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-block@vger.kernel.org, nbd-general@lists.sourceforge.net,
	open-iscsi@googlegroups.com, linux-scsi@vger.kernel.org,
	netdev@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC
Date: Wed, 5 Apr 2017 14:40:43 +0300	[thread overview]
Message-ID: <1f26f654-abaf-3878-6abb-5e27ff3a289e@virtuozzo.com> (raw)
In-Reply-To: <20170405074700.29871-2-vbabka@suse.cz>

On 04/05/2017 10:46 AM, Vlastimil Babka wrote:
> The function __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
                           is false			

> 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")
> Reported-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> Cc: <stable@vger.kernel.org>
> ---
>  mm/page_alloc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3589f8be53be..b84e6ffbe756 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3288,6 +3288,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>  		enum compact_priority prio, enum compact_result *compact_result)
>  {
>  	struct page *page;
> +	unsigned int noreclaim_flag = current->flags & PF_MEMALLOC;
>  
>  	if (!order)
>  		return NULL;
> @@ -3295,7 +3296,7 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order,
>  	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;

Perhaps this would look better:

	tsk_restore_flags(current, noreclaim_flag, PF_MEMALLOC);

?

>  	if (*compact_result <= COMPACT_INACTIVE)
>  		return NULL;
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2017-04-05 11:39 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05  7:46 [PATCH 0/4] more robust PF_MEMALLOC handling Vlastimil Babka
2017-04-05  7:46 ` Vlastimil Babka
2017-04-05  7:46 ` [PATCH 1/4] mm: prevent potential recursive reclaim due to clearing PF_MEMALLOC Vlastimil Babka
2017-04-05  7:46   ` Vlastimil Babka
2017-04-05  7:46   ` Vlastimil Babka
2017-04-05 11:21   ` Michal Hocko
2017-04-05 11:21     ` Michal Hocko
2017-04-05 11:40   ` Andrey Ryabinin [this message]
2017-04-05 11:40     ` Andrey Ryabinin
2017-04-05 11:40     ` Andrey Ryabinin
2017-04-07  9:21     ` Vlastimil Babka
2017-04-07  9:21       ` Vlastimil Babka
2017-04-07  7:33   ` Hillf Danton
2017-04-07  7:33     ` Hillf Danton
2017-04-07  7:33     ` Hillf Danton
2017-04-05  7:46 ` [PATCH 2/4] mm: introduce memalloc_noreclaim_{save,restore} Vlastimil Babka
2017-04-05  7:46   ` Vlastimil Babka
2017-04-05 11:28   ` Michal Hocko
2017-04-05 11:28     ` Michal Hocko
2017-04-05 11:28     ` [PATCH 2/4] mm: introduce memalloc_noreclaim_{save, restore} Michal Hocko
2017-04-07  7:38   ` [PATCH 2/4] mm: introduce memalloc_noreclaim_{save,restore} Hillf Danton
2017-04-07  7:38     ` Hillf Danton
2017-04-07  7:38     ` Hillf Danton
2017-04-05  7:46 ` [PATCH 3/4] treewide: convert PF_MEMALLOC manipulations to new helpers Vlastimil Babka
2017-04-05  7:46   ` Vlastimil Babka
2017-04-05  7:46   ` Vlastimil Babka
2017-04-05 11:30   ` Michal Hocko
2017-04-05 11:30     ` Michal Hocko
2017-04-05 11:30     ` Michal Hocko
2017-04-06  6:38     ` [Nbd] " Wouter Verhelst
2017-04-06  6:38       ` Wouter Verhelst
2017-04-06  6:38       ` Wouter Verhelst
2017-04-06 11:25       ` [Nbd] " Mel Gorman
2017-04-06 11:25         ` Mel Gorman
2017-04-05  7:47 ` [PATCH 4/4] mtd: nand: nandsim: convert to memalloc_noreclaim_*() Vlastimil Babka
2017-04-05  7:47   ` Vlastimil Babka
2017-04-05  7:47   ` Vlastimil Babka
2017-04-05 11:31   ` Michal Hocko
2017-04-05 11:31     ` Michal Hocko
2017-04-05 11:36     ` Richard Weinberger
2017-04-05 11:36       ` Richard Weinberger
2017-04-05 11:39       ` Vlastimil Babka
2017-04-05 11:39         ` Vlastimil Babka
2017-04-05 12:09         ` Michal Hocko
2017-04-05 12:09           ` Michal Hocko
2017-04-06  6:33         ` Adrian Hunter
2017-04-06  6:33           ` Adrian Hunter
2017-04-06  7:27           ` Michal Hocko
2017-04-06  7:27             ` Michal Hocko
2017-04-06  7:27             ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1f26f654-abaf-3878-6abb-5e27ff3a289e@virtuozzo.com \
    --to=aryabinin@virtuozzo.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=nbd-general@lists.sourceforge.net \
    --cc=netdev@vger.kernel.org \
    --cc=open-iscsi@googlegroups.com \
    --cc=stable@vger.kernel.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.