On Sun, Apr 19, 2020 at 07:26:53AM +0530, Ritesh Harjani wrote: > ++ mailing list. > Sorry somehow it got dropped. > > > On 4/19/20 7:21 AM, Ritesh Harjani wrote: > > Hello Murphy, > > > > I guess the patch to fix this issue was recently submitted. > > Could you please test your reproducer, xfstest and ltp > > tests on below patch too. And let me know if we can add your Tested-by: > > > > https://patchwork.ozlabs.org/project/linux-ext4/patch/1a2dc8f198e1225ddd40833de76b60c7ee20d22d.1587024137.git.riteshh@xxxxxxxxxxxxx/ His reproducer is still failing with your patch. In order to for his reproducer to succeed, we need to constrain lblk and last_lblk more strictly than what is done in: [PATCHv2 1/1] ext4: fix overflow case for map.m_len in ext4_iomap_begin_* His patch does fix the issue. ext4_map_block() is returning EFSCORRUPTED when lblk is EXT4_MAX_LOGICAL_BLOCK, which is why he's constraining lblk to EXT4_MAX_LOGICAL_BLOCK. I haven't looked into this more closely yet, but it looks we have some overflow/wraparound issue when lblk is 0xFFFFFFFF. Which might mean that in fact EXT4_MAX_LOGICAL_BLOCK might need to be 0xFFFFFFFE, or we need to look very closely our code paths to make sure the right thing happes when we call ext4_map_blocks() with m_lblk == 0xFFFFFFFF and m_len == 1. I think we need to take his patch, and make a simialr change to ext4_iomap_begin(). Ritesh, do you agree? - Ted
