From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.160.51 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793297394; b=VCtBpKbh3rRHthwClWwcnbFffsTHAaAlT1xiEeCflop5K8y/Qu3D2s/cLMQCGDycCuxu 1NvtKdNifclWPrRxbaZ+x9dKmOFZlG0CoDmwe+kX6VLGJ+iqw/bI8G4mTOtkdlTrz/EEB 150yin/PjU43vP1uRDUeP1vpuONXUAa+7HI2aUxRTrIJrPrK2CtgmG7AtpfhQDv4Aq+FD 4joN2zXAtiBPiUWPZzmFPp0/SJhfiX/XPmQ/N+kuyW1zvWVT/JHbtXSG+6XbzvGOx7YVW NzVLa5dNujdKJLX9xucp42/LuvGkFerUrvWFi8eeTQUZr8FmVVaF7iNavJebC1F2lBA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793297394; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: From:To:Cc:Subject:Date:Message-ID:X-Mailer:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding; bh=BL+32AV/+8oEq45HeDcTTOkYS9ivJyJauIHumIl+ifc=; b=b1uXOEsgCLEKIUWmNQdhFdT3Qsyf/s5t/dxwEyo9HFbfgjkFt5whDHT/FYPz6BgoM8KN uGVebmedLo7BM2DEjmDfL/Cey00In7//XoD8lBzoSJDANWxbDzZWTP66q6PBQA02DEJjp 6BzDITPSIwXYNLxJ6WyrtJFGCQ+JiAihb0nzPjagKZF7I+dDUGG3wAROvdC5pdXRJCUUM NseKyc9S+nav0YS9dPcXkB5VDrwvziUx0D3VidWIrvmLj/5IBkKcOoKdMQ7ZcZfk2mWQ+ /ozSEvrnyfH7K5ozZDABCjzX/w1ivamPc2xeZ39HGQOLcFH+Y1MhailGzLtl3+f9TMg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=hammerspace.com; spf=pass smtp.mailfrom=hammerspace.com; dkim=pass header.d=hammerspace.com header.i=@hammerspace.com header.a=rsa-sha256 header.s=google header.b=H+BMdFYq; arc=none smtp.remote-ip=209.85.160.51 Received: from mail-oa1-f51.google.com (mail-oa1-f51.google.com [209.85.160.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2E20606A31F for ; Thu, 29 Oct 2026 18:09:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org E2E20606A31F Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=hammerspace.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=hammerspace.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=hammerspace.com header.i=@hammerspace.com header.a=rsa-sha256 header.s=google header.b=H+BMdFYq Received: by mail-oa1-f51.google.com with SMTP id 586e51a60fabf-4a822463a22so1535578fac.2 for ; Thu, 29 Oct 2026 11:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hammerspace.com; s=google; t=1793297393; x=1793902193; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=BL+32AV/+8oEq45HeDcTTOkYS9ivJyJauIHumIl+ifc=; b=H+BMdFYqWyleR+B/XOB9zr9SPM/E+SfwEw2vjC/If0ehdKwoRIJEWo1nOqS5eQyLMF fyIgd+dHM9ElDiMRWvNbhLAFaf0lXdH6ix52QRlNR7SMDEXmd1q08/NOlUmJ75oR2AcI ZdNr+BkV2tjrkTF8A/yFFSgefslqtTXZe6hE7ffDpzwwtmxZS4/ELr11z77yTNhdBxSX Ush7n/lnxfD+WluhzrheQrdymDdmll9C4dBNLnPHX1SrZOiNOdj2ey6kYlUcqoC2d+q0 e85PWWgqnUToKtGHkbs/POTQguYGSnPuQOdOO+Z+7OgsNCtmmWWPNLHCGxNo1HobcQF1 g0aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793297393; x=1793902193; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=BL+32AV/+8oEq45HeDcTTOkYS9ivJyJauIHumIl+ifc=; b=VwOup3Qzb035Zo3RCUpD9B0OxhSMDdX93lVn/1P2+FZRO7BcYiT8GMxpNfBFapuypR x9KJabPPCgq449Ysq9gQh0WGe5iLx2dkyaPEtEM/FlgIMeLg3OfuBe7o3+JP9nPBrYwn z8+TQd496uCIfQjZxzjEbGQnrIASTlu+0kBepSAoS7zhE2dYtcDrPh8K2tzhv/cWd1pk gOPtHscpj2sywBwB/IBfPUxFiazWQSAzFFyvMEiuhWD3RG2+iAbf0k9i+r/GR2vRaKNI ujJEZTgR3t7LV2WVSRm6C9ltpzyuVofPogHu/kSQfHj9fm2PQ4lnasnKJ17Jo7COXFmu 66MQ== X-Forwarded-Encrypted: i=1; AKwUvBwrjV6nCjVhTgXv3dHGyQnCPTNihYzTt8wS+a4LyiF4Nl8MbA4tgbgI1KSz8ov0tXYu1QKRWFLYI5UOLpQ=@vger.kernel.org X-Gm-Message-State: AFq9FYKidD/YvBGaE8zg5wxKUMw1Ys8eMD8kGbHVM4GGVBX+cafBIJl0 zW/Bu8EIBlA2jeDvV9w33DtfujlxwlB9cEHzjVyhDFKyXJky6492vYDlNa27WwJ/r7I= X-Gm-Gg: AYBFou3dcpIOVt+rHQU4kAsWtrWNCqEZwa87JqboV5MY4jxdLJVAxE0Z4THiER5CeFg JiWfunDwHDbJnyCPsOVgBLNmr7AZ92cBj1iNZshOyxjgYJ55uzmAnBEVYoo/ZXWFTv1XHaSYMjj blo+VUROLtTWGS4Rn4JJjGbR2Bb1xQxAqbOgo66fyzbJnGAivwogLHVCpw7DhwP3Ib694Evrk8C vPulhm5p6L08cD6qPH5lTX6mqQSnzFU8AK6Emo+LOTES3pzg95HxTmIkGLnPV+5kbsr+we2RlCH Ok2CVylU8td6tzpGnFvVsaFJ+ncXjqCXl2tKr2+iiRFLsG9/b/hXOLTl4do4L1jErc0sl243zfv 81W+jNb8FaZQdIsVoUfP9nPXpirCDjMvcpFxyfDzOF0U6YK0jC0Etbe1Ug/vxzU6YOTje+/MdDq rOR3rYQApB87v+ANmYFO6eaaMGcKmKEK7cZdPzf35j3Ox+nPEiYASzX+ylnu0ZlxlYqowT9zyuH ZMJXHssVBO4hYy7Re2EZnXZkTAfGF1o608xeORcpGT/yoS1yol/lGspU8Pn7Z6PkFuR0JHvmJJe kecUVXl4Fvb8B9Zrv6myLRhjMM6Kavegor9+Y7JOqlB7deJ+Sti+0WIUd5gJvBv6Df5u9vjW X-Received: by 2002:a05:6871:3287:b0:4a7:5eb7:ab97 with SMTP id 586e51a60fabf-4a8bb62169emr4560053fac.32.1793297392261; Thu, 29 Oct 2026 11:09:52 -0700 (PDT) Received: from localhost (75-163-200-235.clsp.qwest.net. [75.163.200.235]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-4a9048e6ab1sm119378fac.8.2026.10.29.11.09.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Oct 2026 11:09:51 -0700 (PDT) From: Jonathan Flynn To: NeilBrown , Trond Myklebust , Anna Schumaker Cc: Alexander Viro , Christian Brauner , Jeff Layton , Chuck Lever , Jan Kara , linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 0/3] nfs: fix the silly-delete hand-off that 2/9 makes reachable Date: Thu, 29 Oct 2026 12:09:47 -0600 Message-ID: <20261029180950.387072-1-jonathan.flynn@hammerspace.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20261028041023.3738553-3-neilb@ownmail.net> References: <20261028041023.3738553-3-neilb@ownmail.net> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Neil, Your "nfs: fix nfs_call_unlink()" computes the silly name's hash before d_alloc_parallel(), so nfs_call_unlink() can now find another cached entry for that name and hand it the pending silly-delete. With it applied, that happens: an entry made by a fresh lookup of the silly name, after the original entry was invalidated, receives the delete when the file is closed. Three problems in the hand-off become reachable with it, and these patches fix them: 1/3 the hand-off can overwrite NFS_FSDATA_BLOCKED on an entry whose REMOVE or RENAME is in flight (Sashiko's review of 2/9 reports this too); 2/3 the other order: nfs_rename() tests its target before it takes ->d_lock, so a hand-off landing in between is kfree()d by block_revalidate(), leaving DCACHE_NFSFS_RENAMED set with no data and a NULL dereference at the final dput(); a hand-off that the VFS's unlocked test missed also trips the WARN_ON()s in nfs_unlink() and nfs_rename(). nfs_rename() now tests under ->d_lock, and both return -EBUSY, as may_delete_dentry() does; 3/3 nfs_call_unlink() holds rmdir_sem for read across its lookup and across the dput() of the alias, and either can kill a dentry carrying a silly-delete, which re-enters nfs_call_unlink() with rmdir_sem still held: that deadlocks against a waiting rmdir() (Sashiko's review of 2/9 reports the alias case). It now takes rmdir_sem only for the REMOVE it sends, which also closes an older route to the same re-entry that does not need 2/9: NFSv4's delegation return in ->unlink_setup(). They have to go wherever 2/9 goes, and its Fixes: tag will take it to stable. Fold them into 2/9 if you prefer, as you did with the d_seq fix in 1/9. One window is not covered, and you may prefer to close it another way. After nfs_unlink() or nfs_rename() clears the mark, and before the VFS's d_delete() or nfs_rename()'s d_move(), a hand-off can still land on the entry. For an unlink, that costs only a second REMOVE, which finds nothing. For a rename onto the silly name, the target is left owing a REMOVE of a name that now belongs to the renamed file. That REMOVE is normally dropped, because nfs_call_unlink() then finds the renamed file's own entry and its file handle differs; but if that entry has left the dcache by the time the target's last reference goes, the REMOVE is sent and deletes the renamed file. Closing the rename case would take the hand-off refusing an alias that is no longer hashed, and nfs_rename() dropping, under ->d_lock and after d_move(), a silly-delete that landed after its mark cleared. I have a draft of that, and can test and send it if you want it. Tested with your v4 and these patches on a 7.3-based kernel, over NFSv4.2 to a pNFS metadata server that is not knfsd. The hand-off happens as described above. With 3/3, the nested nfs_call_unlink() that follows it starts with rmdir_sem not held, where without 3/3 it ran with rmdir_sem held for read, and the REMOVE is sent once. The removal race tests of my RFC, posted in reply to your 0/9, passed on this kernel, as did a PROVE_LOCKING and KASAN build running them, though lockdep does not see rmdir_sem's read hold, which is taken with down_read_non_owner(). No test here hits the races that 1/3 and 2/3 close, or the deadlock itself, so for those the fixes rest on the code. The series applies to 83f32c773255 in Linus's tree with your v4, and fs/ compiles without warnings at each patch. Tools: these patches, their changelogs and this letter were written with Claude Code, using Anthropic's Claude Opus 5 and Claude Opus 5.5 models, at my direction. It found the problems fixed by 1/3 and 2/3, and two of the three routes in 3/3, reading the code with and without Sashiko's review prompts; Sashiko's own review of 2/9 reported the problem in 1/3 as well, and the route through the alias in 3/3. Thanks, Jonathan Jonathan Flynn (3): nfs: do not transfer a sillydelete onto a blocked dentry nfs: answer a handed-off silly-delete on a removal target with -EBUSY nfs: take rmdir_sem for a silly-delete only when its REMOVE is sent fs/nfs/dir.c | 32 ++++++++++++++++++++++++++------ fs/nfs/unlink.c | 39 ++++++++++++++++++++++++++++++++------- 2 files changed, 58 insertions(+), 13 deletions(-) base-commit: 83f32c773255720a661aa45d83e36278135f23f5 prerequisite-patch-id: 3405b4d6ab8b0bf24ba63a898083d617deec4f24 prerequisite-patch-id: 096657d6d80d7ca533ccb574d2af65611ede4af2 prerequisite-patch-id: 1a2319c14739918aef86116647fea28ae85ad4df prerequisite-patch-id: 725cb18c3936d50141ef27dafc159bf50b64a5bd prerequisite-patch-id: b39cdd352b97e2cd247311fd5db620dbff227bd7 prerequisite-patch-id: f9f3f0e945cadf96113d4ac9ab8f7b0c207af4e5 prerequisite-patch-id: 4c09a15390bb556d79bea1ee733f52a58bec80ef prerequisite-patch-id: 7c026717a97b2c86a169539822f5d14650f68f8a prerequisite-patch-id: a702d54495d0f3d7f88b82411d884dcf5aacf9a0 -- 2.43.0