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

From: Linus Torvalds
Date: Fri Apr 09 2010 - 15:37:11 EST




On Fri, 9 Apr 2010, Borislav Petkov wrote:
> >
> > So what I _think_ will happen is that you'll be able to re-create the
> > problem that started this all. But I'd like to verify that, just because
> > I'm anal and I'd like these things to be tested independently.
>
> Heh, that was easy. Third hibernate cycle is a charm^Wboom :)

Ok, good to know that I'm still tracking ok on the issue.

> > So assuming that the original problem happens again, if you can then apply
> > Rik's patch, but add a
> >
> > dst->anon_vma = src->anon_vma;
> >
> > to just before the success case (the "return 0") in anon_vma_clone(),
> > that would be good.
>
> It looks like this way we mangle the anon_vma chains somehow. From
> what I can see and if I'm not mistaken, we save the anon_vmas alright
> but end up in what seems like an endless list_for_each_entry()
> loop having grabbed anon_vma->lock in page_lock_anon_vma() and we
> can't seem to yield it through page_unlock_anon_vma() at the end of
> page_referenced_anon() so it has to be that code in between iterating
> over each list entry...

Ok. So scratch Rik's patch. It doesn't work even with the anon_vma set up.

Rik? I think it's back to you. I'm not going to bother committing the
change to the anon_vma locking unless you actually need the locking
guarantees for anon_vma_prepare().

And I've got the feeling that the proper fix is in the vma_adjust()
handling if your original idea was right.

Anybody?

We're at the point where I've already delayed -rc4 several days because
it's pointless cutting it without fixing this. One option is to just say
"f*ck it, we'll revert it all and try again later". But it feels so
close..

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/