From: Christoph Hellwig <hch@lst.de>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: linux-fsdevel@vger.kernel.org,
Christian Brauner <brauner@kernel.org>,
Brian Foster <bfoster@redhat.com>,
linux-erofs@lists.ozlabs.org, linux-xfs@vger.kernel.org,
Bo Liu <liubo03@inspur.com>, Christoph Hellwig <hch@lst.de>,
"Darrick J. Wong" <djwong@kernel.org>
Subject: Re: [PATCH -next] iomap: fix inline data on buffered read
Date: Wed, 19 Mar 2025 09:17:30 +0100 [thread overview]
Message-ID: <20250319081730.GB26281@lst.de> (raw)
In-Reply-To: <20250319025953.3559299-1-hsiangkao@linux.alibaba.com>
I'd move the iomap_iter_advance into iomap_read_inline_data, just like
we've pushed it down as far as possible elsewhere, e.g. something like
the patch below. Although with that having size and length puzzles
me a bit, so maybe someone more familar with the code could figure
out why we need both, how they can be different and either document
or eliminate that.
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index d52cfdc299c4..7858c8834144 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -332,15 +332,15 @@ struct iomap_readpage_ctx {
* Only a single IOMAP_INLINE extent is allowed at the end of each file.
* Returns zero for success to complete the read, or the usual negative errno.
*/
-static int iomap_read_inline_data(const struct iomap_iter *iter,
- struct folio *folio)
+static int iomap_read_inline_data(struct iomap_iter *iter, struct folio *folio)
{
const struct iomap *iomap = iomap_iter_srcmap(iter);
size_t size = i_size_read(iter->inode) - iomap->offset;
+ loff_t length = iomap_length(iter);
size_t offset = offset_in_folio(folio, iomap->offset);
if (folio_test_uptodate(folio))
- return 0;
+ goto advance;
if (WARN_ON_ONCE(size > iomap->length))
return -EIO;
@@ -349,7 +349,8 @@ static int iomap_read_inline_data(const struct iomap_iter *iter,
folio_fill_tail(folio, offset, iomap->inline_data, size);
iomap_set_range_uptodate(folio, offset, folio_size(folio) - offset);
- return 0;
+advance:
+ return iomap_iter_advance(iter, &length);
}
static inline bool iomap_block_needs_zeroing(const struct iomap_iter *iter,
next prev parent reply other threads:[~2025-03-19 8:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 2:59 [PATCH -next] iomap: fix inline data on buffered read Gao Xiang
2025-03-19 8:17 ` Christoph Hellwig [this message]
2025-03-19 8:23 ` Christoph Hellwig
2025-03-19 8:34 ` Gao Xiang
-- strict thread matches above, loose matches on Subject: below --
2025-03-19 6:40 Bo Liu (刘波)-浪潮信息
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=20250319081730.GB26281@lst.de \
--to=hch@lst.de \
--cc=bfoster@redhat.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=liubo03@inspur.com \
/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.