From: tip-bot2 for Julien Grall <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Julien Grall <julien.grall@arm.com>
Subject: [tip: timers/core] hrtimer: Don't take expiry_lock when timer is currently migrated
Date: Fri, 23 Aug 2019 02:12:15 -0000 [thread overview]
Message-ID: <156652633520.11649.15892124550118329976.tip-bot2@tip-bot2> (raw)
In-Reply-To: <20190821092409.13225-4-julien.grall@arm.com>
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 68b2c8c1e421096f4b46ac2ac502d25ca067a2a6
Gitweb: https://git.kernel.org/tip/68b2c8c1e421096f4b46ac2ac502d25ca067a2a6
Author: Julien Grall <julien.grall@arm.com>
AuthorDate: Wed, 21 Aug 2019 10:24:09 +01:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Wed, 21 Aug 2019 16:10:01 +02:00
hrtimer: Don't take expiry_lock when timer is currently migrated
migration_base is used as a placeholder when an hrtimer is migrated to a
different CPU. In the case that hrtimer_cancel_wait_running() hits a timer
which is currently migrated it would pointlessly acquire the expiry lock of
the migration base, which is even not initialized.
Surely it could be initialized, but there is absolutely no point in
acquiring this lock because the timer is guaranteed not to run it's
callback for which the caller waits to finish on that base. So it would
just do the inc/lock/dec/unlock dance for nothing.
As the base switch is short and non-preemptible, there is no issue when the
wait function returns immediately.
The timer base and base->cpu_base cannot be NULL in the code path which is
invoking that, so just replace those checks with a check whether base is
migration base.
[ tglx: Updated from RT patch. Massaged changelog. Added comment. ]
Signed-off-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190821092409.13225-4-julien.grall@arm.com
---
kernel/time/hrtimer.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index f48864e..ebbd0fb 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1217,7 +1217,11 @@ void hrtimer_cancel_wait_running(const struct hrtimer *timer)
/* Lockless read. Prevent the compiler from reloading it below */
struct hrtimer_clock_base *base = READ_ONCE(timer->base);
- if (!timer->is_soft || !base || !base->cpu_base) {
+ /*
+ * Just relax if the timer expires in hard interrupt context or if
+ * it is currently on the migration base.
+ */
+ if (!timer->is_soft || base == &migration_base)
cpu_relax();
return;
}
next prev parent reply other threads:[~2019-08-23 2:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 9:24 [RT PATCH 0/3] hrtimer: RT fixes for hrtimer_grab_expiry_lock() Julien Grall
2019-08-21 9:24 ` [RT PATCH 1/3] hrtimer: Use READ_ONCE to access timer->base in hrimer_grab_expiry_lock() Julien Grall
2019-08-21 13:44 ` Sebastian Andrzej Siewior
2019-08-21 13:50 ` Thomas Gleixner
2019-08-21 13:59 ` Sebastian Andrzej Siewior
2019-09-26 21:47 ` Eric Dumazet
2019-08-23 2:12 ` [tip: timers/core] hrtimer: Protect lockless access to timer->base tip-bot2 for Julien Grall
2019-08-21 9:24 ` [RT PATCH 2/3] hrtimer: Don't grab the expiry lock for non-soft hrtimer Julien Grall
2019-08-21 13:49 ` Sebastian Andrzej Siewior
2019-08-21 9:24 ` [RT PATCH 3/3] hrtimer: Prevent using uninitialized spin_lock in hrtimer_grab_expiry_lock() Julien Grall
2019-08-21 14:02 ` Thomas Gleixner
2019-08-22 10:59 ` Julien Grall
2019-08-23 2:12 ` tip-bot2 for Julien Grall [this message]
2019-09-04 14:15 ` [PATCH] hrtimer: Add a missing bracket and hide `migration_base' on !SMP Sebastian Andrzej Siewior
2019-09-04 14:39 ` Thomas Gleixner
2019-09-04 14:55 ` [PATCH v2] " Sebastian Andrzej Siewior
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=156652633520.11649.15892124550118329976.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=julien.grall@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).