linux-kernel - Re: [syzbot] [ext4?] possible deadlock in ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250826034607.5604-1-hdanton@sina.com>
Date: Tue, 26 Aug 2025 11:46:06 +0800
From: Hillf Danton <hdanton@...a.com>
To: "Theodore Ts'o" <tytso@....edu>
Cc: syzbot <syzbot+c5c9c223a721d7353490@...kaller.appspotmail.com>,
	linux-kernel@...r.kernel.org,
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ext4?] possible deadlock in ext4_truncate (2)

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