From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: mhocko@kernel.org, rientjes@google.com
Cc: akpm@linux-foundation.org, aarcange@redhat.com, guro@fb.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap
Date: Wed, 18 Apr 2018 20:49:11 +0900 [thread overview]
Message-ID: <201804182049.EDJ21857.OHJOMOLFQVFFtS@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <20180418075051.GO17484@dhcp22.suse.cz>
Michal Hocko wrote:
> On Tue 17-04-18 19:52:41, David Rientjes wrote:
> > Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> > possible for the oom reaper to concurrently operate on an mm until
> > MMF_OOM_SKIP is set.
> >
> > This allows munlock_vma_pages_all() to concurrently run while the oom
> > reaper is operating on a vma. Since munlock_vma_pages_range() depends on
> > clearing VM_LOCKED from vm_flags before actually doing the munlock to
> > determine if any other vmas are locking the same memory, the check for
> > VM_LOCKED in the oom reaper is racy.
> >
> > This is especially noticeable on architectures such as powerpc where
> > clearing a huge pmd requires serialize_against_pte_lookup(). If the pmd
> > is zapped by the oom reaper during follow_page_mask() after the check for
> > pmd_none() is bypassed, this ends up deferencing a NULL ptl.
> >
> > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > reaped. This prevents the concurrent munlock_vma_pages_range() and
> > unmap_page_range(). The oom reaper will simply not operate on an mm that
> > has the bit set and leave the unmapping to exit_mmap().
>
> This will further complicate the protocol and actually theoretically
> restores the oom lockup issues because the oom reaper doesn't set
> MMF_OOM_SKIP when racing with exit_mmap so we fully rely that nothing
> blocks there... So the resulting code is more fragile and tricky.
>
> Can we try a simpler way and get back to what I was suggesting before
> [1] and simply not play tricks with
> down_write(&mm->mmap_sem);
> up_write(&mm->mmap_sem);
>
> and use the write lock in exit_mmap for oom_victims?
You mean something like this?
Then, I'm tempted to call __oom_reap_task_mm() before holding mmap_sem for write.
It would be OK to call __oom_reap_task_mm() at the beginning of __mmput()...
diff --git a/mm/mmap.c b/mm/mmap.c
index 188f195..ba7083b 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3011,17 +3011,22 @@ void exit_mmap(struct mm_struct *mm)
struct mmu_gather tlb;
struct vm_area_struct *vma;
unsigned long nr_accounted = 0;
+ const bool is_oom_mm = mm_is_oom_victim(mm);
/* mm's last user has gone, and its about to be pulled down */
mmu_notifier_release(mm);
if (mm->locked_vm) {
+ if (is_oom_mm)
+ down_write(&mm->mmap_sem);
vma = mm->mmap;
while (vma) {
if (vma->vm_flags & VM_LOCKED)
munlock_vma_pages_all(vma);
vma = vma->vm_next;
}
+ if (is_oom_mm)
+ up_write(&mm->mmap_sem);
}
arch_exit_mmap(mm);
@@ -3037,7 +3042,7 @@ void exit_mmap(struct mm_struct *mm)
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(&tlb, vma, 0, -1);
- if (unlikely(mm_is_oom_victim(mm))) {
+ if (unlikely(is_oom_mm)) {
/*
* Wait for oom_reap_task() to stop working on this
* mm. Because MMF_OOM_SKIP is already set before
next prev parent reply other threads:[~2018-04-18 11:49 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 22:46 [patch] " David Rientjes
2018-04-18 0:57 ` Tetsuo Handa
2018-04-18 2:39 ` David Rientjes
2018-04-18 2:52 ` [patch v2] " David Rientjes
2018-04-18 3:55 ` Tetsuo Handa
2018-04-18 4:11 ` David Rientjes
2018-04-18 4:47 ` Tetsuo Handa
2018-04-18 5:20 ` David Rientjes
2018-04-18 7:50 ` Michal Hocko
2018-04-18 11:49 ` Tetsuo Handa [this message]
2018-04-18 11:58 ` Michal Hocko
2018-04-18 13:25 ` Tetsuo Handa
2018-04-18 13:44 ` Michal Hocko
2018-04-18 14:28 ` Tetsuo Handa
2018-04-18 19:14 ` David Rientjes
2018-04-19 6:35 ` Michal Hocko
2018-04-19 10:45 ` Tetsuo Handa
2018-04-19 11:04 ` Michal Hocko
2018-04-19 11:51 ` Tetsuo Handa
2018-04-19 12:48 ` Michal Hocko
2018-04-19 19:14 ` David Rientjes
2018-04-19 19:34 ` David Rientjes
2018-04-19 22:13 ` Tetsuo Handa
2018-04-20 8:23 ` Michal Hocko
2018-04-20 12:40 ` Michal Hocko
2018-04-22 3:22 ` David Rientjes
2018-04-22 3:48 ` [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap Tetsuo Handa
2018-04-22 13:08 ` Michal Hocko
2018-04-24 2:31 ` David Rientjes
2018-04-24 5:11 ` Tetsuo Handa
2018-04-24 5:35 ` David Rientjes
2018-04-24 21:57 ` [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap Tetsuo Handa
2018-04-24 22:25 ` David Rientjes
2018-04-24 22:34 ` [patch v3 for-4.17] " David Rientjes
2018-04-24 23:19 ` Michal Hocko
2018-04-24 13:04 ` [patch v2] mm, oom: fix concurrent munlock and oom reaperunmap Michal Hocko
2018-04-24 20:01 ` David Rientjes
2018-04-24 20:13 ` Michal Hocko
2018-04-24 20:22 ` David Rientjes
2018-04-24 20:31 ` Michal Hocko
2018-04-24 21:07 ` David Rientjes
2018-04-24 23:08 ` Michal Hocko
2018-04-24 23:14 ` Michal Hocko
2018-04-22 3:45 ` [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap David Rientjes
2018-04-22 13:18 ` Michal Hocko
2018-04-23 16:09 ` 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=201804182049.EDJ21857.OHJOMOLFQVFFtS@I-love.SAKURA.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=rientjes@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox