linux-kernel - Re: [PATCH v3] regmap: add cache validity to REGCACHE

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: <26abcd6d-ae3a-4ef8-890a-9b209c3c8e03@sirena.org.uk>
Date: Fri, 17 Oct 2025 14:56:10 +0100
From: Mark Brown <broonie@...nel.org>
To: Sander Vanheule <sander@...nheule.net>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] regmap: add cache validity to REGCACHE_FLAT

On Thu, Oct 16, 2025 at 10:49:40PM +0200, Sander Vanheule wrote:

> The proposed patch also won't perform any allocations outside of the regmap
> initialization. There is the additional overhead of checking a bitmap, yes, but
> that's probably not a huge problem if the main issue are the allocations?

The allocations are more of an issue, but they're both potential issues.
Note that you can also avoid allocations with rbtree or maple by
prefilling the cache, it's just harder to absolutely guarantee that you
got everything right.

> A number of REGCACHE_FLAT users provide only num_reg_defaults_raw. That looked
> strange to me, because why would a user provide a buffer size, but no buffer?
> This even conflicts with the documentation, as "Number of elements in
> reg_defaults_raw" doesn't make sense if reg_defaults_raw is NULL. As you are
> probably aware, this configuration causes the regmap init to read registers from
> the device to generate a default state, which is then used to fill the flat
> cache. So this effectively replaces the (invalid) zero-initialization. What
> feels problematic to me, is that only the flat cache requires this sort of
> "hack" for it to contain values that correctly reflect the hardware state.

Yes, that's absoutely a hack for the lack of sparseness in the flat
cache.

> Some quick grepping turned up 35 drivers which use REGCACHE_FLAT without any
> cache initialization (see below), thus defaulting to the all-zero cache. This
> includes the driver I think you found issues with on the pine64: sun8i-codec.c
> If this driver (accidentally) relies on the zero-initialization, I would expect
> the spurious interrupts to also pop up when switching to a maple cache, or when
> using the num_reg_defaults_raw workaround.

Yes, that driver is relying on the current behaviour - I'd expect at
least some of the other drivers are too.  

There's two separate things here, there's what the driver you're working
on should do (which is to use a maple tree cache from the sounds of it)
and there's potential improvements to the flat cache, or adding a new
sparse flat cache.

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