linux-kernel - Re: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1004091657090.3558@i5.linux-foundation.org>
Date:	Fri, 9 Apr 2010 17:03:55 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Rik van Riel <riel@...hat.com>
cc:	Johannes Weiner <hannes@...xchg.org>,
	Borislav Petkov <bp@...en8.de>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Minchan Kim <minchan.kim@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Nick Piggin <npiggin@...e.de>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	sgunderson@...foot.com
Subject: Re: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmas
 of a mergeable VMA

On Fri, 9 Apr 2010, Rik van Riel wrote:
> 
> The trick is in the fact that anon_vma_merge is only called
> when vma->anon_vma == vma1->anon_vma.

Sure sure. I still think it's _way_ too complex. See my previous email 
where I suggested one single simple additional rule that I think makes 
things _much_ simpler.

> If the top anon_vmas are different, then anon_vma_merge will
> not be called.

Right. The case of different anon_vma's is the trivial one. I don't worry 
about that.

> That leaves just the split & create cases, which will be
> passed to anon_vma_merge when they are merged.
> 
> In case of split, they will have identical anon_vma chains.

And yes, split is fundamentally simple. Split guarantees that the chains 
look identical.

But:

> In case of create + merge, one of the two VMAs will have
> the whole anon_vma chain, while the other one has just
> the top anon_vma.

THIS is where I think you simplified a lot and said "and magic happens".

The thing is, in the case of create, we create a different chain. That 
simple fact just makes merging fundamentally complicated.  And we now have 
two different chains, and both of those can split, so those differences 
can "spread out". And you need to guarantee that "merge" really works. It 
didn't work in your original code, and quite frankly, I do _not_ think 
it's entirely obvious that it works in Johannes' code either.

Don't get me wrong: _maybe_ Johannes' code works fine. I just don't think 
it's obvious at all. And if it doesn't work fine, now you're just 
spreading the differences even further.

This is why I suggest that we limit the "re-use an existing vma for a new 
case" to the singleton case, which means that now you _never_ have 
differences at all. There's no spreading on splitting. Merging is trivial. 

Now, admittedly, I'm really hopped up on cough medication, so the feeling 
of this solving all the problems in the universe may not be entirely 
accurate. But it feels so _right_.

I hope if feels right when I'm off my meds too.

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