Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp2399358lqp; Sun, 24 Mar 2024 17:50:56 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXbZGvZgLMMOeVBwsiDI3Dkzo0Kiwfjwn2Mrfuypkc1AvnDJrf5dTy/j7WtJE8HF4yFh0NWnI5aDOl/+T7rErK4tsYNu89uqGGcZ1F3Mw== X-Google-Smtp-Source: AGHT+IGihQJ6UjrLRXXrO07bo6M4J6fkTsmGuvM3rGpSb2Els4p0keV1U3Vh39flULXrVklvr3lL X-Received: by 2002:a05:6214:19c9:b0:696:8191:9b17 with SMTP id j9-20020a05621419c900b0069681919b17mr5245103qvc.26.1711327856186; Sun, 24 Mar 2024 17:50:56 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711327856; cv=pass; d=google.com; s=arc-20160816; b=pncjd5MU+C15Ny5hnCtjWYwPo+MLAwithgYIPC14irn0VK+LsT4VaLQYN+albOQD30 tUxBo2HQEcKGJUQK2zMKfk5ZFg4tHSxO//5gNd2+xfyQfG+f3zkrECFNqQoIKJN5eBiG RX3sPrCqOWiEBVn1oD8KpFci/ixzOrfprA1upmOovLihBZkbWyqjoUQsdwn36QTTIAzG 5z0QPo5fJKOPDb0bHQAAlFMDsojeHrB3ha4twhWQZZFB+5Wsth0N6m2VZ6oqZyrZgzcV 7h8dVIWQzU+5I9sQz/7M4gStuqZRqHmA7L66hU/qE3bCsvJhK3X1AC1B1JEHU3e5Q1mh 6qMA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=RRVF/nkOD0UbrxUV34WZe4kVlPpwbDmiZ8sWOmPjRsQ=; fh=kkoHtEqyudNMlW4XJQBgU/B83Swh/oqTJO05vrOYL8Y=; b=KUKmcrGFPcXfTVcq0dLLd7oBWZIPJL1Ga3nzBC4wYgz+FRKACWQ3flNrX1CVVt1ZRM TeArDBNcWDbdzism/I626ADfDxRJE/lbJpqlNqeUJEzFQ1mR6Vwc6jM2KqE8tHEUN327 7ScFxG0iFqZFyMXK/Ng6vpkERx7JRG3sGpaBfyeSib4L3TJDmKUmuhBwXqFSg09Wr/Un mN1OORvQvppKRiSgHiH2fXoHVHRPCto0dLuWSCIQWlWWwVLbwukd9IgDOW6HhZKfdhAM 95COV+6vCZVCAybhoHMqBunjhZoP9J0AQ4bEMMbS4WMucNj6q9fPpzFSStZUSZkjbRnF Hecg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=K2BdbIlP; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-113494-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-113494-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id gi12-20020a056214248c00b0068d0c6f5766si6696788qvb.515.2024.03.24.17.50.56 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Mar 2024 17:50:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-113494-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=K2BdbIlP; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-113494-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-113494-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id E21251C2414F for ; Mon, 25 Mar 2024 00:50:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0DC351B8FAF; Sun, 24 Mar 2024 22:44:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K2BdbIlP" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 0D0DB1B885F; Sun, 24 Mar 2024 22:44:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320296; cv=none; b=k/Y8UeaaX6yJaBcFu134+7jB8w5ZMlwBS3EiLFmbV5gl7Vsv95wtxzM2an56918T5EiQ1X66MRbMfO03LLvHLNfpUK0mc/3Rxr7x5o0XgPIF5LYKm3Gesl07QlU7Uiz7bpkFZt67Mm3oXHRZdK4F5LE84yhEInRLSmdd33ikPlM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320296; c=relaxed/simple; bh=67eAQKcAC4gVWRQlrJDdEVJNqMFb1SeOyoS/9NlUAbg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tPx4zBfN8SiVlubu32pDlCKPQS0pZXRfodylZ+WmDCKBPVzqeD8LeIvn/iYzYg/DNjauPGY3NL1YRwh+eDyidTQiEDqz8oQmakLByAAxMiq8wgMfVev6W/lj5CbsNxAhJTTPf3K2TEIBtOimDJmLY+27jMqmkDUzW/K2+gGlOHc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K2BdbIlP; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18CCDC433F1; Sun, 24 Mar 2024 22:44:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320295; bh=67eAQKcAC4gVWRQlrJDdEVJNqMFb1SeOyoS/9NlUAbg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K2BdbIlPI1L21da7cZCB2e0j3uEhXUS/oYJaeygzU5gpuBT9Z5sgDL3fyb8FT1NCe Q4OS5QDdUj0jmujLeerFsEteyRrkgF4XcXBxZr9zsbHXJXBf5aOTqLN6wwALY0988U 7wfPnYnDdfpPJ73jMQ7DUOgNVaNHAR6dbw4TFF5c1Iu3B5Rjuvf6Gr7dFRxjwDO5Sw BiJZ6cvmYTAaU//ADd3op18rzT+FHwMXDfR5lntmSTEVOR0/bfajxRnkQNHAt72m1S A5XCWddQubALUOq+c54/OAHYezlC+fxCtxj4m6k7jv1UvKEENl6M0Js/GujTiB5PjF i6qivxrAZeV8w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Howells , Marc Dionne , linux-afs@lists.infradead.org, Christian Brauner , Sasha Levin Subject: [PATCH 6.8 603/715] afs: Fix occasional rmdir-then-VNOVNODE with generic/011 Date: Sun, 24 Mar 2024 18:33:02 -0400 Message-ID: <20240324223455.1342824-604-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit From: David Howells [ Upstream commit b74c02a37987d3ea755f96119c527f5e91950592 ] Sometimes generic/011 causes kafs to follow up an FS.RemoveDir RPC call by spending around a second sending a slew of FS.FetchStatus RPC calls to the directory just deleted that then abort with VNOVNODE, indicating deletion of the target directory. This seems to stem from userspace attempting to stat the directory or something in it: afs_select_fileserver+0x46d/0xaa2 afs_wait_for_operation+0x12/0x17e afs_fetch_status+0x56/0x75 afs_validate+0xfb/0x240 afs_permission+0xef/0x1b0 inode_permission+0x90/0x139 link_path_walk.part.0.constprop.0+0x6f/0x2f0 path_lookupat+0x4c/0xfa filename_lookup+0x63/0xd7 vfs_statx+0x62/0x13f vfs_fstatat+0x72/0x8a The issue appears to be that afs_dir_remove_subdir() marks the callback promise as being cancelled by setting the expiry time to AFS_NO_CB_PROMISE - which then confuses afs_validate() which sends the FetchStatus to try and get a new one before it checks for the AFS_VNODE_DELETED flag which indicates that we know the directory got deleted. Fix this by: (1) Make afs_check_validity() return true if AFS_VNODE_DELETED is set, and then tweak the return from afs_validate() if the DELETED flag is set. (2) Move the AFS_VNODE_DELETED check in afs_validate() up above the expiration check to immediately after we've grabbed the validate_lock. Fixes: 453924de6212 ("afs: Overhaul invalidation handling to better support RO volumes") Signed-off-by: David Howells Link: https://lore.kernel.org/r/20240313081505.3060173-3-dhowells@redhat.com Reviewed-by: Marc Dionne cc: Marc Dionne cc: linux-afs@lists.infradead.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin --- fs/afs/validation.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/fs/afs/validation.c b/fs/afs/validation.c index 46b37f2cce7d9..32a53fc8dfb26 100644 --- a/fs/afs/validation.c +++ b/fs/afs/validation.c @@ -122,6 +122,9 @@ bool afs_check_validity(const struct afs_vnode *vnode) const struct afs_volume *volume = vnode->volume; time64_t deadline = ktime_get_real_seconds() + 10; + if (test_bit(AFS_VNODE_DELETED, &vnode->flags)) + return true; + if (atomic_read(&volume->cb_v_check) != atomic_read(&volume->cb_v_break) || atomic64_read(&vnode->cb_expires_at) <= deadline || volume->cb_expires_at <= deadline || @@ -389,12 +392,17 @@ int afs_validate(struct afs_vnode *vnode, struct key *key) key_serial(key)); if (afs_check_validity(vnode)) - return 0; + return test_bit(AFS_VNODE_DELETED, &vnode->flags) ? -ESTALE : 0; ret = down_write_killable(&vnode->validate_lock); if (ret < 0) goto error; + if (test_bit(AFS_VNODE_DELETED, &vnode->flags)) { + ret = -ESTALE; + goto error_unlock; + } + /* Validate a volume after the v_break has changed or the volume * callback expired. We only want to do this once per volume per * v_break change. The actual work will be done when parsing the @@ -448,12 +456,6 @@ int afs_validate(struct afs_vnode *vnode, struct key *key) vnode->cb_ro_snapshot = cb_ro_snapshot; vnode->cb_scrub = cb_scrub; - if (test_bit(AFS_VNODE_DELETED, &vnode->flags)) { - _debug("file already deleted"); - ret = -ESTALE; - goto error_unlock; - } - /* if the vnode's data version number changed then its contents are * different */ zap |= test_and_clear_bit(AFS_VNODE_ZAP_DATA, &vnode->flags); -- 2.43.0