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  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:	Wed, 17 Nov 2010 18:52:30 -0500
From:	Ted Ts'o <>
To:	Dave Chinner <>
Cc:	Michel Lespinasse <>,
	Peter Zijlstra <>,
	Nick Piggin <>,,,
	Andrew Morton <>,
	Hugh Dickins <>,
	Rik van Riel <>,
	Kosaki Motohiro <>,
	Theodore Tso <>,
	Michael Rubin <>,
	Suleiman Souhlal <>
Subject: Re: [PATCH 3/3] mlock: avoid dirtying pages and triggering

On Thu, Nov 18, 2010 at 10:11:43AM +1100, Dave Chinner wrote:
> I don't think ->page_mkwrite can be worked around - we need that to
> be called on the first write fault of any mmap()d page to ensure it
> is set up correctly for writeback.  If we don't get write faults
> after the page is mlock()d, then we need the ->page_mkwrite() call
> during the mlock() call.

OK, so I'm not an mm hacker, so maybe I'm missing something.  Could
part of this be fixed by simply sending the write faults for
mlock()'ed pages, so page_mkwrite() gets called when the page is
dirtied.  Seems like a real waste to have the file system pre-allocate
all of the blocks for a mlock()'ed region.  Why does mlock() have to
result in the write faults getting suppressed when the page is
actually dirtied?

						- Ted
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists