On Sat, Apr 13, 2024 at 04:43:18PM +0200, Nam Cao wrote: > > I have zero knowledge about file system, but I think it's an integer > overflow problem. The calculation of "dlimit" overflow and dlimit wraps > around, this leads to wrong comparison later on. > > I guess that explains why your bisect and Conor's bisect results are > strange: the bug has been here for quite some time, but it only appears > when "dlimit" happens to overflow. So the problem with that theory is that for that to be the case buf_size would have to be invalid, and it's unclear how could have happened. We can try to test that theory by putting something like this at the beginning of ext4_search_dir(): if (buf_size < 0 || buf_size > dir->i_sb->s_blocksize) { /* should never happen */ EXT4_ERROR_INODE(dir, "insane buf_size %d", buf_size); WARN_ON(1) return -EFSCORRUPTED; } Just to confirm, this file system is not one that has been fuzzed or is being dynamically modified while mounted, right? Even if that were the case, looking at the stack trace, I don't see how this could have happened. (I could imagine some scenario involving inline directoreis and fuzzed or dynamically modified file systems might be a potential problem=, or at least one that involve much more careful; code review, since that code is not as battle tested as other parts of ext4; but the stack trace reported at the beginning of this thread doesn't seem to indicate that inline directories were involved.) - Ted