From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Johan Hovold <johan@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Stanislaw Gruszka <sgruszka@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH] USB: ehci: drop workaround for forced irq threading
Date: Mon, 22 Mar 2021 17:59:17 +0100 [thread overview]
Message-ID: <20210322165917.it5d5f5kuvs7jah5@linutronix.de> (raw)
In-Reply-To: <20210322164200.GB667925@rowland.harvard.edu>
On 2021-03-22 12:42:00 [-0400], Alan Stern wrote:
> What happens on RT systems? Are they smart enough to avoid the whole
> problem by enabling interrupts during _all_ callbacks?
tl;dr: Yes.
The referenced commit (id 81e2073c175b) disables interrupts only on !RT
configs so for RT everything remains unchanged (the backports are
already adjusted for the old stable trees to use the proper CONFIG_* for
enabled RT).
All hrtimer callbacks run as HRTIMER_MODE_SOFT by default. The
HRTIMER_MODE_HARD ones (which expire in HARDIRQ context) were audited /
explicitly enabled.
The same goes irq_work.
The printk code is different compared to mainline. A printk() on RT in
HARDIRQ context is printed once the HARDIRQ context is left. So the
serial/console/… driver never gets a chance to acquire its lock in
hardirq context.
An interrupt handler which is not forced-threaded must be marked as such
and must not use any spinlock_t based locking. lockdep/might_sleep
complain here already.
> Alan Stern
Sebastian
next prev parent reply other threads:[~2021-03-22 17:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 11:12 Johan Hovold
2021-03-22 16:42 ` Alan Stern
2021-03-22 16:59 ` Sebastian Andrzej Siewior [this message]
2021-03-22 19:01 ` Alan Stern
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=20210322165917.it5d5f5kuvs7jah5@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=sgruszka@redhat.com \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®