Re: [PATCH] ocfs2: fix lock acquisition order in refcounttree
Tetsuo Handa <[email protected]>
| Newsgroups | dev.linux.lists.ocfs2-devel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 2026/04/26 6:26, Andrew Morton wrote: > But ocfs2_reflink() does > > down_write(&OCFS2_I(inode)->ip_xattr_sem); > down_write(&OCFS2_I(inode)->ip_alloc_sem); > > Yes, we know. We are waiting for response from OCFS2 people on the below message. -------- Forwarded Message -------- Message-ID: <[email protected]> Date: Mon, 21 Jul 2025 19:40:58 +0900 Subject: Re: [PATCH] ocfs2: fix lock acquisition order in refcounttree From: Tetsuo Handa <[email protected]> To: Diogo Jahchan Koike <[email protected]>, Mark Fasheh <[email protected]>, Joel Becker <[email protected]>, Joseph Qi <[email protected]>, [email protected] Cc: [email protected], [email protected] References: <[email protected]> <[email protected]> <[email protected]> In-Reply-To: <[email protected]> On 2025/07/18 22:54, Tetsuo Handa wrote: > On 2025/07/15 11:51, Tetsuo Handa wrote: >> On 2025/07/15 7:15, Diogo Jahchan Koike wrote: >>> Acquiring the locks in refcounttree should follow >>> the ip_alloc --> ip_xattr ordering, as done by multiple >>> code paths in ocfs2; otherwise, we risk an ABBA deadlock >>> (i.e in the start transaction path). >> >> I noticed that ocfs2_reflink() in the same file wants similar change. >> >> down_write(&OCFS2_I(inode)->ip_xattr_sem); >> down_write(&OCFS2_I(inode)->ip_alloc_sem); >> error = __ocfs2_reflink(old_dentry, old_bh, >> new_orphan_inode, preserve); >> up_write(&OCFS2_I(inode)->ip_alloc_sem); >> up_write(&OCFS2_I(inode)->ip_xattr_sem); >> > > Moreover, I noticed that e.g. ocfs2_xattr_set_handle() firstly acquires > ip_xatr_sem and then ocfs2_xattr_ibody_find() might acquire ip_alloc_sem. > > Diogo, where do you see the ip_alloc --> ip_xattr ordering? > > Unless we unify to either ip_alloc --> ip_xattr ordering or > ip_xattr --> ip_alloc ordering (or replace ip_xattr with ip_alloc), > this patch simply changes the location of lockdep warning? > Since I couldn't find direct ip_alloc --> ip_xattr ordering, I tried effectively replacing ip_xattr with ip_alloc at https://lkml.kernel.org/r/[email protected] and got sb_internal --> ip_alloc v.s. ip_alloc --> sb_internal ordering problem, as with other lockdep reports in ocfs2 subsystem at https://syzkaller.appspot.com/upstream/s/ocfs2 . In the team network driver, this kind of ordering issues has been addressed by simplifying locking dependency at https://lkml.kernel.org/r/[email protected] . ocfs2 developers, can you simplify locking dependency in ocfs2, by killing several locks and reordering the locks?