From: Leonardo Bras <leobras@redhat.com>
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"John Ogness" <john.ogness@linutronix.de>,
"Tony Lindgren" <tony@atomide.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>
Cc: Leonardo Bras <leobras@redhat.com>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: [RESEND RFC PATCH v1 1/2] irq/spurious: Reset irqs_unhandled if an irq_thread handles one IRQ request
Date: Tue, 16 Jan 2024 04:36:59 -0300 [thread overview]
Message-ID: <20240116073701.2356171-2-leobras@redhat.com> (raw)
In-Reply-To: <20240116073701.2356171-1-leobras@redhat.com>
When the IRQs are threaded, the part of the handler that runs in
interruption context can be pretty fast, as per design, while letting the
slow part to run into the thread handler.
In some cases, given IRQs can be triggered too fast, making it impossible
for the irq_thread to be able to keep up handling every request.
If two requests happen before any irq_thread handler is able to finish,
no increment to threads_handled happen, causing threads_handled and
threads_handled_last to be equal, which will ends up
causing irqs_unhandled to be incremented in note_interrupt().
Once irqs_unhandled gets to ~100k, the IRQ line gets disabled, disrupting
the device work.
As of today, the only way to reset irqs_unhandled before disabling the IRQ
line is to stay 100ms without having any increment to irqs_unhandled, which
can be pretty hard to happen if the IRQ is very busy.
On top of that, some irq_thread handlers can handle requests in batches,
effectively incrementing threads_handled only once despite dealing with a
lot of requests, which make the irqs_unhandled to reach 100k pretty fast
if the IRQ is getting a lot of requests.
This IRQ line disable bug can be easily reproduced with a serial8250
console on a PREEMPT_RT kernel: it only takes the user to print a lot
of text to the console (or to ttyS0): around 300k chars should be enough.
To fix this bug, reset irqs_unhandled whenever irq_thread handles at least
one IRQ request.
This fix makes possible to avoid disabling IRQs which irq_thread handlers
can take long (while on heavy usage of the IRQ line), without losing the
ability of disabling IRQs that actually get unhandled for too long.
Signed-off-by: Leonardo Bras <leobras@redhat.com>
---
kernel/irq/spurious.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c
index 02b2daf074414..b60748f89738a 100644
--- a/kernel/irq/spurious.c
+++ b/kernel/irq/spurious.c
@@ -339,6 +339,14 @@ void note_interrupt(struct irq_desc *desc, irqreturn_t action_ret)
handled |= SPURIOUS_DEFERRED;
if (handled != desc->threads_handled_last) {
action_ret = IRQ_HANDLED;
+
+ /*
+ * If the thread handlers handle
+ * one IRQ reset the unhandled
+ * IRQ counter.
+ */
+ desc->irqs_unhandled = 0;
+
/*
* Note: We keep the SPURIOUS_DEFERRED
* bit set. We are handling the
--
2.43.0
next prev parent reply other threads:[~2024-01-16 7:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 7:36 [RESEND RFC PATCH v1 0/2] Fix serial console for PREEMPT_RT Leonardo Bras
2024-01-16 7:36 ` Leonardo Bras [this message]
2024-01-17 22:08 ` [RESEND RFC PATCH v1 1/2] irq/spurious: Reset irqs_unhandled if an irq_thread handles one IRQ request Thomas Gleixner
2024-01-17 22:46 ` Leonardo Bras
2024-01-18 9:24 ` Leonardo Bras
2024-01-16 7:37 ` [RESEND RFC PATCH v1 2/2] serial/8250: Avoid getting lock in RT atomic context Leonardo Bras
2024-01-16 8:48 ` Ilpo Järvinen
2024-01-16 18:21 ` Leonardo Bras
2024-01-18 9:01 ` John Ogness
2024-01-18 9:36 ` Leonardo Bras
2024-01-18 10:27 ` John Ogness
2024-01-18 17:50 ` Leonardo Bras
2024-01-18 10:33 ` Jiri Slaby
2024-01-18 17:57 ` Leonardo Bras
2024-01-17 22:44 ` Thomas Gleixner
2024-01-17 23:18 ` Leonardo Bras
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=20240116073701.2356171-2-leobras@redhat.com \
--to=leobras@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=tglx@linutronix.de \
--cc=tony@atomide.com \
/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