linux-kernel - Re: [PATCH] ocfs2: fix deadlock in ocfs2_get_system_file

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: <20250424194639.GH2023217@ZenIV>
Date: Thu, 24 Apr 2025 20:46:39 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Kevin Paul Reddy Janagari <kevinpaul468@...il.com>
Cc: mark@...heh.com, jlbec@...lplan.org, joseph.qi@...ux.alibaba.com,
	ocfs2-devel@....oracle.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ocfs2: fix deadlock in ocfs2_get_system_file_inode

On Thu, Apr 24, 2025 at 09:59:11PM +0530, Kevin Paul Reddy Janagari wrote:
> This issue can be resolved by making the down_read -> down_read_try
> in the ocfs2_read_virt_blocks.

ITYM "can be papered over by..."; *IF* fill_super() is the only place where
these are taken in such order, this is strictly worse than the current
situation - you are taking a false positive from lockdep (fill_super is
not going to have any other threads accessing the same fs instance) and
adding random failures and syslog spew where none existed.

NAK in that form; it _may_ serve as a stopgap if fill_super is not
the only place where we do it in such order, but even then we need
to deal with the problem properly.