Re: [PATCH AUTOSEL 6.18-6.6] iomap: adjust read range correctly for non-block-aligned positions

[Sasha Levin <sashal@kernel.org>]

On Wed, Dec 03, 2025 at 03:07:12PM -0800, Joanne Koong wrote:
>On Wed, Dec 3, 2025 at 12:28 PM Sasha Levin <sashal@kernel.org> wrote:
>>
>> From: Joanne Koong <joannelkoong@gmail.com>
>>
>> [ Upstream commit 7aa6bc3e8766990824f66ca76c19596ce10daf3e ]
>>
>> iomap_adjust_read_range() assumes that the position and length passed in
>> are block-aligned. This is not always the case however, as shown in the
>> syzbot generated case for erofs. This causes too many bytes to be
>> skipped for uptodate blocks, which results in returning the incorrect
>> position and length to read in. If all the blocks are uptodate, this
>> underflows length and returns a position beyond the folio.
>>
>> Fix the calculation to also take into account the block offset when
>> calculating how many bytes can be skipped for uptodate blocks.
>>
>> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
>> Tested-by: syzbot@syzkaller.appspotmail.com
>> Reviewed-by: Brian Foster <bfoster@redhat.com>
>> Reviewed-by: Christoph Hellwig <hch@lst.de>
>> Signed-off-by: Christian Brauner <brauner@kernel.org>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>>
>> LLM Generated explanations, may be completely bogus:
>>
>> Now I have all the information needed for a comprehensive analysis. Let
>> me compile my findings.
>>
>> ---
>
>I don't think any filesystems had repercussions from this. afaik only
>inlined mappings are non-block-aligned and the underflow of length and
>the overflow of position when added together offset each other when
>determining how much to advance the iter for the next iteration. But I
>have no objection to this being backported to stable. I think if this
>gets backported, then we should also backport this one as well
>(https://lore.kernel.org/linux-fsdevel/20251111193658.3495942-3-joannelkoong@gmail.com/).

Sure, I'll grab that one too. Thanks!

-- 
Thanks,
Sasha