On Tue, 14 Sep 2021 19:14:15 +0800, yangerkun wrote:
> Or the ls for ext4 dir can run into a deadloop since info->last_pos !=
> ctx->pos which will reset the world and start read the entry which has
> already got before. Details see below:
>
> 1. a dx_dir which has 3 block, block 0 as dx_root block, block 1/2 as
> leaf block which own the ext4_dir_entry_2
> 2. block 1 read ok and call_filldir which will fill the dirent and update
> the ctx->pos
> 3. block 2 read fail, but we has already fill some dirent, so we will
> return back to userspace will a positive return val(see ksys_getdents64)
> 4. the second ext4_dx_readdir will reset the world since info->last_pos
> != ctx->pos, and will also init the curr_hash which pos to block 1
> 5. So we will read block1 too, and once block2 still read fail, we can
> only fill one dirent because the hash of the entry in block1(besides
> the last one) won't greater than curr_hash
> 6. this time, we forget update last_pos too since the read for block2
> will fail, and since we has got the one entry, ksys_getdents64 can
> return success
> 7. Latter we will trapped in a loop with step 4~6
>
> [...]
I rewrote the patch summary and the first paragraph to improve the
English:
ext4: fix potential infinite loop in ext4_dx_readdir()
When ext4_htree_fill_tree() fails, ext4_dx_readdir() can run into an
infinite loop since if info->last_pos != ctx->pos this will reset the
directory scan and reread the failing entry. For example:
Applied, thanks!
[1/1] ext4: update last_pos for the case ext4_htree_fill_tree return fail
commit: 42cb447410d024e9d54139ae9c21ea132a8c384c
Best regards,
--
Theodore Ts'o <tytso@xxxxxxx>
