lkml.org 
[lkml]   [2010]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateWed, 7 Apr 2010 08:30:52 -0700 (PDT)
FromLinus Torvalds <>
SubjectRe: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmas of a mergeable VMA


On Wed, 7 Apr 2010, Rik van Riel wrote:
>
> - fix the locking issues spotted by Kosaki Motohiro

No, they're broken.

And Rik, please explain the locking rather than make even more of these
kinds of random ad-hoc locking rules.

I've said this now _three_ times, but let me repeat once more:

- the locking rules for that anon_vma_chain are very unclear. I _think_
you mean for them to be "mmap_sem held for writing, _or_ mmap_sem held
for reading and page_table_lock held", but nowhere is that actually
documented.

Why is it so hard for you to just admit that? Especially after you
yourself got it wrong.

> + merge_vma = find_mergeable_anon_vma(vma);
> + if (merge_vma) {
> + int ret;
> + spin_lock(&mm->page_table_lock);
> + ret = anon_vma_clone(vma, merge_vma);
> + if (!ret)
> + vma->anon_vma = merge_vma->anon_vma;
> + spin_unlock(&mm->page_table_lock);
> + return ret;
> + }

Rik, the above is obviously total crap.

anon_vma_clone() needs to allocate memory, and it does so with GFP_KERNEL.
You can't do that with a spinlock held.

Linus


\
 
 \ /
  Last update: 2010-04-07 17:39    [from the cache]
©2003-2010