From: Thomas Gleixner <tglx@linutronix.de>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org,
Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH 0/5] Make it easier to use nested locking for interrupt descriptors
Date: Mon, 03 Feb 2025 20:40:46 +0100 [thread overview]
Message-ID: <87r04eolz5.ffs@tglx> (raw)
In-Reply-To: <20250203175939.3133477-1-bvanassche@acm.org>
Bart!
On Mon, Feb 03 2025 at 09:59, Bart Van Assche wrote:
> The number of irq_set_lockdep_class() calls and IRQ_GC_INIT_NESTED_LOCK
> occurrences in the kernel tree shows that nested locking is common for
> interrupt descriptors.
I can see why you think it's cumbersome to nest interrupts, but calling
it common is pretty exaggerated. If my mental arithmetic is not
completely off, then this affects less than 5% of the interrupt
chip/handler implementations.
The restriction is there on purpose because nesting interrupts is the
exception and not the common case. If there is no real reason, i.e. a
hardware constraint, then interrupt nesting is a bug by definition.
> This patch series makes it easier to use nested
> locking by removing the function irq_set_lockdep_class() and also the
> IRQ_GC_INIT_NESTED_LOCK flag.
>
> As one can tell from the diffstat, this patch series removes more code
> than it adds.
Sure, but with that it removes a debug mechanism for the common case,
which is not nested. Line count is not a measure for quality, neither in
one nor in the other direction.
So if you want to go there, then you have to come up with a proper
explanation why removing the 'yell, if not annotated nesting'
functionality is not a problem and the 'simplificaiton' is actually
worth it.
Thanks,
tglx
prev parent reply other threads:[~2025-02-03 19:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 17:59 [PATCH 0/5] Make it easier to use nested locking for interrupt descriptors Bart Van Assche
2025-02-03 17:59 ` [PATCH 1/5] lockdep: Introduce lockdep_unregister_key_nosync() Bart Van Assche
2025-02-03 17:59 ` [PATCH 2/5] irqdesc: Use dynamic lockdep keys for interrupt descriptors Bart Van Assche
2025-02-03 17:59 ` [PATCH 3/5] irq: Remove irq_set_lockdep_class() and __irq_set_lockdep_class() Bart Van Assche
2025-02-03 17:59 ` [PATCH 4/5] irq: Remove the IRQ_GC_INIT_NESTED_LOCK flag Bart Van Assche
2025-02-03 17:59 ` [PATCH 5/5] irq: Simplify gpiochip_add_data() Bart Van Assche
2025-02-03 19:40 ` Thomas Gleixner [this message]
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=87r04eolz5.ffs@tglx \
--to=tglx@linutronix.de \
--cc=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.