[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b7a1884c-77fb-41c7-b660-10d2d5d68aae@sirena.org.uk>
Date: Tue, 18 Jul 2023 18:16:39 +0100
From: Mark Brown <broonie@...nel.org>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>
Cc: Richard Fitzgerald <rf@...nsource.cirrus.com>,
Lee Jones <lee@...nel.org>, alsa-devel@...a-project.org,
patches@...nsource.cirrus.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/11] mfd: wm5110: Update to use maple tree register
cache
On Tue, Jul 18, 2023 at 05:00:35PM +0000, Charles Keepax wrote:
> On Tue, Jul 18, 2023 at 03:42:00PM +0000, Charles Keepax wrote:
> > This one appears to cause me some issues, seems to get the IRQs
> > into a weird state when doing compressed stream stuff. The
> > issue seems to also require commit bfa0b38c1483 ("regmap:
> > maple: Implement block sync for the maple tree cache") to be
> > present. So it definitely seems to relate to the cache sync,
> > but not sure if it is something todo with the device itself,
> > or the maple tree stuff yet.
> Ah... I think I see the regcache_sync sets async=true, but then
> the maple tree code immediately deletes the buffer after calling
> _regmap_raw_write. So its a racy use after free.
> How would we feel about having the maple tree code, clear async
> again?
I was going to say, it must be a maple tree issue. I think we should
push that async down into the rbtree code, that's probably also broken
for other cache types if used in conjunction with slow buses...
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists