Re: [PATCH v2 2/4] irqdomain: Fix mapping-creation race

[Johan Hovold <johan@kernel.org>]

Hi Marc,

On Thu, Sep 15, 2022 at 09:54:25AM +0100, Marc Zyngier wrote:
> Johan,
> 
> On Thu, 01 Sep 2022 15:28:14 +0100,
> Johan Hovold <johan+linaro@kernel.org> wrote:
> > 
> > Parallel probing (e.g. due to asynchronous probing) of devices that share
> > interrupts can currently result in two mappings for the same hardware
> > interrupt to be created.
> > 
> > Add a serialising mapping mutex so that looking for an existing mapping
> > before creating a new one is done atomically.
> > 
> > Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
> > Fixes: b62b2cf5759b ("irqdomain: Fix handling of type settings for existing mappings")
> > Cc: Dmitry Torokhov <dtor@chromium.org>
> > Cc: Jon Hunter <jonathanh@nvidia.com>
> > Link: https://lore.kernel.org/r/YuJXMHoT4ijUxnRb@hovoldconsulting.com
> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org>

> I must confess I have a hard time figuring out the semantic difference
> between map_mutex and revmap_mutex. or rather, what is the use of
> revmap_mutex once map_mutex is taken. They fundamentally overlap, and
> I have the feeling one should eventually replace the other.
> 
> If anything, you should absolutely define/document how these two locks
> interact.

Sorry about the late follow-up on this. I meant to revisit this much
sooner, but couldn't seem to find the time until this week.

I just sent you a v3 which reworks the irqdomain locking and fixes the
race in the process. In the end the irq_domain_mutex is only used for
managing the irq_domain_list, while domain operations use per-domain
(hierarchy) locking.

Johan