Re: [PATCH] xfs: take hm->lock in xfs_ioc_health_monitor() before insert
From: Shigeru Yoshida
Date: Thu Sep 10 2026 - 11:00:49 EST
Carlos Maiolino <cem@xxxxxxxxxx> writes:
> On Wed, Sep 09, 2026 at 10:07:56PM -0700, Christoph Hellwig wrote:
>> On Sun, Sep 06, 2026 at 09:51:50PM -0700, Darrick J. Wong wrote:
>> > On Sun, Sep 06, 2026 at 08:16:29PM +0530, Deepanshu Kartikey wrote:
>> > > __xfs_healthmon_insert() asserts that hm->lock is held
>> > > (lockdep_assert_held), but xfs_ioc_health_monitor() called it right
>> > > after allocating hm, before ever taking the lock, triggering a
>> > > lockdep warning.
>> > >
>> > > Take hm->lock around the call.
>> > >
>> > > Fixes: b3a289a2a9397 ("xfs: create event queuing, formatting, and discovery infrastructure")
>> > > Reported-by: syzbot+ccdf3469f5f653bff7ac@xxxxxxxxxxxxxxxxxxxxxxxxx
>> > > Closes: https://syzkaller.appspot.com/bug?extid=ccdf3469f5f653bff7ac
>> > > Signed-off-by: Deepanshu Kartikey <kartikey406@xxxxxxxxx>
>> >
>> > Heh, I added a patch just like this one to my own tree.
>> > Reviewed-by: "Darrick J. Wong" <djwong@xxxxxxxxxx>
>>
>> Can we get this queued up ASAP? It's also causing a lot of failures in
>> our zoned XFS CI.
>>
>>
>
> Done. It's in for-next already. Not sure if I'll manage to push the
> attrs fsblock fix yet this -rc, but this one will go to Linus on
> Saturday
I noticed that the second mutex operation in this commit was
accidentally left as mutex_lock() instead of mutex_unlock(). I've
sent a fix as a separate patch ("xfs: fix double mutex_lock() call
in xfs_ioc_health_monitor()"). Feel free to use it if it helps.
Thanks,
Shigeru