Commit c9427539 authored Jan 09, 2017 by Santosh Mardi

cpufreq: update hrtimer start with no-wakeup version.



There is a possibility of waking up a de-queued task on
the same CPU it is currently running. When this happens,
Scheduler will wait infinitely and results in a watch dog bark.

The above deadlock condition is observed when ksoftirqd is woken
up from the governor's load change callback.
- Task ksoftirqd enters interruptible sleep by calling schedule()
- As it is the only runnable task on this CPU, idle_balance()
is called.
- Few tasks are pulled to the current CPU and a notification
is sent to the governor for selecting appropriate frequency
- Governor arms a hrtimer which involves waking up ksoftirqd on
the same CPU
- ksoftirqd is not on the run-queue but it's on_cpu is set, so
Scheduler wait infinitely for it to be cleared.

To avoid this scenario update the hrtimer start with no-wakeup
version which will not wake up softirqd rather it will set the
pending softirq which will not wake up the softirqd immediately
and softirq will get a chance to run soon.

CRs-Fixed: 1108244
Change-Id: I46e015d80c85c94a8072b906d1ba836a4fa62cbb
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>

parent 1bcbd831

drivers/cpufreq/cpufreq_interactive.c

+2 −2

Original line number	Diff line number	Diff line
		@@ -811,8 +811,8 @@ static int load_change_callback(struct notifier_block *nb, unsigned long val,
		spin_unlock_irqrestore(&ppol->target_freq_lock, flags);

		if (!hrtimer_is_queued(&ppol->notif_timer))
		hrtimer_start(&ppol->notif_timer, ms_to_ktime(1),
		HRTIMER_MODE_REL);
		__hrtimer_start_range_ns(&ppol->notif_timer, ms_to_ktime(1),
		0, HRTIMER_MODE_REL, 0);
		exit:
		up_read(&ppol->enable_sem);
		return 0;