From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with SMTP id 8212C6B01F0 for ; Fri, 27 Aug 2010 19:06:11 -0400 (EDT) Date: Fri, 27 Aug 2010 18:06:07 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH] mm: fix hang on anon_vma->root->lock In-Reply-To: Message-ID: References: <20100826235052.GZ6803@random.random> <20100827095546.GC6803@random.random> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Hugh Dickins Cc: Andrea Arcangeli , Linus Torvalds , Andrew Morton , Rik van Riel , Peter Zijlstra , linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Fri, 27 Aug 2010, Hugh Dickins wrote: > >> I do not see a second check (*after* taking the lock) in the patch > > if (page_mapped(page)) > return anon_vma; As far as I can tell you would have to recheck the mapping pointer and the pointer to the root too after taking the lock because only taking the lock stabilitzes the object. Any other data you may have obtained before acquiring the lock may have changed. > >> and the way the lock is taken can be a problem in itself. > > No, that's what we rely upon SLAB_DESTROY_BY_RCU for. SLAB_DESTROY_BY_RCU does not guarantee that the object stays the same nor does it prevent any fields from changing. Going through a pointer with only SLAB_DESTROY_BY_RCU means that you can only rely on the atomicity guarantee for pointer updates. You get a valid pointer but pointer changes are not prevented by SLAB_DESTROY_BY_RCU. The only guarantee of that would be through other synchronization techniques. If you believe that the page lock provides sufficient synchronization that then this approach may be 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