linux-kernel - Re: [PATCH] ocfs2: fix circular locking dependency in ocfs2_acquire

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0a2eab22-95ee-4172-9052-aefcbc5bf227@linux.alibaba.com>
Date: Tue, 20 Jan 2026 09:37:17 +0800
From: Joseph Qi <joseph.qi@...ux.alibaba.com>
To: Szymon Wilczek <swilczek.lx@...il.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,
 akpm <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ocfs2: fix circular locking dependency in
 ocfs2_acquire_dquot



On 1/9/26 10:02 AM, Szymon Wilczek wrote:
> 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
> 

Ummm... When sync and release also is
  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.
> 
>From the report link, start_trans is called during
ocfs2_shutdown_local_alloc(), but ocfs2_disable_quotas() is fnished now.
So how it happens?

Thanks,
Joseph

> 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