From: Namjae Jeon <linkinjeon@kernel.org>
To: brauner@kernel.org, djwong@kernel.org
Cc: willy@infradead.org, xiang@kernel.org, hch@lst.de,
linux-fsdevel@vger.kernel.org,
Namjae Jeon <linkinjeon@kernel.org>,
Gao Xiang <hsiangkao@linux.alibaba.com>
Subject: [PATCH RESEND] iomap: remove over-strict inline data boundary check
Date: Mon, 11 May 2026 23:11:51 +0900 [thread overview]
Message-ID: <20260511141151.6021-1-linkinjeon@kernel.org> (raw)
The current iomap_inline_data_valid() check ensures that inline data
does not cross a PAGE_SIZE boundary. However, this is an unnecessarily
strict constraint. If a filesystem provides a valid iomap::inline_data
pointer and iomap::length, we should trust that the caller has mapped
sufficient memory for the range, even if it spans across page boundaries.
Removing this check allows filesystems to point directly to their
internal data structures without forced page-alignment or additional
redundant allocations. This remove iomap_inline_data_valid() and
its callers in buffered and direct I/O paths.
Suggested-by: Matthew Wilcox <willy@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
---
fs/iomap/buffered-io.c | 1 -
fs/iomap/direct-io.c | 3 ---
include/linux/iomap.h | 10 ----------
3 files changed, 14 deletions(-)
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index d7b648421a70..c4c5bddcbe3a 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -1058,7 +1058,6 @@ static bool iomap_write_end_inline(const struct iomap_iter *iter,
void *addr;
WARN_ON_ONCE(!folio_test_uptodate(folio));
- BUG_ON(!iomap_inline_data_valid(iomap));
if (WARN_ON_ONCE(!iomap->inline_data))
return false;
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index b0a6549b3848..a4459c5abb07 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -603,9 +603,6 @@ static int iomap_dio_inline_iter(struct iomap_iter *iomi, struct iomap_dio *dio)
if (WARN_ON_ONCE(!inline_data))
return -EIO;
- if (WARN_ON_ONCE(!iomap_inline_data_valid(iomap)))
- return -EIO;
-
if (dio->flags & IOMAP_DIO_WRITE) {
loff_t size = iomi->inode->i_size;
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
index 531f9ebdeeae..c758a8e865ed 100644
--- a/include/linux/iomap.h
+++ b/include/linux/iomap.h
@@ -142,16 +142,6 @@ static inline void *iomap_inline_data(const struct iomap *iomap, loff_t pos)
return iomap->inline_data + pos - iomap->offset;
}
-/*
- * Check if the mapping's length is within the valid range for inline data.
- * This is used to guard against accessing data beyond the page inline_data
- * points at.
- */
-static inline bool iomap_inline_data_valid(const struct iomap *iomap)
-{
- return iomap->length <= PAGE_SIZE - offset_in_page(iomap->inline_data);
-}
-
/*
* When get_folio succeeds, put_folio will always be called to do any
* cleanup work necessary. put_folio is responsible for unlocking and putting
--
2.25.1
next reply other threads:[~2026-05-11 14:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-11 14:11 Namjae Jeon [this message]
2026-05-11 14:57 ` [PATCH RESEND] iomap: remove over-strict inline data boundary check Christian Brauner
2026-05-12 6:07 ` Christoph Hellwig
2026-05-12 6:33 ` Namjae Jeon
2026-05-12 12:12 ` Christian Brauner
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=20260511141151.6021-1-linkinjeon@kernel.org \
--to=linkinjeon@kernel.org \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=willy@infradead.org \
--cc=xiang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox