[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0805071803240.3024@woody.linux-foundation.org>
Date: Wed, 7 May 2008 18:07:27 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christoph Lameter <clameter@....com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Andrea Arcangeli <andrea@...ranet.com>, steiner@....com,
holt@....com, npiggin@...e.de, a.p.zijlstra@...llo.nl,
kvm-devel@...ts.sourceforge.net, kanojsarcar@...oo.com,
rdreier@...co.com, swise@...ngridcomputing.com,
linux-kernel@...r.kernel.org, avi@...ranet.com, linux-mm@...ck.org,
general@...ts.openfabrics.org, hugh@...itas.com,
rusty@...tcorp.com.au, aliguori@...ibm.com, chrisw@...hat.com,
marcelo@...ck.org, dada1@...mosbay.com, paulmck@...ibm.com
Subject: Re: [PATCH 08 of 11] anon-vma-rwsem
On Wed, 7 May 2008, Christoph Lameter wrote:
>
> Set the vma flag when we locked it and then skip when we find it locked
> right? This would be in addition to the global lock?
Yes. And clear it before unlocking (and again, testing if it's already
clear - you mustn't unlock twice, so you must only unlock when the bit
was set).
You also (obviously) need to have somethign that guarantees that the lists
themselves are stable over the whole sequence, but I assume you already
have mmap_sem for reading (since you'd need it anyway just to follow the
list).
And if you have it for writing, it can obviously *act* as the global lock,
since it would already guarantee mutual exclusion on that mm->mmap list.
Linus
--
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