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

[Hillf Danton <hdanton@sina.com>]

On Mon, 25 Aug 2025 09:37:43 -0400 Theodore Ts'o wrote:
> 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

It is simpler to fix it than create it wrt surviving the syzbot test [1].

[1] https://lore.kernel.org/lkml/68ad1ca1.050a0220.37038e.009e.GAE@google.com/

> 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.
> 
Frankly there is much noise you can safely ignore, like what LT made.

> Cheers,
> 
>						- Ted