From: Daniel Wagner <wagi@monom.org>
To: LKML <linux-kernel@vger.kernel.org>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Carsten Emde <C.Emde@osadl.org>, John Kacur <jkacur@redhat.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Tom Zanussi <tom.zanussi@linux.intel.com>,
Clark Williams <williams@redhat.com>,
Pavel Machek <pavel@denx.de>
Cc: Mike Galbraith <efault@gmx.de>, Daniel Wagner <wagi@monom.org>
Subject: [PATCH RT 6/9] timers: Don't block on ->expiry_lock for TIMER_IRQSAFE timers
Date: Mon, 24 Oct 2022 12:44:22 +0200 [thread overview]
Message-ID: <20221024104425.16423-7-wagi@monom.org> (raw)
In-Reply-To: <20221024104425.16423-1-wagi@monom.org>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
v4.19.255-rt114-rc1 stable review patch.
If anyone has any objections, please let me know.
-----------
Upstream commit c725dafc95f1b37027840aaeaa8b7e4e9cd20516
PREEMPT_RT does not spin and wait until a running timer completes its
callback but instead it blocks on a sleeping lock to prevent a livelock in
the case that the task waiting for the callback completion preempted the
callback.
This cannot be done for timers flagged with TIMER_IRQSAFE. These timers can
be canceled from an interrupt disabled context even on RT kernels.
The expiry callback of such timers is invoked with interrupts disabled so
there is no need to use the expiry lock mechanism because obviously the
callback cannot be preempted even on RT kernels.
Do not use the timer_base::expiry_lock mechanism when waiting for a running
callback to complete if the timer is flagged with TIMER_IRQSAFE.
Also add a lockdep assertion for RT kernels to validate that the expiry
lock mechanism is always invoked in preemptible context.
Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201103190937.hga67rqhvknki3tp@linutronix.de
[bigeasy: The logic in v4.19 is slightly different but the outcome is the
same as we must not sleep while waiting for the irqsafe timer to
complete. The IRQSAFE timer can not be preempted.
The "lockdep annotation" is not available and has been replaced with
might_sleep()]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Daniel Wagner <wagi@monom.org>
---
kernel/time/timer.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 3e2c0bd03004..0a6d60b3e67c 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1272,6 +1272,9 @@ static int __del_timer_sync(struct timer_list *timer)
if (ret >= 0)
return ret;
+ if (READ_ONCE(timer->flags) & TIMER_IRQSAFE)
+ continue;
+
/*
* When accessing the lock, timers of base are no longer expired
* and so timer is no longer running.
@@ -1336,6 +1339,12 @@ int del_timer_sync(struct timer_list *timer)
* could lead to deadlock.
*/
WARN_ON(in_irq() && !(timer->flags & TIMER_IRQSAFE));
+ /*
+ * Must be able to sleep on PREEMPT_RT because of the slowpath in
+ * __del_timer_sync().
+ */
+ if (IS_ENABLED(CONFIG_PREEMPT_RT) && !(timer->flags & TIMER_IRQSAFE))
+ might_sleep();
return __del_timer_sync(timer);
}
--
2.38.0
next prev parent reply other threads:[~2022-10-24 10:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 10:44 [PATCH RT 0/9] Linux v4.19.255-rt114-rc1 Daniel Wagner
2022-10-24 10:44 ` [PATCH RT 1/9] Revert "random: Use local locks for crng context access" Daniel Wagner
2022-10-24 10:44 ` [PATCH RT 2/9] random: Bring back the local_locks Daniel Wagner
2022-10-24 10:44 ` [PATCH RT 3/9] local_lock: Provide INIT_LOCAL_LOCK() Daniel Wagner
2022-10-24 10:44 ` [PATCH RT 4/9] Revert "workqueue: Use local irq lock instead of irq disable regions" Daniel Wagner
2022-10-24 10:44 ` [PATCH RT 5/9] timers: Keep interrupts disabled for TIMER_IRQSAFE timer Daniel Wagner
2022-10-24 10:44 ` Daniel Wagner [this message]
2022-10-24 10:44 ` [PATCH RT 7/9] rcu: Update rcuwait Daniel Wagner
2022-10-24 10:44 ` [PATCH RT 8/9] workqueue: Use rcuwait for wq_manager_wait Daniel Wagner
2022-10-24 10:44 ` [PATCH RT 9/9] Linux 4.19.255-rt114-rc1 Daniel Wagner
2022-10-24 10:54 ` [PATCH RT 0/9] Linux v4.19.255-rt114-rc1 Daniel Wagner
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=20221024104425.16423-7-wagi@monom.org \
--to=wagi@monom.org \
--cc=C.Emde@osadl.org \
--cc=bigeasy@linutronix.de \
--cc=efault@gmx.de \
--cc=jkacur@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=pavel@denx.de \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tom.zanussi@linux.intel.com \
--cc=williams@redhat.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
all inboxes | Powered by JetHome®