Re: [patch] mm: fix anon_vma races

Nick Piggin
2008-10-18T01:32:58Z

On Fri, Oct 17, 2008 at 06:08:05PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 17 Oct 2008, Linus Torvalds wrote:
> >
> > So maybe a better patch would be as follows? It simplifies the whole thing
> > by just always locking and unlocking the vma, whether it's newly allocated
> > or not (and whether it then gets dropped as unnecessary or not).
>
> Side note: it would be nicer if we had a "spin_lock_init_locked()", so
> that we could avoid the more expensive "true lock" when doing the initial
> allocation, but we don't. That said, the case of having to allocate a new
> anon_vma _should_ be the rare one.

We can't do that, unfortuantely, because anon_vmas are allocated with
SLAB_DESTROY_BY_RCU. Obviously that's the easier way to solve most of
the orderings (then you just need to order store to spinlock with store
to make anon_vma visible). But no, we can't do that.

But there seem like there might be other problems here too... Hmm.