From: Gaurav Kohli <gkohli@codeaurora.org>
To: peterz@infradead.org, tglx@linutronix.de, mpe@ellerman.id.au,
mingo@kernel.org, bigeasy@linutronix.de
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Gaurav Kohli <gkohli@codeaurora.org>,
Neeraj Upadhyay <neeraju@codeaurora.org>
Subject: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup
Date: Wed, 25 Apr 2018 14:03:19 +0530 [thread overview]
Message-ID: <1524645199-5596-1-git-send-email-gkohli@codeaurora.org> (raw)
The control cpu thread which initiates hotplug calls kthread_park()
for hotplug thread and sets KTHREAD_SHOULD_PARK. After this control
thread wakes up the hotplug thread. There is a chance that wakeup
code sees the hotplug thread (running on AP core) in INTERRUPTIBLE
state, but sets its state to RUNNING after hotplug thread has entered
kthread_parkme() and changed its state to TASK_PARKED. This can result
in panic later on in kthread_unpark(), as it sees KTHREAD_IS_PARKED
flag set but fails to rebind the kthread, due to it being not in
TASK_PARKED state. Fix this, by serializing wakeup state change,
against state change before parking the kthread.
Below is the possible race:
Control thread Hotplug Thread
kthread_park()
set KTHREAD_SHOULD_PARK
smpboot_thread_fn
set_current_state(TASK_INTERRUPTIBLE);
kthread_parkme
wake_up_process()
raw_spin_lock_irqsave(&p->pi_lock, flags);
if (!(p->state & state)) -> this will fail
goto out;
__kthread_parkme
__set_current_state(TASK_PARKED);
if (p->on_rq && ttwu_remote(p, wake_flags))
ttwu_remote()
p->state = TASK_RUNNING;
schedule();
So to avoid this race, take pi_lock to serial state changes.
Suggested-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Co-developed-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
---
Changes since V1:
- Add comment to explain need of pi_lock.
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 5043e74..c5c5184 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -122,7 +122,45 @@ static int smpboot_thread_fn(void *data)
}
if (kthread_should_park()) {
+ /*
+ * Serialize against wakeup. If we take the lock first,
+ * wakeup is skipped. If we run later, we observe,
+ * TASK_RUNNING update from wakeup path, before moving
+ * forward. This helps avoid the race, where wakeup
+ * observes TASK_INTERRUPTIBLE, and also observes
+ * the TASK_PARKED in kthread_parkme() before updating
+ * task state to TASK_RUNNING. In this case, kthread
+ * gets parked in TASK_RUNNING state. This results
+ * in panic later on in kthread_unpark(), as it sees
+ * KTHREAD_IS_PARKED flag set but fails to rebind the
+ * kthread, due to it being not in TASK_PARKED state.
+ *
+ * Control thread Hotplug Thread
+ *
+ * kthread_park()
+ * set KTHREAD_SHOULD_PARK
+ * smpboot_thread_fn()
+ * set_current_state(
+ * TASK_INTERRUPTIBLE);
+ * kthread_parkme()
+ *
+ * wake_up_process()
+ *
+ * raw_spin_lock_irqsave(&p->pi_lock, flags);
+ * if (!(p->state & state)) __set_current_state(
+ * goto out; TASK_RUNNING);
+ *
+ * __set_current_state(
+ * TASK_PARKED);
+ *
+ * if (p->on_rq && ttwu_remote(p, wake_flags))
+ * ttwu_remote()
+ * p->state = TASK_RUNNING;
+ * schedule();
+ */
+ raw_spin_lock(¤t->pi_lock);
__set_current_state(TASK_RUNNING);
+ raw_spin_unlock(¤t->pi_lock);
preempt_enable();
if (ht->park && td->status == HP_THREAD_ACTIVE) {
BUG_ON(td->cpu != smp_processor_id());
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
next reply other threads:[~2018-04-25 8:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 8:33 Gaurav Kohli [this message]
2018-04-25 20:09 ` [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup Peter Zijlstra
2018-04-26 4:04 ` Kohli, Gaurav
2018-04-26 9:14 ` Peter Zijlstra
2018-04-26 8:41 ` Peter Zijlstra
2018-04-26 8:57 ` Peter Zijlstra
2018-04-26 15:53 ` Kohli, Gaurav
2018-04-30 11:17 ` Peter Zijlstra
2018-05-01 7:50 ` Kohli, Gaurav
2018-05-01 10:18 ` Peter Zijlstra
2018-05-01 10:40 ` Peter Zijlstra
2018-05-01 10:40 ` Kohli, Gaurav
2018-05-01 11:31 ` Peter Zijlstra
2018-05-01 11:46 ` Kohli, Gaurav
2018-05-01 13:19 ` Peter Zijlstra
2018-05-02 5:15 ` Kohli, Gaurav
2018-05-02 8:20 ` Peter Zijlstra
2018-05-02 10:13 ` Kohli, Gaurav
2018-05-07 11:09 ` Kohli, Gaurav
2018-05-07 11:23 ` Kohli, Gaurav
2018-06-05 11:13 ` Kohli, Gaurav
2018-06-05 15:08 ` Oleg Nesterov
2018-06-05 15:22 ` Peter Zijlstra
2018-06-05 15:40 ` Peter Zijlstra
2018-06-05 16:35 ` Oleg Nesterov
2018-06-05 18:21 ` Kohli, Gaurav
2018-06-05 20:13 ` Peter Zijlstra
2018-06-06 13:51 ` Oleg Nesterov
2018-06-06 15:03 ` Peter Zijlstra
2018-06-06 15:04 ` Peter Zijlstra
2018-06-06 15:22 ` Peter Zijlstra
2018-06-06 18:59 ` Peter Zijlstra
2018-06-07 8:30 ` Kohli, Gaurav
2018-05-01 10:44 ` Peter Zijlstra
2018-04-26 16:02 ` Andrea Parri
2018-04-26 16:18 ` Oleg Nesterov
2018-04-30 11:20 ` Peter Zijlstra
2018-04-30 11:56 ` Peter Zijlstra
2018-04-28 6:43 ` [lkp-robot] [kthread/smpboot] cad8e99675: inconsistent{IN-HARDIRQ-W}->{HARDIRQ-ON-W}usage kernel test robot
2018-04-28 6:43 ` kernel test robot
2018-04-28 6:43 ` kernel test robot
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=1524645199-5596-1-git-send-email-gkohli@codeaurora.org \
--to=gkohli@codeaurora.org \
--cc=bigeasy@linutronix.de \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=neeraju@codeaurora.org \
--cc=peterz@infradead.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 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.