linux-kernel - Re: [PATCH] mm: make munlock fast when mlock is canceled by sigkill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090826113622.9A29.A69D9226@jp.fujitsu.com>
Date:	Wed, 26 Aug 2009 11:32:43 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Hugh Dickins <hugh.dickins@...cali.co.uk>
Cc:	kosaki.motohiro@...fujitsu.com,
	Hiroaki Wakabayashi <primulaelatior@...il.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	Paul Menage <menage@...gle.com>, Ying Han <yinghan@...gle.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Lee Schermerhorn <lee.schermerhorn@...com>
Subject: Re: [PATCH] mm: make munlock fast when mlock is canceled by sigkill

> > > Yeah, GUP_FLAGS_NOFAULT is better.
> > 
> > Me too.
> > I will change this flag name.
> >... 
> > When I try to change __get_user_pages(), I got problem.
> > If remove NULLs from pages,
> > __mlock_vma_pages_range() cannot know how long __get_user_pages() readed.
> > So, I have to get the virtual address of the page from vma and page.
> > Because __mlock_vma_pages_range() have to call
> > __get_user_pages() many times with different `start' argument.
> > 
> > I try to use page_address_in_vma(), but it failed.
> > (page_address_in_vma() returned -EFAULT)
> > I cannot find way to solve this problem.
> > Are there good ideas?
> > Please give me some ideas.
> 
> I agree that this munlock issue needs to be addressed: it's not just a
> matter of speedup, I hit it when testing what happens when mlock takes
> you to OOM - which is currently a hanging disaster because munlock'ing
> in the exiting OOM-killed process gets stuck trying to fault in all
> those pages that couldn't be locked in the first place.

I agree too.


> I had intended to fix it by being more careful about splitting/merging
> vmas, noting how far the mlock had got, and munlocking just up to there.
> However, now that I've got in there, that looks wrong to me, given the
> traditional behaviour that mlock does its best, but pretends success
> to allow for later instantiation of the pages if necessary.
> 
> You ask for ideas.  My main idea is that so far we have added
> GUP_FLAGS_IGNORE_VMA_PERMISSIONS (Kosaki-san, what was that about?
>                                   we already had the force flag),

MAY_WRITE and MAY_READ might be turned off at some special case.
but munlock should turn off PG_mlock bit. otherwise the page never be reclaimed.
This problem was explained by Lee about a year ago.

However, To use follow_page() solove this issue and we will be able to
remove this ugly flag.

> GUP_FLAGS_IGNORE_SIGKILL, and now you propose
> GUP_FLAGS_NOFAULT, all for the sole use of munlock.
> 
> How about GUP_FLAGS_MUNLOCK, or more to the point, GUP_FLAGS_DONT_BE_GUP?
> By which I mean, don't all these added flags suggest that almost
> everything __get_user_pages() does is unsuited to the munlock case?
> 
> My advice (but I sure hate giving advice before I've tried it myself)
> is to put __mlock_vma_pages_range() back to handling just the mlock
> case, and do your own follow_page() loop in munlock_vma_pages_range().

Agreed. follow_page() is better.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/