Re: [PATCH 18/26] sh: maple: introduce callback_mutex in maple_device

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

Hi Florian,

On Sat, Jul 04, 2026 at 05:48:16PM +0200, Florian Fuchs wrote:
> Hi Dmitry,
> 
> On 03 Jul 22:57, Dmitry Torokhov wrote:
> > The Maple bus core invokes client callbacks asynchronously from a
> > workqueue (maple_dma_handler). If a device is removed (or closed) while
> > a callback is in flight, it can lead to UAF bugs if the driver's private
> > data is freed.
> > 
> > Introduce callback_mutex in struct maple_device to synchronize
> > callback registration/modification and callback invocation.

...

> 
> Thank you so much for your efforts. I can confirm sashikos finding in my
> test (that I saw later),

Thank you for giving the series a spin!

> that this patch hangs the bus if a VMU memcard
> is inserted. So that the peripherals don't work anymore after insertion
> of the memcard. With a last log like:
> Dreamcast_visual_memory 3:01.E: VMU at (3, 1) is busy

Yes, indeed, I overlooked the vmu-flash use case. I will introduce a
lockless way of setting up the callback and a wrapper that takes the
lock and that should solve the deadlock in vmu-flash driver.

I wonder if you had a chance top try out the preceding patches and if
they worked for you? If they do and you can add your tested-by I should
be able to pick up at least the input patches that do not need maple
core changes...

Thanks.

-- 
Dmitry