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

Message-ID: <0b2fa71f1ccd49d66ca02b6c44ba8fe2135e9b6f.camel@svanheule.net>
Date: Thu, 16 Oct 2025 10:46:33 +0200
From: Sander Vanheule <sander@...nheule.net>
To: Mark Brown <broonie@...nel.org>
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

Hi Mark,

On Thu, 2025-01-09 at 20:11 +0000, Mark Brown wrote:
> On Thu, Jan 09, 2025 at 07:02:55PM +0100, Sander Vanheule wrote:
> > The flat regcache will always assume the data in the cache is valid.
> > Since the cache takes priority over hardware values, this may shadow the
> > actual state of the device. This is not the case with REGCACHE_RBTREE
> > for example, which makes these implementation behave differently.
> 
> This is causing spurious events to be generated by the audio drivers on
> Pine64 Plus, the audio drivers for that do use the flat cache (see
> sound/soc/sunxi):
> 
>    https://lava.sirena.org.uk/scheduler/job/1056879#L1897
> 
> I haven't investigated yet but I suspect this is going to have been
> triggered by the change from assuming all registers default to 0 if not
> otherwise specified to reading back from the hardware if the first
> access is a read.  That does seem a bit like a driver bug (I'm not clear
> on the precise mechanism apart from anything else) but I worry that
> it'll be a widespread one where things do read/modify/write cycles.
> There may also be initialisation from suspend issues where we stop
> resetting values after resume.  We do need a plan for this, possibly we
> should default to the old behaviour.
> 
> It's definitely too late in the release cycle to apply the change in any
> case.

Apologies for the delay, it took me some time to get back to this properly.

Would you be open to providing a new type of flat cache with sparse
initalisation (e.g. REGCACHE_FLAT_SPARSE) to provide the behavior provided by
this patches? Most of the code could be shared with REGCACHE_FLAT.

REGCACHE_FLAT and REGCACHE_FLAT_SPARSE would both maintain the cache validity as
in this patch. On a read, _FLAT_SPARSE would return -ENOENT on an invalid cache
entry. _FLAT would then always return 0 and the (zero-initialized) value,
ignoring the cache validity and maintaining the behavior drivers may currently
rely on.

If you would like existing drivers to transition to REGCACHE_FLAT_SPARSE, I
could also add a deprecation warning for users of REGCACHE_FLAT.

I can also just send a patch series, if that helps.

Best,
Sander