Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp732445ybz; Fri, 24 Apr 2020 08:22:21 -0700 (PDT) X-Google-Smtp-Source: APiQypLrm9BwzkRuKtOOfdLQ5FMBO7AX70oF84vaeuh8m2XvgUqRoK2YPnSU1IZW3gcYbxuOxumx X-Received: by 2002:a17:907:7211:: with SMTP id dr17mr7464260ejc.296.1587741741072; Fri, 24 Apr 2020 08:22:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587741741; cv=none; d=google.com; s=arc-20160816; b=oX+INzjWA3Nw1F28QtituihJvGefgoofB0RyrWafgbEOK6UmH+druKB78JsVSmwTcC SkPLP7KNJmGS3TLTwBPEtGUskJTp6bdV6fBtjEPB4k9dBwCuq7ZbE6zBv9UxlfHLwzDk lBjMwJw6OdA9FdifWP4G5j5gB/kz3I+J+T/NXdE7murmxL82Dhz8nOLr3ADo2pkoSsbr TScalSfVayBR+c7z2cVbFzaMr0qBQavBpYvoOgkFy0K3K4Nc1WDMavi232oqo58CWOgr DWdsCcm3S8282CsZq+ZkIRnaicKYD0EMIFEWAokLVoyXJlLVT+W7YjhYJn4IR32T/lz0 wQzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:organization:dkim-signature; bh=2Z+Gadu21Z2xRE8cYGvxOo9yHCfq6rp1d/CEGZW+78A=; b=Qvw2wMTR50/LWQ62ge/eFiXQZS2JuudCvDNxcjH8Pdq7uPqblBWG55qZTiwsTG50zW y+QMstRdXD13C7vZh4h8y2neEZbiElc1i/u1LVhVIsADdMgixhTjgJwTi3Q3M2bagyPk YlCS6ulMY8zAsQdw+8oPkxWJazP9UjU9lBiCUjlfylJVIWy7QwFgy1jzIkRJBCxQkjfj NwIwVnBV8nBjRkfF3mwQIQwUUsgdRfQjb+fdSqHhVld77PvbSiVTQxaFN+Vscm3IUFV9 QHsc2OOvHGkMxPKgo0oY+zYXj/jQs/aTyZe+x1Y7aoUtRuTwN3iq2+oI2K9X3WZEctKr qC/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ERNapSpp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c22si3104231edr.408.2020.04.24.08.21.51; Fri, 24 Apr 2020 08:22:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ERNapSpp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727947AbgDXPUU (ORCPT + 99 others); Fri, 24 Apr 2020 11:20:20 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:55731 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727868AbgDXPUT (ORCPT ); Fri, 24 Apr 2020 11:20:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587741618; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2Z+Gadu21Z2xRE8cYGvxOo9yHCfq6rp1d/CEGZW+78A=; b=ERNapSpp8t1L427qnG7XIdBBzs5gBjKUSiMEXDsDE6FrYmCejb6i790Ip3G8t8OJvJwUB8 YOXte+pOtmuBUdFdHNTrKY52rR4Q2ovDgi1sSZAHRbt+x6tKJomSnBRx2GULmeRJmCAD95 yZu6mSFuJQReMqNk5u4iNY+FZk+gIvs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-392-hUBQ_FouPRuxm-87spewCA-1; Fri, 24 Apr 2020 11:19:56 -0400 X-MC-Unique: hUBQ_FouPRuxm-87spewCA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 79D5B107ACCA; Fri, 24 Apr 2020 15:19:55 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-113-129.rdu2.redhat.com [10.10.113.129]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5AD0260CD0; Fri, 24 Apr 2020 15:19:54 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Subject: [PATCH 1/8] afs: Always include dir in bulk status fetch from afs_do_lookup() From: David Howells To: linux-afs@lists.infradead.org Cc: Dave Botsch , Jeffrey Altman , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, dhowells@redhat.com Date: Fri, 24 Apr 2020 16:19:53 +0100 Message-ID: <158774159361.3619859.14445546902173034503.stgit@warthog.procyon.org.uk> In-Reply-To: <158774158625.3619859.10579201535876583842.stgit@warthog.procyon.org.uk> References: <158774158625.3619859.10579201535876583842.stgit@warthog.procyon.org.uk> User-Agent: StGit/0.21 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a lookup is done in an AFS directory, the filesystem will speculate and fetch up to 49 other statuses for files in the same directory and fetch those as well, turning them into inodes or updating inodes that already exist. However, occasionally, a callback break might go missing due to NAT timing out, but the afs filesystem doesn't then realise that the directory is not up to date. Alleviate this by using one of the status slots to check the directory in which the lookup is being done. Reported-by: Dave Botsch Suggested-by: Jeffrey Altman Signed-off-by: David Howells --- fs/afs/dir.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fs/afs/dir.c b/fs/afs/dir.c index d1e1caa23c8b..3c486340b220 100644 --- a/fs/afs/dir.c +++ b/fs/afs/dir.c @@ -658,7 +658,8 @@ static struct inode *afs_do_lookup(struct inode *dir, struct dentry *dentry, cookie->ctx.actor = afs_lookup_filldir; cookie->name = dentry->d_name; - cookie->nr_fids = 1; /* slot 0 is saved for the fid we actually want */ + cookie->nr_fids = 2; /* slot 0 is saved for the fid we actually want + * and slot 1 for the directory */ read_seqlock_excl(&dvnode->cb_lock); dcbi = rcu_dereference_protected(dvnode->cb_interest, @@ -709,7 +710,11 @@ static struct inode *afs_do_lookup(struct inode *dir, struct dentry *dentry, if (!cookie->inodes) goto out_s; - for (i = 1; i < cookie->nr_fids; i++) { + cookie->fids[1] = dvnode->fid; + cookie->statuses[1].cb_break = afs_calc_vnode_cb_break(dvnode); + cookie->inodes[1] = igrab(&dvnode->vfs_inode); + + for (i = 2; i < cookie->nr_fids; i++) { scb = &cookie->statuses[i]; /* Find any inodes that already exist and get their