Lockdep reports a possible deadlock involving ip_alloc_sem,
j_trans_barrier, and ip_xattr_sem:

  Chain exists of:
    &oi->ip_alloc_sem --> &journal->j_trans_barrier --> &oi->ip_xattr_sem

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&oi->ip_xattr_sem);
                                lock(&journal->j_trans_barrier);
                                lock(&oi->ip_xattr_sem);
   lock(&oi->ip_alloc_sem);

  *** DEADLOCK ***

ocfs2_reflink() and ocfs2_try_remove_refcount_tree() acquire
ip_xattr_sem before ip_alloc_sem.  This is the reverse of the
established system-wide ordering where ip_alloc_sem is outer:

  - Write paths (e.g. ocfs2_write_begin_nolock) hold ip_alloc_sem
    and call ocfs2_start_trans(), which takes j_trans_barrier.

  - ocfs2_mknod() calls ocfs2_start_trans() (j_trans_barrier) then
    ocfs2_init_acl(), which takes ip_xattr_sem on the parent dir.

Fix by swapping the lock order in both functions to acquire
ip_alloc_sem before ip_xattr_sem, consistent with the rest of the
codebase.

Fixes: 09bf27a00020 ("ocfs2: Implement ocfs2_reflink.")
Fixes: 8b2c0dba5159 ("ocfs2: Call refcount tree remove process properly.")
Reported-by: syzbot+e42eae29bba35810f43c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e42eae29bba35810f43c
Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
---
 fs/ocfs2/refcounttree.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
index d9f22b4a2654..c734ce295bf0 100644
--- a/fs/ocfs2/refcounttree.c
+++ b/fs/ocfs2/refcounttree.c
@@ -955,8 +955,8 @@ int ocfs2_try_remove_refcount_tree(struct inode *inode,
 	struct ocfs2_inode_info *oi = OCFS2_I(inode);
 	struct ocfs2_dinode *di = (struct ocfs2_dinode *)di_bh->b_data;
 
-	down_write(&oi->ip_xattr_sem);
 	down_write(&oi->ip_alloc_sem);
+	down_write(&oi->ip_xattr_sem);
 
 	if (oi->ip_clusters)
 		goto out;
@@ -972,8 +972,8 @@ int ocfs2_try_remove_refcount_tree(struct inode *inode,
 	if (ret)
 		mlog_errno(ret);
 out:
-	up_write(&oi->ip_alloc_sem);
 	up_write(&oi->ip_xattr_sem);
+	up_write(&oi->ip_alloc_sem);
 	return 0;
 }
 
@@ -4292,12 +4292,12 @@ static int ocfs2_reflink(struct dentry *old_dentry, struct inode *dir,
 		goto out;
 	}
 
-	down_write(&OCFS2_I(inode)->ip_xattr_sem);
 	down_write(&OCFS2_I(inode)->ip_alloc_sem);
+	down_write(&OCFS2_I(inode)->ip_xattr_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);
+	up_write(&OCFS2_I(inode)->ip_alloc_sem);
 
 	ocfs2_inode_unlock(inode, 1);
 	ocfs2_rw_unlock(inode, 1);
-- 
2.39.3

On Fri, 31 Jul 2026 19:34:25 +0800 Joseph Qi <joseph.qi@linux.alibaba.com> wrote:

> Lockdep reports a possible deadlock involving ip_alloc_sem,
> j_trans_barrier, and ip_xattr_sem:
> 

Cool.

Sashiko said a couple of things:
	https://sashiko.dev/#/patchset/20260731113425.4130293-1-joseph.qi@linux.alibaba.com

> Fix by swapping the lock order in both functions to acquire
> ip_alloc_sem before ip_xattr_sem, consistent with the rest of the
> codebase.
> 
> Fixes: 09bf27a00020 ("ocfs2: Implement ocfs2_reflink.")
> Fixes: 8b2c0dba5159 ("ocfs2: Call refcount tree remove process properly.")

Should we backport this into -stable kernels?

On 8/1/26 2:21 AM, Andrew Morton wrote:
> On Fri, 31 Jul 2026 19:34:25 +0800 Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> 
>> Lockdep reports a possible deadlock involving ip_alloc_sem,
>> j_trans_barrier, and ip_xattr_sem:
>>
> 
> Cool.
> 
> Sashiko said a couple of things:
> 	https://sashiko.dev/#/patchset/20260731113425.4130293-1-joseph.qi@linux.alibaba.com
> 

The issue sashiko has found is real.

After a deep look, I think it can be fixed by breaking j_trans_barrier
-> ip_xattr_sem instread of ip_xattr_sem -> ip_alloc_sem, which is
actually posted by Krystian Kaniewski in thread (I've ACKed):
https://lore.kernel.org/ocfs2-devel/f98ff905-74bf-4017-a673-fd28f30f11d3@linux.alibaba.com/T/#t

So please drop this patch and let's keep the existing order for
ip_xattr_sem -> ip_alloc_sem.

Thanks,
Joseph


>> Fix by swapping the lock order in both functions to acquire
>> ip_alloc_sem before ip_xattr_sem, consistent with the rest of the
>> codebase.
>>
>> Fixes: 09bf27a00020 ("ocfs2: Implement ocfs2_reflink.")
>> Fixes: 8b2c0dba5159 ("ocfs2: Call refcount tree remove process properly.")
> 
> Should we backport this into -stable kernels?
>

On 8/1/26 2:21 AM, Andrew Morton wrote:
> On Fri, 31 Jul 2026 19:34:25 +0800 Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
> 
>> Lockdep reports a possible deadlock involving ip_alloc_sem,
>> j_trans_barrier, and ip_xattr_sem:
>>
> 
> Cool.
> 
> Sashiko said a couple of things:
> 	https://sashiko.dev/#/patchset/20260731113425.4130293-1-joseph.qi@linux.alibaba.com
> 

Thanks, I'll take a deep look for the sashiko review comments.

>> Fix by swapping the lock order in both functions to acquire
>> ip_alloc_sem before ip_xattr_sem, consistent with the rest of the
>> codebase.
>>
>> Fixes: 09bf27a00020 ("ocfs2: Implement ocfs2_reflink.")
>> Fixes: 8b2c0dba5159 ("ocfs2: Call refcount tree remove process properly.")
> 
> Should we backport this into -stable kernels?
> 
Yes, I think it deserves.
Sorry for missing the cc stable tag.

Thanks,
Joseph