linux-kernel - Re: [PATCH 3/3] mlock: avoid dirtying pages and triggering writeback

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Nov 2010 16:46:29 +1100
From:	Nick Piggin <npiggin@...nel.dk>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Nick Piggin <npiggin@...nel.dk>,
	Michel Lespinasse <walken@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickins <hughd@...gle.com>,
	Rik van Riel <riel@...hat.com>,
	Kosaki Motohiro <kosaki.motohiro@...fujitsu.com>,
	Theodore Tso <tytso@...gle.com>,
	Michael Rubin <mrubin@...gle.com>,
	Suleiman Souhlal <suleiman@...gle.com>
Subject: Re: [PATCH 3/3] mlock: avoid dirtying pages and triggering
 writeback

On Wed, Nov 17, 2010 at 04:28:54PM +0100, Peter Zijlstra wrote:
> On Wed, 2010-11-17 at 23:57 +1100, Nick Piggin wrote:
> > On Wed, Nov 17, 2010 at 04:23:58AM -0800, Michel Lespinasse wrote:
> > > When faulting in pages for mlock(), we want to break COW for anonymous
> > > or file pages within VM_WRITABLE, non-VM_SHARED vmas. However, there is
> > > no need to write-fault into VM_SHARED vmas since shared file pages can
> > > be mlocked first and dirtied later, when/if they actually get written to.
> > > Skipping the write fault is desirable, as we don't want to unnecessarily
> > > cause these pages to be dirtied and queued for writeback.
> > 
> > It's not just to break COW, but to do block allocation and such
> > (filesystem's page_mkwrite op). That needs to at least be explained
> > in the changelog.
> 
> Agreed, the 0/3 description actually does mention this.

Oh, missed that, but yes the changelog needs to.

 
> > Filesystem doesn't have a good way to fully pin required things
> > according to mlock, but page_mkwrite provides some reasonable things
> > (like block allocation / reservation).
> 
> Right, but marking all pages dirty isn't really sane. I can imagine
> making the reservation but not marking things dirty solution, although
> it might be lots harder to implement, esp since some filesystems don't
> actually have a page_mkwrite() implementation.

I think it is sane enough. Going back to previous behaviour would be
a regression, wouldn't it?

The right way to fix this would not be to introduce the new regression
but either/both: a specific syscall to mlock-for-read which does not do
any reservations, fix filesystem hook to allow reservation without
implying dirtying. A simple flag to page_mkwrite will be enough (plus
the logic to call it from VM).

If an app has called mlock, presumably it doesn't want to SIGBUS from
out of space, if it can possibly help it. If it isn't going to write
to it, then PROT_READ would be appropriate.

If not, then a note to man page maintainer, and an idea of performance
improvement in an actual use case would be nice.

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