From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E225329BD87; Fri, 1 May 2026 01:11:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777597890; cv=none; b=nhNmkirLs/DlaE4GJLuxIRtw6/X/QD1VnZY6F1mrajz/3AIItUfd/FeXTdY++uNTN16UISHWeQyESo2i7qlfkfXU3sM0nMSCuYkOtW9SR77CnBbfYBr8WvUN1oj2AaRbEBt54Aw4neh4JyvLi5pCYifC2q7zNGfsDPSc+VEV/ps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777597890; c=relaxed/simple; bh=q2FUFwmn4e1pgFgNlaih3TmZ3N3T0Ip+LeiuocIeZrM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l8uSGsvow8dBsvOR6IBgjLJxKMlqTo9J+7iFnGSeGILPcOxMRiUoL+0SbFq0vMDHmm2jZ5WdSLlT/TtmMRQXPJgYWoGg6Vsj1/c6Et0IpJJIdaPzGqrbQ5hJCLhoffvbibq5rZQ9x+SlwxflrISJpik9oXPmcC/URExx6dNk7ng= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=P40ZBP6T; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="P40ZBP6T" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=KR+8ubcBI7cu5TARnKFNwpgQVYeQTnmqfhastYpHDSo=; b=P40ZBP6T2AXqUPxr7OJkSk3XMX 8jEPjqTS4QOgnORGQ6x5wI7ep9ga1OQ8sFtzJx4YewG+qYlwuzeeHf7Bco3aJ8Vj3XKa8JDklNf89 UpBQAS1AKTdBYH2YwunyJgzpnCq+4r1APxK64muYk9f7KzVrsHWsGT0Jph0rcLKAaPFcWoQHLN74u /1YrHS+8gFt7aWpolHcQae3K2+iP944XbAR5SaD6il+QR46pteLw/vwEBtDf8Qi7pBBuO2TtR4qDE gqIv+eHDcbEUPBHUGQqhrFg0lqoVrFwTDtzHbVAn72N4+ef/+euLzWGduqMfxZp6OY2t/aUet6Zb4 68g2eFBw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wIcPk-0000000Ctnc-2wuA; Fri, 01 May 2026 01:11:33 +0000 Date: Fri, 1 May 2026 02:11:32 +0100 From: Al Viro To: NeilBrown Cc: Linus Torvalds , Christian Brauner , Jan Kara , Jeff Layton , Trond Myklebust , Anna Schumaker , Miklos Szeredi , Amir Goldstein , Jeremy Kerr , Ard Biesheuvel , linux-efi@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 04/19] VFS: use wait_var_event for waiting in d_alloc_parallel() Message-ID: <20260501011132.GA3518998@ZenIV> References: <20260427040517.828226-1-neilb@ownmail.net> <20260427040517.828226-5-neilb@ownmail.net> <20260428033738.GV3518998@ZenIV> <177737511992.1474915.1952404144121931523@noble.neil.brown.name> <20260428142225.GX3518998@ZenIV> <177741881482.1474915.12527082398060370192@noble.neil.brown.name> <20260429052626.GY3518998@ZenIV> <20260429170731.GZ3518998@ZenIV> <177759308866.1474915.9708613530229799376@noble.neil.brown.name> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <177759308866.1474915.9708613530229799376@noble.neil.brown.name> Sender: Al Viro On Fri, May 01, 2026 at 09:51:28AM +1000, NeilBrown wrote: > I saw this comment the first time I read this email, but I didn't > process it properly. That code is wrong. One in mainline isn't - d_wait comes from target, as it ought to. > It only makes sense to > __d_wake_in_lookup_waiters() a dentry that we know was in-lookup, and in > d_move, that is target. > This can only happen (I think) in nfs where nfs_lookup() skips the lookup > for LOOKUP_RENAME_TARGET and leaves the dentry in-lookup. Other threads > looking up that name will then block. > After the rename completes that in-lookup dentry will now be unhashed > but we need to wake it up so other threads can continue (and repeat the > lookup). > > So we need > > __d_wake_in_lookup_waiters(target); > > in d_move. target, not dentry. Yep. > Thanks for flagging this, > > Also my testing has hit a problem with some sort of deadlock in the nfs > server (so accessing and XFS filesystem). They are tring to unlink a > file and are waiting in d_alloc_parallel() under reconnect_path. > This is running generic/467. > > So better hold off this patchset until I have that understood. Let's deal with d_alloc_parallel() first; it doesn't have to be tied into the rest of patchset. Does the variant I've posted + s/dentry/target/ in that call of __d_wake_in_lookup_waiters() trigger any problems in your testing? If it doesn't, let's get that part out of the way - it makes sense on its own and getting it into -next (I'm sitting on a bunch of fs/dcache.c patches, and it would fit there nicely) would be a good idea. FWIW, your "noblock" variant is a misnomer - it *is* a trylock analogue of d_alloc_parallel(), all right, but it might very well block; on allocations, if nothing else, and there's a chance of having that dput(dentry) in "wouldblock" case coming right after the sucker ceased to be in-lookup and dropping the sole remaining reference. Which may block on real IO, final dput() being what it is... And I really dislike the "drop and regain a caller-held lock" games - we'd been there many times and it had ended up with race galore again and again; see https://lore.kernel.org/all/20250623213747.GJ1880847@ZenIV/ for one recent example...