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

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2025/10/17 06:03, Joanne Koong wrote:
> On Wed, Oct 15, 2025 at 6:58 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:

...

>>
>>>
>>> So I don't think this patch should have a fixes: tag for that commit.
>>> It seems to me like no one was hitting this path before with a
>>> non-block-aligned position and offset. Though now there will be a use
>>> case for it, which is fuse.
>>
>> To make it simplified, the issue is that:
>>    - Previously, before your fuse iomap read patchset (assuming Christian
>>      is already applied), there was no WARNING out of there;
>>
>>    - A new WARNING should be considered as a kernel regression.
> 
> No, the warning was always there. As shown in the syzbot report [1],
> the warning that triggers is this one in iomap_iter_advance()
> 
> int iomap_iter_advance(struct iomap_iter *iter, u64 *count)
> {
>          if (WARN_ON_ONCE(*count > iomap_length(iter)))
>                  return -EIO;
>          ...
> }
> 
> which was there even prior to the fuse iomap read patchset.
> 
> Erofs could still trigger this warning even without the fuse iomap
> read patchset changes. So I don't think this qualifies as a new
> warning that's caused by the fuse iomap read changes.

No, I'm pretty sure the current Linus upstream doesn't have this
issue, because:

  - I've checked it against v6.17 with the C repro and related
    Kconfig (with make olddefconfig revised);

  - IOMAP_INLINE is pretty common for directories and regular
    inodes, if it has such warning syzbot should be reported
    much earlier (d9dc477ff6a2 was commited at Feb 26, 2025;
    and b26816b4e320 was commited at Mar 19, 2025) in the dashboard
    (https://syzkaller.appspot.com/upstream/s/erofs) rather
    than triggered directly by your fuse read patchset.

Could you also check with v6.17 codebase?

Thanks,
Gao Xiang