linux-kernel - Re: [RFC][PATCH] lru_add_drain_all() don't use schedule_on_each

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: <1225229366.6343.74.camel@lts-notebook>
Date:	Tue, 28 Oct 2008 17:29:26 -0400
From:	Lee Schermerhorn <Lee.Schermerhorn@...com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Christoph Lameter <cl@...ux-foundation.org>,
	kosaki.motohiro@...fujitsu.com, heiko.carstens@...ibm.com,
	npiggin@...e.de, linux-kernel@...r.kernel.org, hugh@...itas.com,
	torvalds@...ux-foundation.org, riel@...hat.com, linux-mm@...ck.org
Subject: Re: [RFC][PATCH] lru_add_drain_all() don't use
	schedule_on_each_cpu()

On Tue, 2008-10-28 at 13:45 -0700, Andrew Morton wrote:
> On Tue, 28 Oct 2008 09:25:31 -0500 (CDT)
> Christoph Lameter <cl@...ux-foundation.org> wrote:
> 
> > On Mon, 27 Oct 2008, Andrew Morton wrote:
> > 
> > > Can we fix that instead?
> > 
> > How about this fix?
> > 
> > 
> > 
> > Subject: Move migrate_prep out from under mmap_sem
> > 
> > Move the migrate_prep outside the mmap_sem for the following system calls
> > 
> > 1. sys_move_pages
> > 2. sys_migrate_pages
> > 3. sys_mbind()
> > 
> > It really does not matter when we flush the lru. The system is free to add
> > pages onto the lru even during migration which will make the page 
> > migration either skip the page (mbind, migrate_pages) or return a busy 
> > state (move_pages).
> > 
> 
> That looks nicer, thanks.  Hopefully it fixes the
> lockdep-warning/deadlock...

I believe that we still  have the lru_drain_all() called from the fault
path [with mmap_sem held] in clear_page_mlock().  We call
clear_page_mlock() on COW of an mlocked page in a VM_LOCKED vma to
ensure that we don't end up with an mlocked page in some other task's
non-VM_LOCKED vma where we'd then fail to munlock it later.  During
development testing, Rik encountered scenarios where a page would
encounter a COW fault while it was still making its way to the LRU via
the pagevecs.  So, he added the 'drain_all() and that seemed to avoid
this scenario.

Now, in the current upstream version of the unevictable mlocked pages
patches, we just count any mlocked pages [vmstat] that make their way to
free*page() instead of BUGging out, as we were doing earlier during
development.  So, maybe we can drop the lru_drain_add()s in the
unevictable mlocked pages work and live with the occasional freed
mlocked page, or mlocked page on the active/inactive lists to be dealt
with by vmscan.

Comments?

Lee

> 
> I guess we should document our newly discovered schedule_on_each_cpu()
> problems before we forget about it and later rediscover it.

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