Re: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmasof a mergeable VMA

From: Linus Torvalds
Date: Wed Apr 07 2010 - 11:36:09 EST

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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at