Re: [PATCH v3 1/8] iomap: account for unaligned end offsets when truncating read range

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Nov 06, 2025 at 09:08:47AM -0800, Joanne Koong wrote:
> On Tue, Nov 4, 2025 at 5:27 PM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > On Tue, Nov 04, 2025 at 12:51:12PM -0800, Joanne Koong wrote:
> > > The end position to start truncating from may be at an offset into a
> > > block, which under the current logic would result in overtruncation.
> > >
> > > Adjust the calculation to account for unaligned end offsets.
> >
> > When would the read offset be in the middle of a block?  My guess is
> > that happens when fuse reads some unaligned number of bytes into a folio
> > and then stops?  Can this also happen with inlinedata mappings?  I think
> > those are the only two conditions where iomap isn't dealing with
> > fsblock-aligned mappings and/or IOs.
> >
> 
> The end offset may be in the middle of a block if the filesystem sets
> an unaligned mapping size (the length of the read used is derived from
> iomap_length(), which considers iter->iomap.length which is set by the
> filesystem's ->iomap_begin() handler). This is what we saw on erofs
> for inline mappings for example in this syzbot report [1].
> 
> [1] https://lore.kernel.org/linux-fsdevel/68ca71bd.050a0220.2ff435.04fc.GAE@google.com/

Ahh ok.  Then I've understood this patch sufficiently. :)
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> 
> Thanks,
> Joanne
> 
> > (Obviously the pagecache copies themselves aren't required to be
> > aligned)
> >
> > --D
>