From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 19 Oct 2008 05:03:25 +0200 From: Nick Piggin Subject: Re: [patch] mm: fix anon_vma races Message-ID: <20081019030325.GE16562@wotan.suse.de> References: <20081016041033.GB10371@wotan.suse.de> <1224285222.10548.22.camel@lappy.programming.kicks-ass.net> <20081018013258.GA3595@wotan.suse.de> <20081018022541.GA19018@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org Return-Path: To: Hugh Dickins Cc: Linus Torvalds , Peter Zijlstra , Linux Memory Management List List-ID: On Sat, Oct 18, 2008 at 08:14:12PM +0100, Hugh Dickins wrote: > And Nick is right that page_lock_anon_vma() is not safe against finding > an anon_vma which has now been allocated for something else: but that > is no surprise, it's very much in the nature of SLAB_DESTROY_BY_RCU > (I left most of the comment in mm/slab.c, just said "tricky" here). > > It should be no problem: having locked the right-or-perhaps-wrong > anon_vma, we then go on to search its list for a page which may or > may not be there, even when it's the right anon_vma; there's no need OK, so it may be correct but I think that's pretty nasty if we can avoid it so easily. Then we have to keep in mind this special case throughout the code rather than just confining it to the low level take-a-reference function and never having to worry about it. > for special code to deal with the very unlikely case that we've now > got an irrelevant list, it's just that the page we're looking for > won't be found in it. There is already a page_mapped check in there. I'm just going to propose we move that down. No extra branchesin the fastpath. OK? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org