From: Thomas Gleixner <tglx@linutronix.de>
To: Johan Hovold <johan@kernel.org>
Cc: Johan Hovold <johan+linaro@kernel.org>,
Marc Zyngier <maz@kernel.org>,
x86@kernel.org, platform-driver-x86@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org, Hsin-Yi Wang <hsinyi@chromium.org>,
Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Subject: Re: [PATCH v4 06/19] irqdomain: Drop revmap mutex
Date: Mon, 06 Feb 2023 14:09:02 +0100 [thread overview]
Message-ID: <87zg9rx7o1.ffs@tglx> (raw)
In-Reply-To: <Y8fv3KWoxmaykrP6@hovoldconsulting.com>
On Wed, Jan 18 2023 at 14:10, Johan Hovold wrote:
> On Wed, Jan 18, 2023 at 02:05:29PM +0100, Thomas Gleixner wrote:
>> You can do this in a two step approach.
>>
>> 1) Add the new locking and ensure that the lock is held when
>> the functions are called
>
> But the new locking has nothing to do with these functions. They are
> added because they fix various races elsewhere. Adding lockdep
> assertions in unrelated function as part of those fixes doesn't really
> make much sense.
Seriously? The point is that revmap_mutex is not protecting against any
of the races which you are trying to protect against. Ergo, any callsite
which does not hold the irqdomain mutex is part of the problem you are
trying to solve, no?
The removal of the revmap_mutex becomes possible due to the overall
protection scheme rework _after_ you established that all callers hold
the irqdomain mutex.
Thanks,
tglx
next prev parent reply other threads:[~2023-02-06 13:09 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 13:50 [PATCH v4 00/19] irqdomain: fix mapping race and clean up locking Johan Hovold
2023-01-16 13:50 ` [PATCH v4 01/19] irqdomain: Drop bogus fwspec-mapping error handling Johan Hovold
2023-01-17 21:17 ` Thomas Gleixner
2023-01-16 13:50 ` [PATCH v4 02/19] irqdomain: Drop dead domain-name assignment Johan Hovold
2023-01-17 21:18 ` Thomas Gleixner
2023-01-16 13:50 ` [PATCH v4 03/19] irqdomain: Drop leftover brackets Johan Hovold
2023-01-17 21:19 ` Thomas Gleixner
2023-01-18 9:05 ` Johan Hovold
2023-01-16 13:50 ` [PATCH v4 04/19] irqdomain: Fix association race Johan Hovold
2023-01-17 21:20 ` Thomas Gleixner
2023-01-16 13:50 ` [PATCH v4 05/19] irqdomain: Fix disassociation race Johan Hovold
2023-01-16 13:50 ` [PATCH v4 06/19] irqdomain: Drop revmap mutex Johan Hovold
2023-01-17 21:23 ` Thomas Gleixner
2023-01-18 9:22 ` Johan Hovold
2023-01-18 13:05 ` Thomas Gleixner
2023-01-18 13:10 ` Johan Hovold
2023-02-06 13:09 ` Thomas Gleixner [this message]
2023-02-06 17:10 ` Johan Hovold
2023-01-16 13:50 ` [PATCH v4 07/19] irqdomain: Look for existing mapping only once Johan Hovold
2023-01-17 21:34 ` Thomas Gleixner
2023-01-18 9:26 ` Johan Hovold
2023-02-09 13:00 ` Johan Hovold
2023-01-16 13:50 ` [PATCH v4 08/19] irqdomain: Refactor __irq_domain_alloc_irqs() Johan Hovold
2023-01-17 21:34 ` Thomas Gleixner
2023-01-18 9:30 ` Johan Hovold
2023-01-16 13:50 ` [PATCH v4 09/19] irqdomain: Fix mapping-creation race Johan Hovold
2023-01-17 21:39 ` Thomas Gleixner
2023-01-18 9:40 ` Johan Hovold
2023-02-09 13:08 ` Johan Hovold
2023-01-16 13:50 ` [PATCH v4 10/19] irqdomain: Clean up irq_domain_push/pop_irq() Johan Hovold
2023-01-16 13:50 ` [PATCH v4 11/19] x86/ioapic: Use irq_domain_create_hierarchy() Johan Hovold
2023-01-17 21:41 ` Thomas Gleixner
2023-01-18 10:31 ` Johan Hovold
2023-01-16 13:50 ` [PATCH v4 12/19] x86/apic: " Johan Hovold
2023-01-16 13:50 ` [PATCH v4 13/19] irqchip/alpine-msi: Use irq_domain_add_hierarchy() Johan Hovold
2023-01-16 13:50 ` [PATCH v4 14/19] irqchip/gic-v2m: Use irq_domain_create_hierarchy() Johan Hovold
2023-01-16 13:50 ` [PATCH v4 15/19] irqchip/gic-v3-its: " Johan Hovold
2023-01-16 13:50 ` [PATCH v4 16/19] irqchip/gic-v3-mbi: " Johan Hovold
2023-01-16 13:50 ` [PATCH v4 17/19] irqchip/loongson-pch-msi: " Johan Hovold
2023-01-16 13:50 ` [PATCH v4 18/19] irqchip/mvebu-odmi: " Johan Hovold
2023-01-16 13:50 ` [PATCH v4 19/19] irqdomain: Switch to per-domain locking Johan Hovold
2023-01-17 21:50 ` Thomas Gleixner
2023-01-18 9:51 ` Johan Hovold
2023-01-18 13:09 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zg9rx7o1.ffs@tglx \
--to=tglx@linutronix.de \
--cc=hsinyi@chromium.org \
--cc=johan+linaro@kernel.org \
--cc=johan@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=mark-pk.tsai@mediatek.com \
--cc=maz@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox