[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxeNisBgvE9EePR9OGm_BkO7RvxbqCws04v7QTJ=bGMnw@mail.gmail.com>
Date: Fri, 1 Nov 2013 10:47:34 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yuanhan Liu <yuanhan.liu@...ux.intel.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Rik van Riel <riel@...hat.com>,
Michel Lespinasse <walken@...gle.com>
Subject: Re: [PATCH 1/4] mm/rmap: per anon_vma lock
On Fri, Nov 1, 2013 at 7:09 AM, Yuanhan Liu <yuanhan.liu@...ux.intel.com> wrote:
>
> Sorry, I may be wrong again this time. But, isn't vma->anon_vma_chain
> list being protect by mmap_sem & page_table_lock?
No.
The mmap_sem (and the page_table_lock) only protects a single VM instance.
The anon_vma chains, in contrast, can span multiple VM instances,
since it grows over fork().
Now, you're right that we used to not always lock the root every time,
but the code has changed since. We used to lock each anon_vma as we
copied them, now we lock the root only once (see anon_vma_clone()).
And that works exactly because they all share the same root anon_vma
on the chain. You can't change that to just randomly lock one non-root
vma.
So I'll add my voice to the chorus that says "that's wrong", when you
changed "anon_vma->root->lock" to "anon_vma->lock".
We *may* be able to do finer-grained anon_vma locking again, but it's
definitely not some mindless "let's just change it back" thing. It
needs real code changes (and I bet it's not just anon_vma_clone()),
and it needs a lot of care.
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