linux-kernel - Re: [PATCH RFC] regmap: maple: Switch to use irq-safe locking

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <cd4c01db-961c-4afb-8b8a-8fc6efb91234@sirena.org.uk>
Date: Sat, 17 Aug 2024 00:35:05 +0100
From: Mark Brown <broonie@...nel.org>
To: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Heiko Stübner <heiko@...ech.de>,
	Andy Yan <andy.yan@...k-chips.com>, kernel@...labora.com,
	linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH RFC] regmap: maple: Switch to use irq-safe locking

On Fri, Aug 16, 2024 at 11:11:27PM +0300, Cristian Ciocaltea wrote:

> The deadlock scenario indicated by lockdep actually points to the lock
> acquired by regcache_maple_exit(), which has been triggered during module
> unload operation, and the lock acquired by regcache_maple_write(), in the
> context of vop2_plane_atomic_update() called within the DRM stack.

So still within the interrupt context then, and due to the fact that the
register has not been accessed outside of interrupt context.  Reading or
writing any cached registers used in atomic context on init should do
that and avoid the issue I expect.  In general if you're going to use a
sparse cache you should ensure it's populated during init, like I said
in the prior mail providing defaults is the standard way to do that but
just an access should also work.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)