Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758331Ab0LCJMX (ORCPT ); Fri, 3 Dec 2010 04:12:23 -0500 Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:50927 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755348Ab0LCJMV (ORCPT ); Fri, 3 Dec 2010 04:12:21 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAExC+Ex5LdV4/2dsb2JhbACjNHLCLYVHBI9/ Date: Fri, 3 Dec 2010 20:12:12 +1100 From: Nick Piggin To: Linus Torvalds Cc: Andrew Morton , Trond Myklebust , Hugh Dickins , Nick Piggin , Nick Bowler , Linux Kernel Mailing List , linux-nfs@vger.kernel.org, Rik van Riel , Christoph Hellwig , Al Viro Subject: Re: [PATCH v2 3/3] NFS: Fix a memory leak in nfs_readdir Message-ID: <20101203091212.GA3346@amd> References: <20101201133831.ea6ba10a.akpm@linux-foundation.org> <1291240272.6609.50.camel@heimdal.trondhjem.org> <20101201141351.8609140b.akpm@linux-foundation.org> <20101201143856.51f4f9d9.akpm@linux-foundation.org> <20101201153608.78b331f9.akpm@linux-foundation.org> <20101201172224.b8a25bdf.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1328 Lines: 35 On Wed, Dec 01, 2010 at 05:42:08PM -0800, Linus Torvalds wrote: > On Wed, Dec 1, 2010 at 5:22 PM, Andrew Morton wrote: > > > > What we're talking about is races against memory reclaim, unmount, etc. > > Ahh. Those I can believe in. Yeah, it's a tricky question. It would be solved if the inode reclaim code didn't have the nasty shortcuts for nr_pages == 0 sitting outisde the tree_lock... any time we have these kinds of optimisations checking things outside locks, we invaraibly find they have races or data races :( So doing those checks under lock would be a reasonable way to fix it if anyone cares for 2.6.37 or earlier (eg. distros). But it is another lock in inode freeing path which is nice to avoid, so let's just get it fixed with RCU in 2.6.38. > Although I think they'd almost > incidentally be fixed by making inode freeing (which is where the > 'struct address_space' is embedded) RCU-safe, which we're going to do > anyway in 38. Then we could make the vmscan code just be a rcu-read > section. Yep, good observation. Thanks, Nick -- 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/