Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754398Ab0DLXzA (ORCPT ); Mon, 12 Apr 2010 19:55:00 -0400 Received: from f0.cmpxchg.org ([85.214.51.133]:36771 "EHLO cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754021Ab0DLXy7 (ORCPT ); Mon, 12 Apr 2010 19:54:59 -0400 Date: Tue, 13 Apr 2010 01:54:31 +0200 From: Johannes Weiner To: Linus Torvalds Cc: Borislav Petkov , Rik van Riel , KOSAKI Motohiro , Andrew Morton , Minchan Kim , Linux Kernel Mailing List , Lee Schermerhorn , Nick Piggin , Andrea Arcangeli , Hugh Dickins , sgunderson@bigfoot.com Subject: Re: [PATCH 1/4] Simplify and comment on anon_vma re-use for anon_vma_prepare() Message-ID: <20100412235431.GA20163@cmpxchg.org> References: <20100411185508.GA4450@liondog.tnic> <20100412072056.GA2432@liondog.tnic> <4BC36916.3080005@redhat.com> <20100412190002.GA8595@a1.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2286 Lines: 49 Hi Linus, On Mon, Apr 12, 2010 at 01:22:33PM -0700, Linus Torvalds wrote: > > From: Linus Torvalds > Date: Sat, 10 Apr 2010 10:36:19 -0700 > Subject: [PATCH 1/4] Simplify and comment on anon_vma re-use for anon_vma_prepare() > > This changes the anon_vma reuse case to require that we only reuse > simple anon_vma's - ie the case when the vma only has a single anon_vma > associated with it. > > This means that a reuse of an anon_vma from an adjacent vma will always > guarantee that both vma's are associated not onyl with the same > anon_vma, they will also have the same anon_vma chain (of just a single > entry in this case). > > And since anon_vma re-use was the only case where the same anon_vma > might be associated with different chains of anon_vma's, we now have the > case that every vma that shares the same vma will always also have the ^^^ That should be anon_vma? > same chain. That makes it much easier to think about merging vma's that > share the same anon_vma's: you can always just drop the other anon_vma > chain in anon_vma_merge() since you know that they are always identical. I like to think of 'incomplete' and 'complete' versions of the same chain and that this new rule of yours simplifies things by limiting reuse to the cases where the incomplete and the complete version end up identical. I can live with your wording, though :) > This also splits up the function to validate the anon_vma re-use, and > adds a lot of commentary about the possible races. > > Signed-off-by: Linus Torvalds Acked-by: Johannes Weiner That said, I still don't like that the vma comparisons differ depending on whether we reuse an anon_vma or merge vmas. In my happy-place, the same vma comparison function is predicate for both cases, so I actually liked that aspect of the old code, but I also see that code reuse is a PITA in that file... Ah well, that can still be cleaned up later. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/