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?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.