linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Michal Hocko <mhocko@suse.cz>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>,
	linux-mm@kvack.org
Subject: Re: [PATCH 1/2] mm, oom: skip mlocked VMAs in __oom_reap_vmas()
Date: Tue, 5 Jan 2016 15:10:39 +0200	[thread overview]
Message-ID: <20160105131039.GA19907@node.shutemov.name> (raw)
In-Reply-To: <20160105124735.GA15324@dhcp22.suse.cz>

On Tue, Jan 05, 2016 at 01:47:35PM +0100, Michal Hocko wrote:
> On Tue 29-12-15 23:46:29, Kirill A. Shutemov wrote:
> > As far as I can see we explicitly munlock pages everywhere before unmap
> > them. The only case when we don't to that is OOM-reaper.
> 
> Very well spotted!
> 
> > I don't think we should bother with munlocking in this case, we can just
> > skip the locked VMA.
> 
> Why cannot we simply munlock them here for the private mappings?

It's probably right think to do, but I wanted to fix the bug first.
And I wasn't ready to investigate context the reaper working in to check
if it's safe to munlock there. For instance, munlock would take page lock
and I'm not sure at the moment if it can or cannot lead to deadlock in
some scenario. So I choose safer fix.

If calling munlock is always safe where unmap happens, why not move inside
unmap?

> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 4b0a5d8b92e1..25dd7cd6fb5e 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -456,9 +456,12 @@ static bool __oom_reap_vmas(struct mm_struct *mm)
>  		 * we do not want to block exit_mmap by keeping mm ref
>  		 * count elevated without a good reason.
>  		 */
> -		if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED))
> +		if (vma_is_anonymous(vma) || !(vma->vm_flags & VM_SHARED)) {
> +			if (vma->vm_flags & VM_LOCKED)
> +				munlock_vma_pages_all(vma);
>  			unmap_page_range(&tlb, vma, vma->vm_start, vma->vm_end,
>  					 &details);
> +		}
>  	}
>  	tlb_finish_mmu(&tlb, 0, -1);
>  	up_read(&mm->mmap_sem);
-- 
 Kirill A. Shutemov

--
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>

  reply	other threads:[~2016-01-05 13:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-29 20:46 [PATCH 0/2] THP mlock fix Kirill A. Shutemov
2015-12-29 20:46 ` [PATCH 1/2] mm, oom: skip mlocked VMAs in __oom_reap_vmas() Kirill A. Shutemov
2016-01-05 12:47   ` Michal Hocko
2016-01-05 13:10     ` Kirill A. Shutemov [this message]
2016-01-05 13:31       ` Michal Hocko
2016-01-05 15:03         ` Kirill A. Shutemov
2016-01-05 15:45           ` Michal Hocko
2016-01-05 13:33   ` Michal Hocko
2016-01-05 15:03     ` Kirill A. Shutemov
2016-01-05 15:44       ` Sasha Levin
2015-12-29 20:46 ` [PATCH 2/2] mm, thp: clear PG_mlocked when last mapping gone Kirill A. Shutemov
2016-01-05  9:37   ` Vlastimil Babka
2016-01-05 14:37     ` Kirill A. Shutemov
2015-12-29 20:52 ` [PATCH 0/2] THP mlock fix Sasha Levin

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=20160105131039.GA19907@node.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=sasha.levin@oracle.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;
as well as URLs for NNTP newsgroup(s).