From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Daejun Park <daejun7.park@samsung.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Christoph Hellwig <hch@lst.de>,
Pankaj Raghav <p.raghav@samsung.com>,
Carlos Maiolino <cem@kernel.org>, Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.15.y] xfs: cap the block count of xfs_iomap_write_direct() at one extent
Date: Sat, 14 Nov 2026 20:53:18 -0500 [thread overview]
Message-ID: <20261115015155.842255-1-sashal@kernel.org> (raw)
In-Reply-To: <20261109202300-failed-5.15-66d1ce09ebd7@kernel.org>
From: Daejun Park <daejun7.park@samsung.com>
[ Upstream commit 66d1ce09ebd72709f8d739630c39f440445173fd ]
xfs_iomap_write_direct() reserves blocks for the whole count in an
unsigned int. For a pNFS layout the client chooses that count, and an
RW LAYOUTGET for 16 TiB wraps the reservation and shuts XFS down.
xfs_bmapi_write() maps at most XFS_MAX_BMBT_EXTLEN blocks here, so cap
the count at that. nfsd asks again for the rest. The other callers get
the same mapping as before.
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Suggested-by: Christoph Hellwig <hch@lst.de>
Suggested-by: Pankaj Raghav <p.raghav@samsung.com>
Fixes: 527851124d10 ("xfs: implement pNFS export operations")
Cc: stable@vger.kernel.org
Signed-off-by: Daejun Park <daejun7.park@samsung.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
[ sashal: Replaced XFS_MAX_BMBT_EXTLEN with the equivalent MAXEXTLEN macro in the added code and comment. ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/xfs/xfs_iomap.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 093758440ad53..920ce54d00055 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -202,6 +202,14 @@ xfs_iomap_write_direct(
ASSERT(count_fsb > 0);
+ /*
+ * xfs_bmapi_write() maps at most MAXEXTLEN blocks in one
+ * mapping, so don't reserve blocks for more. A pNFS layout range
+ * comes from a client, and its block count may not even fit the
+ * 32-bit reservation. The caller maps the rest with a later call.
+ */
+ count_fsb = min_t(xfs_filblks_t, count_fsb, MAXEXTLEN);
+
resaligned = xfs_aligned_fsb_count(offset_fsb, count_fsb,
xfs_get_extsz_hint(ip));
if (unlikely(XFS_IS_REALTIME_INODE(ip))) {
--
2.53.0
prev parent reply other threads:[~2026-11-15 1:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 1:23 FAILED: patch "[PATCH] xfs: cap the block count of xfs_iomap_write_direct() at one extent" failed to apply to 5.15-stable tree Sasha Levin
2026-11-15 1:53 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261115015155.842255-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=cem@kernel.org \
--cc=daejun7.park@samsung.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=p.raghav@samsung.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.