[PATCH] mm: memcontrol: fix potential oom_lock recursion deadlock

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

syzbot is reporting fs_reclaim allocation with oom_lock held [1]. We
must make sure that such allocation won't hit __alloc_pages_may_oom()
path which will retry forever if oom_lock is already held.

I choose GFP_ATOMIC than GFP_NOWAIT, for since global OOM situation will
likely be avoided by killing some process in memcg, and memory will be
released after printk(), trying a little hard will be acceptable.

Link: https://syzkaller.appspot.com/bug?extid=2d2aeadc6ce1e1f11d45 [1]
Reported-by: syzbot <syzbot+2d2aeadc6ce1e1f11d45@syzkaller.appspotmail.com>
Fixes: c8713d0b23123759 ("mm: memcontrol: dump memory.stat during cgroup OOM")
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
 mm/memcontrol.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 618c366a2f07..11cd900729b9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1465,7 +1465,8 @@ static char *memory_stat_format(struct mem_cgroup *memcg)
 	struct seq_buf s;
 	int i;
 
-	seq_buf_init(&s, kmalloc(PAGE_SIZE, GFP_KERNEL), PAGE_SIZE);
+	/* Caller might be holding oom_lock. */
+	seq_buf_init(&s, kmalloc(PAGE_SIZE, GFP_ATOMIC), PAGE_SIZE);
 	if (!s.buffer)
 		return NULL;
 
-- 
2.18.4