Received-SPF: pass (google.com: domain of linux-ext4+bounces-2260-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Thu, 2 May 2024 12:33:41 +0200
From: Jan Kara <jack@suse.cz>
To: syzbot <syzbot+dd43bd0f7474512edc47@syzkaller.appspotmail.com>
Cc: adilger.kernel@dilger.ca, jack@suse.cz, libaokun1@huawei.com,
	linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	nathan@kernel.org, ndesaulniers@google.com, ritesh.list@gmail.com,
	syzkaller-bugs@googlegroups.com, trix@redhat.com, tytso@mit.edu
Subject: Re: [syzbot] [ext4?] WARNING in mb_cache_destroy
Message-ID: <20240502103341.t53u6ya7ujbzkkxo@quack3>
References: <00000000000072c6ba06174b30b7@google.com>
 <0000000000003bf5be061751ae70@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0000000000003bf5be061751ae70@google.com>

On Tue 30-04-24 08:04:03, syzbot wrote:
> syzbot has bisected this issue to:
> 
> commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3
> Author: Baokun Li <libaokun1@huawei.com>
> Date:   Thu Jun 16 02:13:56 2022 +0000
> 
>     ext4: fix use-after-free in ext4_xattr_set_entry

So I'm not sure the bisect is correct since the change is looking harmless.
But it is sufficiently related that there indeed may be some relationship.
Anyway, the kernel log has:

[   44.932900][ T1063] EXT4-fs warning (device loop0): ext4_evict_inode:297: xattr delete (err -12)
[   44.943316][ T1063] EXT4-fs (loop0): unmounting filesystem.
[   44.949531][ T1063] ------------[ cut here ]------------
[   44.955050][ T1063] WARNING: CPU: 0 PID: 1063 at fs/mbcache.c:409 mb_cache_destroy+0xda/0x110

So ext4_xattr_delete_inode() called when removing inode has failed with
ENOMEM and later mb_cache_destroy() was eventually complaining about having
mbcache entry with increased refcount. So likely some error cleanup path is
forgetting to drop mbcache entry reference somewhere but at this point I
cannot find where. We'll likely need to play with the reproducer to debug
that. Baokun, any chance for looking into this?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR