Messages in this thread |  | | | Date | Wed, 7 Apr 2010 08:30:52 -0700 (PDT) | | From | Linus Torvalds <> | | Subject | Re: [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
|  |