From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [patch 01/10] fs: fix do_lookup false negative Date: Wed, 18 Aug 2010 15:41:02 +0200 Message-ID: <87mxskkpht.fsf@basil.nowhere.org> References: <20100817183729.613117146@kernel.dk> <20100817184120.128470975@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Al Viro , linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: Received: from one.firstfloor.org ([213.235.205.2]:40935 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753221Ab0HRNlI (ORCPT ); Wed, 18 Aug 2010 09:41:08 -0400 In-Reply-To: <20100817184120.128470975@kernel.dk> (Nick Piggin's message of "Wed, 18 Aug 2010 04:37:30 +1000") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Nick Piggin writes: > fs: fix do_lookup false negative > > In do_lookup, if we initially find no dentry, we take the directory i_mutex and > re-check the lookup. If we find a dentry there, then we revalidate it if > needed. However if that revalidate asks for the dentry to be invalidated, we > return -ENOENT from do_lookup. What should happen instead is an attempt to > allocate and lookup a new dentry. > > This is probably not noticed because it is rare. It is only reached if a > concurrent create races in first (in which case, the dentry probably won't be > invalidated anyway), or if the racy __d_lookup has failed due to a > false-negative (which is very rare). > > Fix this by removing code and have it use the normal reval path. Looks good, but a comment would be good. Reviewed-by: Andi Kleen -Andi -- ak@linux.intel.com -- Speaking for myself only.