FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

[gregkh]

The patch below does not apply to the 4.1-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

>From ecf5fc6e9654cd7a268c782a523f072b2f1959f9 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.cz>
Date: Tue, 4 Aug 2015 14:36:58 -0700
Subject: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS
 allocations

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384e9da8 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f44fcb0 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Cc: stable@vger.kernel.org # 3.9+
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/mm/vmscan.c b/mm/vmscan.c
index e61445dce04e..8286938c70de 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -973,22 +973,18 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 		 *    caller can stall after page list has been processed.
 		 *
 		 * 2) Global or new memcg reclaim encounters a page that is
-		 *    not marked for immediate reclaim or the caller does not
-		 *    have __GFP_IO. In this case mark the page for immediate
+		 *    not marked for immediate reclaim, or the caller does not
+		 *    have __GFP_FS (or __GFP_IO if it's simply going to swap,
+		 *    not to fs). In this case mark the page for immediate
 		 *    reclaim and continue scanning.
 		 *
-		 *    __GFP_IO is checked  because a loop driver thread might
+		 *    Require may_enter_fs because we would wait on fs, which
+		 *    may not have submitted IO yet. And the loop driver might
 		 *    enter reclaim, and deadlock if it waits on a page for
 		 *    which it is needed to do the write (loop masks off
 		 *    __GFP_IO|__GFP_FS for this reason); but more thought
 		 *    would probably show more reasons.
 		 *
-		 *    Don't require __GFP_FS, since we're not going into the
-		 *    FS, just waiting on its writeback completion. Worryingly,
-		 *    ext4 gfs2 and xfs allocate pages with
-		 *    grab_cache_page_write_begin(,,AOP_FLAG_NOFS), so testing
-		 *    may_enter_fs here is liable to OOM on them.
-		 *
 		 * 3) Legacy memcg encounters a page that is not already marked
 		 *    PageReclaim. memcg does not have any dirty pages
 		 *    throttling so we could easily OOM just because too many
@@ -1005,7 +1001,7 @@ static unsigned long shrink_page_list(struct list_head *page_list,
 
 			/* Case 2 above */
 			} else if (sane_reclaim(sc) ||
-			    !PageReclaim(page) || !(sc->gfp_mask & __GFP_IO)) {
+			    !PageReclaim(page) || !may_enter_fs) {
 				/*
 				 * This is slightly racy - end_page_writeback()
 				 * might have just cleared PageReclaim, then

Re: FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

[Hugh Dickins]

On Thu, 13 Aug 2015, gregkh@linuxfoundation.org wrote:
> 
> The patch below does not apply to the 4.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@vger.kernel.org>.
> 
> thanks,
> 
> greg k-h
> 
------------ commit in Linus's tree adjusted to 4.1.5 -------------

>From ecf5fc6e9654cd7a268c782a523f072b2f1959f9 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.cz>
Date: Tue, 4 Aug 2015 14:36:58 -0700
Subject: [PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS
 allocations

Nikolay has reported a hang when a memcg reclaim got stuck with the
following backtrace:

PID: 18308  TASK: ffff883d7c9b0a30  CPU: 1   COMMAND: "rsync"
  #0 __schedule at ffffffff815ab152
  #1 schedule at ffffffff815ab76e
  #2 schedule_timeout at ffffffff815ae5e5
  #3 io_schedule_timeout at ffffffff815aad6a
  #4 bit_wait_io at ffffffff815abfc6
  #5 __wait_on_bit at ffffffff815abda5
  #6 wait_on_page_bit at ffffffff8111fd4f
  #7 shrink_page_list at ffffffff81135445
  #8 shrink_inactive_list at ffffffff81135845
  #9 shrink_lruvec at ffffffff81135ead
 #10 shrink_zone at ffffffff811360c3
 #11 shrink_zones at ffffffff81136eff
 #12 do_try_to_free_pages at ffffffff8113712f
 #13 try_to_free_mem_cgroup_pages at ffffffff811372be
 #14 try_charge at ffffffff81189423
 #15 mem_cgroup_try_charge at ffffffff8118c6f5
 #16 __add_to_page_cache_locked at ffffffff8112137d
 #17 add_to_page_cache_lru at ffffffff81121618
 #18 pagecache_get_page at ffffffff8112170b
 #19 grow_dev_page at ffffffff811c8297
 #20 __getblk_slow at ffffffff811c91d6
 #21 __getblk_gfp at ffffffff811c92c1
 #22 ext4_ext_grow_indepth at ffffffff8124565c
 #23 ext4_ext_create_new_leaf at ffffffff81246ca8
 #24 ext4_ext_insert_extent at ffffffff81246f09
 #25 ext4_ext_map_blocks at ffffffff8124a848
 #26 ext4_map_blocks at ffffffff8121a5b7
 #27 mpage_map_one_extent at ffffffff8121b1fa
 #28 mpage_map_and_submit_extent at ffffffff8121f07b
 #29 ext4_writepages at ffffffff8121f6d5
 #30 do_writepages at ffffffff8112c490
 #31 __filemap_fdatawrite_range at ffffffff81120199
 #32 filemap_flush at ffffffff8112041c
 #33 ext4_alloc_da_blocks at ffffffff81219da1
 #34 ext4_rename at ffffffff81229b91
 #35 ext4_rename2 at ffffffff81229e32
 #36 vfs_rename at ffffffff811a08a5
 #37 SYSC_renameat2 at ffffffff811a3ffc
 #38 sys_renameat2 at ffffffff811a408e
 #39 sys_rename at ffffffff8119e51e
 #40 system_call_fastpath at ffffffff815afa89

Dave Chinner has properly pointed out that this is a deadlock in the
reclaim code because ext4 doesn't submit pages which are marked by
PG_writeback right away.

The heuristic was introduced by commit e62e384e9da8 ("memcg: prevent OOM
with too many dirty pages") and it was applied only when may_enter_fs
was specified.  The code has been changed by c3b94f44fcb0 ("memcg:
further prevent OOM with too many dirty pages") which has removed the
__GFP_FS restriction with a reasoning that we do not get into the fs
code.  But this is not sufficient apparently because the fs doesn't
necessarily submit pages marked PG_writeback for IO right away.

ext4_bio_write_page calls io_submit_add_bh but that doesn't necessarily
submit the bio.  Instead it tries to map more pages into the bio and
mpage_map_one_extent might trigger memcg charge which might end up
waiting on a page which is marked PG_writeback but hasn't been submitted
yet so we would end up waiting for something that never finishes.

Fix this issue by replacing __GFP_IO by may_enter_fs check (for case 2)
before we go to wait on the writeback.  The page fault path, which is
the only path that triggers memcg oom killer since 3.12, shouldn't
require GFP_NOFS and so we shouldn't reintroduce the premature OOM
killer issue which was originally addressed by the heuristic.

As per David Chinner the xfs is doing similar thing since 2.6.15 already
so ext4 is not the only affected filesystem.  Moreover he notes:

: For example: IO completion might require unwritten extent conversion
: which executes filesystem transactions and GFP_NOFS allocations. The
: writeback flag on the pages can not be cleared until unwritten
: extent conversion completes. Hence memory reclaim cannot wait on
: page writeback to complete in GFP_NOFS context because it is not
: safe to do so, memcg reclaim or otherwise.

Cc: stable@vger.kernel.org # 3.9+
[tytso@mit.edu: corrected the control flow]
Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages")
Reported-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

--- 4.1.5/mm/vmscan.c	2015-04-12 15:12:50.000000000 -0700
+++ linux/mm/vmscan.c	2015-08-13 16:14:10.828057894 -0700
@@ -937,21 +937,17 @@ static unsigned long shrink_page_list(st
 		 *
 		 * 2) Global reclaim encounters a page, memcg encounters a
 		 *    page that is not marked for immediate reclaim or
-		 *    the caller does not have __GFP_IO. In this case mark
+		 *    the caller does not have __GFP_FS (or __GFP_IO if it's
+		 *    simply going to swap, not to fs). In this case mark
 		 *    the page for immediate reclaim and continue scanning.
 		 *
-		 *    __GFP_IO is checked  because a loop driver thread might
+		 *    Require may_enter_fs because we would wait on fs, which
+		 *    may not have submitted IO yet. And the loop driver might
 		 *    enter reclaim, and deadlock if it waits on a page for
 		 *    which it is needed to do the write (loop masks off
 		 *    __GFP_IO|__GFP_FS for this reason); but more thought
 		 *    would probably show more reasons.
 		 *
-		 *    Don't require __GFP_FS, since we're not going into the
-		 *    FS, just waiting on its writeback completion. Worryingly,
-		 *    ext4 gfs2 and xfs allocate pages with
-		 *    grab_cache_page_write_begin(,,AOP_FLAG_NOFS), so testing
-		 *    may_enter_fs here is liable to OOM on them.
-		 *
 		 * 3) memcg encounters a page that is not already marked
 		 *    PageReclaim. memcg does not have any dirty pages
 		 *    throttling so we could easily OOM just because too many
@@ -968,7 +964,7 @@ static unsigned long shrink_page_list(st
 
 			/* Case 2 above */
 			} else if (global_reclaim(sc) ||
-			    !PageReclaim(page) || !(sc->gfp_mask & __GFP_IO)) {
+			    !PageReclaim(page) || !may_enter_fs) {
 				/*
 				 * This is slightly racy - end_page_writeback()
 				 * might have just cleared PageReclaim, then

Re: FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

[Greg KH]

On Thu, Aug 13, 2015 at 04:24:10PM -0700, Hugh Dickins wrote:
> On Thu, 13 Aug 2015, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 4.1-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> ------------ commit in Linus's tree adjusted to 4.1.5 -------------

Thanks for this.  Should it also be backported to older kernels as well?

thanks,

greg k-h

Re: FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

[Michal Hocko]

On Thu 13-08-15 19:35:03, Greg KH wrote:
> On Thu, Aug 13, 2015 at 04:24:10PM -0700, Hugh Dickins wrote:
> > On Thu, 13 Aug 2015, gregkh@linuxfoundation.org wrote:
> > > 
> > > The patch below does not apply to the 4.1-stable tree.
> > > If someone wants it applied there, or to any other stable or longterm
> > > tree, then please email the backport, including the original git commit
> > > id to <stable@vger.kernel.org>.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > > 
> > ------------ commit in Linus's tree adjusted to 4.1.5 -------------
> 
> Thanks for this.  Should it also be backported to older kernels as well?

Yes 3.9+ would be appreciated as per Hugh's testing 
http://lkml.kernel.org/r/alpine.LSU.2.11.1508032227050.5070%40eggly.anvils
"
And more testing on the history of it, considering your stable 3.6+
designation that I wasn't satisfied with.  Getting out that USB stick
again, I find that 3.6, 3.7 and 3.8 all OOM if their __GFP_IO test
is updated to a may_enter_fs test; but something happened in 3.9
to make it and subsequent releases safe with the may_enter_fs test.
You can certainly argue that the remote chance of a deadlock is
worse than the fair chance of a spurious OOM; but if you insist
on 3.6+, then I think it would have to go back even further,
because we marked that commit for stable itself.  I suggest 3.9+.
"
-- 
Michal Hocko
SUSE Labs

Re: FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

[Greg KH]

On Fri, Aug 14, 2015 at 09:00:37AM +0200, Michal Hocko wrote:
> On Thu 13-08-15 19:35:03, Greg KH wrote:
> > On Thu, Aug 13, 2015 at 04:24:10PM -0700, Hugh Dickins wrote:
> > > On Thu, 13 Aug 2015, gregkh@linuxfoundation.org wrote:
> > > > 
> > > > The patch below does not apply to the 4.1-stable tree.
> > > > If someone wants it applied there, or to any other stable or longterm
> > > > tree, then please email the backport, including the original git commit
> > > > id to <stable@vger.kernel.org>.
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > > 
> > > ------------ commit in Linus's tree adjusted to 4.1.5 -------------
> > 
> > Thanks for this.  Should it also be backported to older kernels as well?
> 
> Yes 3.9+ would be appreciated as per Hugh's testing 
> http://lkml.kernel.org/r/alpine.LSU.2.11.1508032227050.5070%40eggly.anvils
> "
> And more testing on the history of it, considering your stable 3.6+
> designation that I wasn't satisfied with.  Getting out that USB stick
> again, I find that 3.6, 3.7 and 3.8 all OOM if their __GFP_IO test
> is updated to a may_enter_fs test; but something happened in 3.9
> to make it and subsequent releases safe with the may_enter_fs test.
> You can certainly argue that the remote chance of a deadlock is
> worse than the fair chance of a spurious OOM; but if you insist
> on 3.6+, then I think it would have to go back even further,
> because we marked that commit for stable itself.  I suggest 3.9+.
> "

Ok, I've applied this to 3.10 and 3.14-stable trees.  For 3.10, it had
to be done by hand, so if you could verify I got it right, that would be
appreciated (the whole comment block change didn't apply, but the if()
change did.)

thanks,

greg k-h

Re: FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

[Hugh Dickins]

On Fri, 14 Aug 2015, Greg KH wrote:
> On Fri, Aug 14, 2015 at 09:00:37AM +0200, Michal Hocko wrote:
> > On Thu 13-08-15 19:35:03, Greg KH wrote:
> > > On Thu, Aug 13, 2015 at 04:24:10PM -0700, Hugh Dickins wrote:
> > > > On Thu, 13 Aug 2015, gregkh@linuxfoundation.org wrote:
> > > > > 
> > > > > The patch below does not apply to the 4.1-stable tree.
> > > > > If someone wants it applied there, or to any other stable or longterm
> > > > > tree, then please email the backport, including the original git commit
> > > > > id to <stable@vger.kernel.org>.
> > > > > 
> > > > > thanks,
> > > > > 
> > > > > greg k-h
> > > > > 
> > > > ------------ commit in Linus's tree adjusted to 4.1.5 -------------
> > > 
> > > Thanks for this.  Should it also be backported to older kernels as well?
> > 
> > Yes 3.9+ would be appreciated as per Hugh's testing 
> > http://lkml.kernel.org/r/alpine.LSU.2.11.1508032227050.5070%40eggly.anvils
> > "
> > And more testing on the history of it, considering your stable 3.6+
> > designation that I wasn't satisfied with.  Getting out that USB stick
> > again, I find that 3.6, 3.7 and 3.8 all OOM if their __GFP_IO test
> > is updated to a may_enter_fs test; but something happened in 3.9
> > to make it and subsequent releases safe with the may_enter_fs test.
> > You can certainly argue that the remote chance of a deadlock is
> > worse than the fair chance of a spurious OOM; but if you insist
> > on 3.6+, then I think it would have to go back even further,
> > because we marked that commit for stable itself.  I suggest 3.9+.
> > "
> 
> Ok, I've applied this to 3.10 and 3.14-stable trees.  For 3.10, it had
> to be done by hand, so if you could verify I got it right, that would be
> appreciated (the whole comment block change didn't apply, but the if()
> change did.)

Thanks for doing these, Greg: yes, the code itself is fine, but the
3.10 comment is now out of date: I'll reply in a moment to the 3.10
one with a version of the patch that fixes the comment too.

(Not that anyone actually reads these comments: if they did, they
would find that there's a stray "not" in the Case 3 description
ever since 3.11.  But I noticed that too late to fix it up.)

Hugh

Re: FAILED: patch "[PATCH] mm, vmscan: Do not wait for page writeback for GFP_NOFS" failed to apply to 4.1-stable tree

[Luis Henriques]

On Thu, Aug 13, 2015 at 04:24:10PM -0700, Hugh Dickins wrote:
> On Thu, 13 Aug 2015, gregkh@linuxfoundation.org wrote:
> > 
> > The patch below does not apply to the 4.1-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> ------------ commit in Linus's tree adjusted to 4.1.5 -------------
>

Thanks, I'm using this for the 3.16 kernel as well.

Cheers,
--
Lu�s