Received: by 2002:ab2:710b:0:b0:1ef:a325:1205 with SMTP id z11csp1561763lql; Wed, 13 Mar 2024 01:16:08 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXZh+SO1SkWYh+01idobYDA0YpAp61/eDwRIgLHFg4QbNwu3EflbMpwJtfohAugboQ1nU4W304QGIwNYmhLXbCqwDCem8KYCvSRlZLyiQ== X-Google-Smtp-Source: AGHT+IEytFGT8yibkvTWgYPgd4IqfcuXWAdMs6PJ7TfBGzz4lhXcQSKPM7cXKRp7BgoCKQlxHito X-Received: by 2002:a05:6a00:804:b0:6e6:8df5:f77a with SMTP id m4-20020a056a00080400b006e68df5f77amr2055934pfk.31.1710317768615; Wed, 13 Mar 2024 01:16:08 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710317768; cv=pass; d=google.com; s=arc-20160816; b=FWwH/wcMEvY19lQh5pFQ65w3st7zaBD7JG0QEbJ41dOGBNeWR175zzfeEnouHrCEUx GHBYLUl9SRvJphb1pf7oPQzxyNsDqvPNinEqZc1Fj/HFiE1LXRDgbnEzsGqXe7kdQXDt nsL+u+l6gDAjR5dNuu3PPnnupva+Mi338Lu8cgxKODQJ51C6WFWHkuN9YnTWu+WIYv+9 +mibPJ8wIeIfTo4Ce46KVLIqaZsRBzIzUhCdRVgk8WbkfeT/AUblr9lprdTLJz5X35zW nwBNvLKev04rdKSK6FVptt8EVfZEQl+eQXw2OIa+sb61tNFgy/rFnrAEqpHeXgEQMB1u 2dZw== 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=91bNCNkvqiMRdaqnUe2NMNtpy4+Y+1Q/++18wDtAqbY=; fh=q5b0b12/c9B3HD3t3caNNmAFy1LNWNeL+ritg8twD4Y=; b=imqNCAGGyG5CBZJy4WTQt0O1HzHWwNE6ECeFHDRcpvBrBH8Zr1ALxXJYrM3b9d+f+T 0Jy1OFfhF9+xTzIdSnMMog2l8cOhJg5UfqV8MwhunSb0zBY6W9aWCf24y6MXOCoCnLRl 7AZbfyuvIWSiemD6Q7T4EnXNJg0MMrVZ0dyymBVioQBZblrLeomRj48KmkO+pPkYTvq8 fkE6jKZlIAMJU0Ckqr9UnO0YcGFPYZdW/ASsvsA7LTnOnAGt6mgLwHV8x4Q3dn3+1MBC qyrnZ9xTVi1v21+TtvA7UUrgWlbt38DSAUo4lmI/5oULt6SkgRFL/Iys5niyPhTkuzbr 0c8Q==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R+fhjGga; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-101207-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-101207-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id u14-20020a63454e000000b005dc36761ae8si8343666pgk.351.2024.03.13.01.16.08 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Mar 2024 01:16:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-101207-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R+fhjGga; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-101207-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-101207-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 497A2282FA9 for ; Wed, 13 Mar 2024 08:16:08 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CB91E224E0; Wed, 13 Mar 2024 08:15:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="R+fhjGga" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 6ACF31CF87 for ; Wed, 13 Mar 2024 08:15:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710317719; cv=none; b=C0Ji9uXcWxhwzyT17gNtEAi475Ur6O+3KbssEPKqOLBpNk2dcW7HBLd7n6YX9DL21X1OG7dTBWNVYjqTv3TJVderHGN/BkXLPE0mKma2WThGnC5NWuEzhzm+cxNzNVsDfjyBPTYVBHC1rwz1Ws2QExtH4xns3Nkjg3mac8uPgXQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710317719; c=relaxed/simple; bh=2JhikHnvZA+K8h+nUpROY6IhHBbfBTTzo4tCnXSdzbs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mwc/oI41BYzlZqsS1TWIKt/kMPMTj2a20louGsAXOaKfKjuR/jbYdvCASzkRd7bZy7YdkpKIQX6BdLhfPBoK6kRrfvQ7vYSPkeyvXjNTWYXiI2B2HVQAvhlYXEonawq12rdS96zdNzUPyCJ5YI4i5FK/AUlIqj6YKO9oksgz6H4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=R+fhjGga; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710317716; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=91bNCNkvqiMRdaqnUe2NMNtpy4+Y+1Q/++18wDtAqbY=; b=R+fhjGgaakgnZPgfClSpNEfkS2uLQ3/cToLVjp+muVbgsx4VRtRKgsAimGNi6ZfVHrB9E3 mjtNpeKTJyaUtq5+FmAoqdCVpgot0ddQBjqZaJldIbuHVw0AmhPxfUs8u+V2uCfRiWZlJA JF15IONQlqdHWgKX7VeROfarJGCI5Hk= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-587-79ungZldNcmTSKzd7Pbu6w-1; Wed, 13 Mar 2024 04:15:11 -0400 X-MC-Unique: 79ungZldNcmTSKzd7Pbu6w-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6C5FF3C000B3; Wed, 13 Mar 2024 08:15:11 +0000 (UTC) Received: from warthog.procyon.org.com (unknown [10.42.28.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id 982FD40C6CB2; Wed, 13 Mar 2024 08:15:10 +0000 (UTC) From: David Howells To: Marc Dionne Cc: David Howells , Christian Brauner , linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] afs: Fix occasional rmdir-then-VNOVNODE with generic/011 Date: Wed, 13 Mar 2024 08:15:03 +0000 Message-ID: <20240313081505.3060173-3-dhowells@redhat.com> In-Reply-To: <20240313081505.3060173-1-dhowells@redhat.com> References: <20240313081505.3060173-1-dhowells@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 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 cc: Marc Dionne cc: linux-afs@lists.infradead.org --- 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 46b37f2cce7d..32a53fc8dfb2 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);