Received: by 2002:a05:7412:7c14:b0:fa:6e18:a558 with SMTP id ii20csp302379rdb; Mon, 22 Jan 2024 04:55:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IFRta+J64FAM1Jcbedlbdyj/CSbvuHqodXnd4w0QF94u3z396nFRASjqWp1fLc8OyQptId8 X-Received: by 2002:a05:6a20:e116:b0:19a:4d54:67e4 with SMTP id kr22-20020a056a20e11600b0019a4d5467e4mr5034819pzb.2.1705928117739; Mon, 22 Jan 2024 04:55:17 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1705928117; cv=pass; d=google.com; s=arc-20160816; b=cOhmKUFX++YLcMZMXyiht4ZEYAtDnAyoTpqUEWKs3A1I5p5cg9tCSgo7LlGv7cr+vn uH73hcj3cEEFxkQd99IYF8DJDuOyRcRYkKOm4zF9atMxRt6UDNzzcWQ2tUZw8n8WqwKG z2BLpXf/+AAJkXsCs0QKxD+2O2t0Nozl1UdhaALulOrEcDO5XBoptdZSQJ0LwL0Iouqq XBn/iIz87yMmCJu6XHKX7T9ReKduzAiaF0lh13HdPv+MxHEXPsDl/nWkYEcEbDqyRjY4 4RymTf+IVvEoqN0pesbeDt5W7fdOwtiTNBFObi5cJbwi3Ym6utikLSYCa7OjNFzFt5Rw tO+Q== 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=+FTT++75kJXAyd2owaIPHDCXA7EuMAyWq5EQhzAnWG4=; fh=eGsAyyhCpmEu3drPh1b6mpZ/sYPa6e+oB0hw+Oy70rs=; b=GGReqrRNJ7BsjDkSMcnD541jbaQ0L+rNiQV57f810ggweNCalKWFdLpb4j0ESfjh21 kbjzpxhO5vggMWX7KCMbaVQ6cafTzUrJ5X61c3fxO0YsSctFHRn2y9hWz9eOPOKQqVrU YNfMV4RHbV+jKa0NuSRLMFVOoyMLCzkah+uwonlDHqQBTNrmS29yHbeKWYlY5hTmBWH/ 1Xy2FfZlAk/fesyOh3ebvh4CbzGVDBR/kOz9v+FSxjELlm59O85oAslMUiQXoldE3x64 nzXmEQMYsyjjoXHByM9ZzW9FXlnjqMsQXA72Xc0J4ffppWs9Wp1QszVPAOnI0wUBDh3d /FBw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=csYnXpu1; 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-nfs+bounces-1232-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-1232-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. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id s123-20020a632c81000000b005ce0d28f71fsi7963995pgs.347.2024.01.22.04.55.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 04:55:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs+bounces-1232-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=csYnXpu1; 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-nfs+bounces-1232-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-nfs+bounces-1232-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 3669B295A8B for ; Mon, 22 Jan 2024 12:43:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B3A003EA98; Mon, 22 Jan 2024 12:39:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="csYnXpu1" X-Original-To: linux-nfs@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 376CE3EA65 for ; Mon, 22 Jan 2024 12:39:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705927159; cv=none; b=KeRSKAFEICY5VRbKyLBpgcxmbOg0aqrkNX8SR6waKkff9B0v4IU7hjEh2UyDIG9V5l4d+NZkS7wO8Eqln+zppNm3IzYygRtu3llpsHlKKEkAMc8hfckDPh0V5rm7oKM7CZkauwbjTBeX8fTvfS00hzrW8kixJN2f35Z9HOdpzzU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1705927159; c=relaxed/simple; bh=JB0Vh1YbYo63PFWH26WwfxyAN6WsDsnz7f+l6o3Bvjg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gYQAkAJw4HQL0i7J5zHST82UFc9EAzxKUbhDmBRkn6Zg7wkNM81DYOdF2qlbdin/Z6nZFEBO8Qm8sAWPJElsL6FPwFAqelFNN9O1qQ3CptJTfWAt6ovt0Qeygl6rIjA3DnWkdfFAO8/Vq1KTdMWLA8qtcK613R9YG3OS2kn82Aw= 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=csYnXpu1; arc=none smtp.client-ip=170.10.133.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=1705927157; 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=+FTT++75kJXAyd2owaIPHDCXA7EuMAyWq5EQhzAnWG4=; b=csYnXpu1xn6fUqeBJEstqc1iVSiI28c8HOfergX8FhyBENWEG1C7fdy5cmUBppjv9G18MI hTXW4daOD53/flLY9jcYGT8+XwEidWesO0y0VG+87w5yOyA5O7Sju4TKAdR5fhF4BBTWrA uvFJBAGHtocL4jRl5ivna5amH+WFeRg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-500-DdMXm9N_PYeHTA5eKTR1gw-1; Mon, 22 Jan 2024 07:39:14 -0500 X-MC-Unique: DdMXm9N_PYeHTA5eKTR1gw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (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 47D1F88D286; Mon, 22 Jan 2024 12:39:13 +0000 (UTC) Received: from warthog.procyon.org.com (unknown [10.42.28.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id 573461C060B1; Mon, 22 Jan 2024 12:39:11 +0000 (UTC) From: David Howells To: Christian Brauner Cc: David Howells , Jeff Layton , Matthew Wilcox , netfs@lists.linux.dev, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs@lists.linux.dev, linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Jeffrey Altman , Marc Dionne Subject: [PATCH 08/10] afs: Fix error handling with lookup via FS.InlineBulkStatus Date: Mon, 22 Jan 2024 12:38:41 +0000 Message-ID: <20240122123845.3822570-9-dhowells@redhat.com> In-Reply-To: <20240122123845.3822570-1-dhowells@redhat.com> References: <20240122123845.3822570-1-dhowells@redhat.com> Precedence: bulk X-Mailing-List: linux-nfs@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.7 When afs does a lookup, it tries to use FS.InlineBulkStatus to preemptively look up a bunch of files in the parent directory and cache this locally, on the basis that we might want to look at them too (for example if someone does an ls on a directory, they may want want to then stat every file listed). FS.InlineBulkStatus can be considered a compound op with the normal abort code applying to the compound as a whole. Each status fetch within the compound is then given its own individual abort code - but assuming no error that prevents the bulk fetch from returning the compound result will be 0, even if all the constituent status fetches failed. At the conclusion of afs_do_lookup(), we should use the abort code from the appropriate status to determine the error to return, if any - but instead it is assumed that we were successful if the op as a whole succeeded and we return an incompletely initialised inode, resulting in ENOENT, no matter the actual reason. In the particular instance reported, a vnode with no permission granted to be accessed is being given a UAEACCES abort code which should be reported as EACCES, but is instead being reported as ENOENT. Fix this by abandoning the inode (which will be cleaned up with the op) if file[1] has an abort code indicated and turn that abort code into an error instead. Whilst we're at it, add a tracepoint so that the abort codes of the individual subrequests of FS.InlineBulkStatus can be logged. At the moment only the container abort code can be 0. Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept") Reported-by: Jeffrey Altman Signed-off-by: David Howells Reviewed-by: Marc Dionne cc: linux-afs@lists.infradead.org --- fs/afs/dir.c | 12 +++++++++--- include/trace/events/afs.h | 25 +++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 3 deletions(-) diff --git a/fs/afs/dir.c b/fs/afs/dir.c index eface67ccc06..b5b8de521f99 100644 --- a/fs/afs/dir.c +++ b/fs/afs/dir.c @@ -716,6 +716,8 @@ static void afs_do_lookup_success(struct afs_operation *op) break; } + if (vp->scb.status.abort_code) + trace_afs_bulkstat_error(op, &vp->fid, i, vp->scb.status.abort_code); if (!vp->scb.have_status && !vp->scb.have_error) continue; @@ -905,12 +907,16 @@ static struct inode *afs_do_lookup(struct inode *dir, struct dentry *dentry, afs_begin_vnode_operation(op); afs_wait_for_operation(op); } - inode = ERR_PTR(afs_op_error(op)); out_op: if (!afs_op_error(op)) { - inode = &op->file[1].vnode->netfs.inode; - op->file[1].vnode = NULL; + if (op->file[1].scb.status.abort_code) { + afs_op_accumulate_error(op, -ECONNABORTED, + op->file[1].scb.status.abort_code); + } else { + inode = &op->file[1].vnode->netfs.inode; + op->file[1].vnode = NULL; + } } if (op->file[0].scb.have_status) diff --git a/include/trace/events/afs.h b/include/trace/events/afs.h index 8d73171cb9f0..08f2c93d6b16 100644 --- a/include/trace/events/afs.h +++ b/include/trace/events/afs.h @@ -1071,6 +1071,31 @@ TRACE_EVENT(afs_file_error, __print_symbolic(__entry->where, afs_file_errors)) ); +TRACE_EVENT(afs_bulkstat_error, + TP_PROTO(struct afs_operation *op, struct afs_fid *fid, unsigned int index, s32 abort), + + TP_ARGS(op, fid, index, abort), + + TP_STRUCT__entry( + __field_struct(struct afs_fid, fid) + __field(unsigned int, op) + __field(unsigned int, index) + __field(s32, abort) + ), + + TP_fast_assign( + __entry->op = op->debug_id; + __entry->fid = *fid; + __entry->index = index; + __entry->abort = abort; + ), + + TP_printk("OP=%08x[%02x] %llx:%llx:%x a=%d", + __entry->op, __entry->index, + __entry->fid.vid, __entry->fid.vnode, __entry->fid.unique, + __entry->abort) + ); + TRACE_EVENT(afs_cm_no_server, TP_PROTO(struct afs_call *call, struct sockaddr_rxrpc *srx),