Re: riscv32 EXT4 splat, 6.8 regression?

["Theodore Ts'o" <tytso@mit.edu>]

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