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

[Joanne Koong <joannelkoong@gmail.com>]

On Wed, Oct 15, 2025 at 10:40 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> On 2025/10/16 01:34, Joanne Koong wrote:
> > On Sun, Oct 12, 2025 at 8:00 PM Christoph Hellwig <hch@infradead.org> wrote:
> >>
> >> On Thu, Oct 09, 2025 at 03:56:03PM -0700, 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.
> >>
> >> Should this get a fixes tag?
> >
> > I don't think this needs a fixes tag because when it was originally
> > written (in commit 9dc55f1389f9 ("iomap: add support for sub-pagesize
> > buffered I/O without buffer heads") in 2018), it was only used by xfs.
> > think it was when erofs started using iomap that iomap mappings could
> > represent non-block-aligned data.
>
> What non-block-aligned data exactly? erofs is a strictly block-aligned
> filesystem except for tail inline data.
>
> Is it inline data? gfs2 also uses the similar inline data logic.

This is where I encountered it in erofs: [1] for the "WARNING in
iomap_iter_advance" syz repro. (this syzbot report was generated in
response to this patchset version [2]).

When I ran that syz program locally, I remember seeing pos=116 and length=3980.

Thanks,
Joanne

[1] https://ci.syzbot.org/series/6845596a-1ec9-4396-b9c4-48bddc606bef
[2] https://lore.kernel.org/linux-fsdevel/68ca71bd.050a0220.2ff435.04fc.GAE@google.com/

>
> Thanks,
> Gao Xiang
>
> >
> >
> > Thanks,
> > Joanne
> >
> >>
> >> Otherwise looks good:
> >>
> >> Reviewed-by: Christoph Hellwig <hch@lst.de>
>