From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793829030; b=Dg7TAyRMWdTl+oQ+2Bk82lYPwiqfPZxoyQnZKOSaqqu7y1Mdo8KxnQWR/tpMUj4phZfH t7DeTYGnNj3vvH7ca2NqOchA/S1fO58zHGa9fxV/XG4VIKqCPfjFPdQPuMJ+kzQxuYoYl cx1dnI5PqciTj+q4WgKV2K9Kljb7rDtwLAflzYMwQZKZmkT2bMt9YT4QU/IC61O6jR8dD YeYBEvbG/wsF99l0WV4Na8U3QWoj2AmIRtoXbiuSQnn0xB43vfTJNLgDFQegxglzCk7z6 CfQ42PpwpHwKT7LlF7Rl+x2dXArTmd991a+PUBKKFtWFU7jQJCBst+2F2g86Np3MpMg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793829030; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=p8jEO4DiLaYUxmVLaMAk6LwQzoer8y9vHn6er03XDb4=; b=a7gtiMllxxWuc2noPmOMGIhHx0GiCtMIHM9kZjnPo9NhjrETBxQtNzg8xaIGTbditdgE FmFaJPRPwOsQM+8IswPQYMCjaBFaofnx4Af4BsSHpVJ85hGo15Yj35Tm0ZjIGGsCLTX9t FBVbQv9R9eIH6H2wRU1nmaiMm9frjtCb9XtvqsJT6YXv5f0Qc6w+yCravFn/zyiodfPnG hDhBVIJRoxqLUlc8V5TmVFPFlmrDiGZnkGQHHrCFfq3KHOPvcYbiogjwASKzcYE2Fcj70 HLWhJbpPdxDFs5REpirNYGHghUGwsf7ypd7Xci99T/bSdchcn5KcCjo7inwcn+a24Gw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b="Plyzsmd/"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0FAD6070745; Wed, 4 Nov 2026 21:50:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=Plyzsmd/ Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91E131F000C1; Wed, 4 Nov 2026 21:50:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1793829029; bh=p8jEO4DiLaYUxmVLaMAk6LwQzoer8y9vHn6er03XDb4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Plyzsmd/eSYwNz86nedLV/Kn4aaTDqf190T9lH4oVczR+TPksASzU3t3YR2uIUhu7 lYqoa9jzBqj2S5MEHjgMdgHD0dMJX/ZOl5Qz5kh0y2SaI46TJK5Vs6TYSGQqS4/rJu pVYMdY6irCozJ8Tf92lk/FONiC9vBD/czerTSYM0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Benjamin Coddington , Jeff Layton , Anna Schumaker Subject: [PATCH 7.3 400/547] NFSv4.1/pnfs: suspend pNFS on NFS4ERR_TOOSMALL from LAYOUTGET Date: Wed, 4 Nov 2026 16:09:44 -0500 Message-ID: <20261104211049.675403561@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261104211038.406938024@linuxfoundation.org> References: <20261104211038.406938024@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Benjamin Coddington commit 28c950413605fb5b6cb3863c5e3274ea69701097 upstream. If the layout for the requested range is larger than the size the client advertised in loga_maxcount, RFC 8881 Section 18.43.3 has the metadata server return NFS4ERR_TOOSMALL. The client caps loga_maxcount at a single page, so a flexfiles server that stripes a layout segment across several dozen data servers produces this error today. The client has no handling for it: nfs4_stat_to_errno() maps the error to -ETOOSMALL during decode, which nothing in the layoutget path recognizes and nfs_error_is_fatal() does not consider fatal, so pnfs_update_layout() clears the layout fail bit and returns no segment. The I/O falls back to the MDS, but because no fail bit was set, every subsequent pageio attempt sends another LAYOUTGET that is doomed to the same NFS4ERR_TOOSMALL. Files whose layouts do not fit the reply buffer never use pNFS and pay an extra round trip on every pageio. Map -ETOOSMALL to -EMSGSIZE in the layoutget exception handler and have pnfs_update_layout() treat it like NFS4ERR_LAYOUTUNAVAILABLE: mark the layout mode as failed and fall back to I/O through the MDS. Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Benjamin Coddington Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman --- fs/nfs/nfs4proc.c | 8 ++++++++ fs/nfs/pnfs.c | 2 ++ 2 files changed, 10 insertions(+) --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -9681,6 +9681,14 @@ nfs4_layoutget_handle_exception(struct r status = -EOVERFLOW; goto out; /* + * NFS4ERR_TOOSMALL means the layout for the requested range + * exceeds what the client advertised in loga_maxcount (see + * RFC8881 section 18.43.3). + */ + case -ETOOSMALL: + status = -EMSGSIZE; + goto out; + /* * NFS4ERR_LAYOUTTRYLATER is a conflict with another client * (or clients) writing to the same RAID stripe except when * the minlength argument is 0 (see RFC5661 section 18.43.3). --- a/fs/nfs/pnfs.c +++ b/fs/nfs/pnfs.c @@ -2331,6 +2331,8 @@ lookup_again: break; case -ENODATA: /* The server returned NFS4ERR_LAYOUTUNAVAILABLE */ + case -EMSGSIZE: + /* The layout exceeded loga_maxcount (NFS4ERR_TOOSMALL) */ pnfs_layout_set_fail_bit( lo, pnfs_iomode_to_fail_bit(iomode)); lseg = NULL;