Re: [syzbot] [ext4?] possible deadlock in ext4_truncate (2)

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

On Mon, Aug 25, 2025 at 06:41:52PM +0800, Hillf Danton wrote:
> > syzbot found the following issue on:
> > 
> > dashboard link: https://syzkaller.appspot.com/bug?extid=c5c9c223a721d7353490
> 
> --- x/fs/ext4/inode.c
> +++ y/fs/ext4/inode.c
> @@ -4573,6 +4573,7 @@ int ext4_truncate(struct inode *inode)
>  	struct ext4_inode_info *ei = EXT4_I(inode);
>  	unsigned int credits;
>  	int err = 0, err2;
> +	static int subclass = 0;
>  	handle_t *handle;
>  	struct address_space *mapping = inode->i_mapping;
>  
> @@ -4636,7 +4637,7 @@ int ext4_truncate(struct inode *inode)
>  	ext4_fc_track_inode(handle, inode);
>  	ext4_check_map_extents_env(inode);
>  
> -	down_write(&EXT4_I(inode)->i_data_sem);
> +	down_write_nested(&EXT4_I(inode)->i_data_sem, subclass++);
>  	ext4_discard_preallocations(inode);
>  
>  	if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))

This isn't the right way to fix these sorts of Syzbot failures.  First
of all, we already have subclasses defined.  Secondly, using a
continuously incrementing subclasses will chew up a huge amount of
memory until lockdep gives a warning that the kernel exceeded a fixed
limit, which (a) disables the lockdep checking, so it's counter
productive, (b) will trigger a syzbot failure, so it doesn't even shut
up the syzbot noise.

The combination of maliciously corrupted/fuzzed file systems, and a
deadlock warning, is something that I just ignore.  Your patch is an
attempt to do this programmtically, if it worked (and for better or
for worse, it doesn't).  If there was a way I could tell syzbot ---
you're just wasting everyone's time, shut up with this combination,
but there isn't.  So when I have time, I'll recategorize these reports
to priority low, which is a signal that it's been triaged, and it's
syzbot noise.

Cheers,

						- Ted