From: Prateek Sood <prsood@codeaurora.org>
To: peterz@infradead.org, mingo@redhat.com
Cc: sramana@codeaurora.org, linux-kernel@vger.kernel.org,
Prateek Sood <prsood@codeaurora.org>
Subject: [PATCH] osq_lock: avoid live-lock issue for RT task
Date: Fri, 14 Jul 2017 19:19:09 +0530 [thread overview]
Message-ID: <1500040149-27971-1-git-send-email-prsood@codeaurora.org> (raw)
Live Lock due to task spinning while unqueue of CPU osq_node
from optimistic_spin_queue. Task T1 had decremented mutex count to
acquire the lock on CPU0. Before setting owner it got preempted. On
CPU1 task T2 acquired osq_lock and started spinning on owner of mutex
with preemption disabled. CPU1 runq has one task, so need_resched will
not be set. On CPU0 task T3 tried to acquire osq_lock to spin on the
same mutex. At this time following scenario causes soft lockup:
After preemption of task T1, RT task T3 tried to acquire the same
mutex. It will start spinning on the osq_lock until the lock is available
or need_resched is set. For RT task, need_resched will not be set. Task T3
will not be able to bail out of the infinite loop.
Signed-off-by: Prateek Sood <prsood@codeaurora.org>
---
kernel/locking/osq_lock.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a3785..99b8d99 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -1,6 +1,7 @@
#include <linux/percpu.h>
#include <linux/sched.h>
#include <linux/osq_lock.h>
+#include <linux/sched/rt.h>
/*
* An MCS like lock especially tailored for optimistic spinning for sleeping
@@ -85,6 +86,7 @@ bool osq_lock(struct optimistic_spin_queue *lock)
{
struct optimistic_spin_node *node = this_cpu_ptr(&osq_node);
struct optimistic_spin_node *prev, *next;
+ struct task_struct *task = current;
int curr = encode_cpu(smp_processor_id());
int old;
@@ -118,8 +120,13 @@ bool osq_lock(struct optimistic_spin_queue *lock)
while (!READ_ONCE(node->locked)) {
/*
* If we need to reschedule bail... so we can block.
+ * If a task spins on owner on a CPU after acquiring
+ * osq_lock while a RT task spins on another CPU to
+ * acquire osq_lock, it will starve the owner from
+ * completing if owner is to be scheduled on the same CPU.
+ * It will be a live lock.
*/
- if (need_resched())
+ if (need_resched() || rt_task(task))
goto unqueue;
cpu_relax_lowlatency();
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next reply other threads:[~2017-07-14 13:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-14 13:49 Prateek Sood [this message]
2017-07-18 11:36 ` [PATCH] osq_lock: avoid live-lock issue for RT task Peter Zijlstra
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=1500040149-27971-1-git-send-email-prsood@codeaurora.org \
--to=prsood@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sramana@codeaurora.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.