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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 9 Apr 2010 16:22:19 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Johannes Weiner <hannes@...xchg.org>
cc:	Borislav Petkov <bp@...en8.de>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.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, Johannes Weiner wrote:
> +	/*
> +	 * 1. case: vma and next are split parts of one root vma.
> +	 * Their anon_vma_chain is equal and we can drop that of next.
> +	 *
> +	 * 2. case: one vma was instantiated as mergeable with the
> +	 * other one and inherited the other one's primary anon_vma as
> +	 * the singleton in its chain.
> +	 *
> +	 * If next came after vma, vma's chain is already an unstrict
> +	 * superset of next's and we can treat it like case 1.
> +	 *
> +	 * If vma has the singleton chain, we have to copy next's
> +	 * unique anon_vmas over.
> +	 */

This comment makes my head hurt. In fact, the whole anon_vma thing hurts 
my head.

Can we have some better high-level documentation on what happens for all 
the cases.

 - split (mprotect, or munmap in the middle):

	anon_vma_clone: the two vma's will have the same anon_vma, and the 
	anon_vma chains will be equivalent. 

 - merge (mprotect that creates a mergeable state):

	anon_vma_merge: we're supposed to have a anon_vma_chain that is 
	a superset of the two chains of the merged entries.

 - fork:

	anon_vma_fork: each new vma will have a _new_ anon_vma as it's 
	primary one, and will link to the old primary trough the 
	anon_vma_chain. It's doing this with a anon_vma_clone() followed 
	by adding an entra entry to the new anon_vma, and setting 
	vma->anon_vma to the new one.

 - create/mmap:

	anon_vma_prepare: find a mergeable anon_vma and use that as a 
	singleton, because the other entries on the anon_vma chain won't 
	matter, since they cannot be associated with any pages associated 
	with the newly created vma..

Correct?

Quite frankly, just looking at that, I can't see how we get to your rules. 
At least not trivially. Especially with multiple merges, I don't see 
how "singleton" is such a special case.

		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/