[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJRoVwgxBKXcMSU-CMH8gC1TLnWFdMHiaFGOyFrkDZqzfpN8Ng@mail.gmail.com>
Date: Fri, 9 Jan 2026 03:02:27 +0100
From: Szymon Wilczek <swilczek.lx@...il.com>
To: Joseph Qi <joseph.qi@...ux.alibaba.com>
Cc: ocfs2-devel@...ts.linux.dev, mark@...heh.com, jlbec@...lplan.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
syzbot+51244a05705883616c95@...kaller.appspotmail.com
Subject: Re: [PATCH] ocfs2: fix circular locking dependency in ocfs2_acquire_dquot
Hi Joseph,
Thank you for pointing to the designed order in quota_global.c.
I looked at the locking documentation. I see that
"Acquire dquot for the first time" specifies:
ocfs2_lock_global_qf -> start_trans
However, I believe the v2 patch is still necessary because lockdep
detected a real circular dependency:
sb_internal -> sysfile_lock_key -> ip_alloc_sem
Since ocfs2_lock_global_qf takes ip_alloc_sem, and start_trans takes
sb_internal (via sb_start_intwrite), the documented order inverts the
chain above, creating an ABBA deadlock with freeze/dismount paths.
The designed order may have been correct before sb_start_intwrite
became part of ocfs2_start_trans, but now this sequence conflicts
with the VFS freeze mechanism.
My patch ensures sb_internal is acquired before ip_alloc_sem, which
matches the expected freeze ordering. Perhaps the documentation in
quota_global.c should be updated to reflect this change?
If you see a problem with this approach, I'm happy to adjust.
What would you suggest?
Thanks,
Szymon
Powered by blists - more mailing lists