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
| ||
|
Date: Thu, 9 Dec 2010 22:39:29 -0800 From: Michel Lespinasse <walken@...gle.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, Hugh Dickins <hughd@...gle.com>, Rik van Riel <riel@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Nick Piggin <npiggin@...nel.dk>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/6] mlock: only hold mmap_sem in shared mode when faulting in pages On Thu, Dec 9, 2010 at 10:11 PM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Wednesday, December 8, 2010, Michel Lespinasse <walken@...gle.com> wrote: >> Yes, patch 1/6 changes the long hold time to be in read mode instead >> of write mode, which is only a band-aid. But, this prepares for patch >> 5/6, which releases mmap_sem whenever there is contention on it or >> when blocking on disk reads. > > I have to say that I'm not a huge fan of that horribly kludgy > contention check case. > > The "move page-in to read-locked sequence" and the changes to > get_user_pages look fine, but the contention thing is just disgusting. > I'd really like to see some other approach if at all possible. Are you OK with the part of patch 5/6 that drops mmap_sem when blocking on disk ? This by itself brings mmap_sem hold time down to a few seconds. Plus, I could add something to limit the interval passed to __mlock_vma_pages_range to a thousand pages or so, so that the hold time would then be bounded by that constant. I think rwsem_is_contended() actually sounds better than fiddling with constants, but OTOH maybe the mlock use case is not significant enough to justify introducing that new API. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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/
Powered by blists - more mailing lists