Request for stable inclusion

Request for stable inclusion

[Thomas Gleixner]

Hi!

I forgot to tag the following two commits for stable:

dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")

Can you please pick them up?

Sorry for the inconveniance.

      Thomas

Re: Request for stable inclusion

[Greg KH]

On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> Hi!
> 
> I forgot to tag the following two commits for stable:
> 
> dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> 
> Can you please pick them up?

Sure, but for what kernel tree(s)?

thanks,

greg k-h

Re: Request for stable inclusion

[Thomas Gleixner]

On Thu, 20 Jul 2017, Greg KH wrote:

> On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> > Hi!
> > 
> > I forgot to tag the following two commits for stable:
> > 
> > dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> > 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> > 
> > Can you please pick them up?
> 
> Sure, but for what kernel tree(s)?

Fixes: 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully up")

# git describe --contains 8df3e07e7f21
v4.6-rc1~150^2~6

dea1d0f5f128 fixes 9cd4f1a4e7a8

Thanks,

	tglx

Re: Request for stable inclusion

[Greg KH]

On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> Hi!
> 
> I forgot to tag the following two commits for stable:
> 
> dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> 
> Can you please pick them up?
> 

These applied to 4.12-stable, but not 4.9-stable, and I think they need
to go there too, right?  If so, can you provide backports?

thanks,

greg k-h

Re: Request for stable inclusion

[Thomas Gleixner]

On Tue, 25 Jul 2017, Greg KH wrote:
> On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> > Hi!
> > 
> > I forgot to tag the following two commits for stable:
> > 
> > dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> > 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> > 
> > Can you please pick them up?
> > 
> 
> These applied to 4.12-stable, but not 4.9-stable, and I think they need
> to go there too, right?  If so, can you provide backports?

Sure. Backport for 9cd4f1a4e7a8 below. dea1d0f5f128 then applies on top.

Thanks,

	tglx

8<---------------
From: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Jul 4 22:20:23 2017 +0200
Subject: smp/hotplug: Move unparking of percpu threads to the control CPU

Upstream commit 9cd4f1a4e7a858849e889a081a99adff83e08e4c

Vikram reported the following backtrace:
    
   BUG: scheduling while atomic: swapper/7/0/0x00000002
   CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.32-perf+ #680
   schedule
   schedule_hrtimeout_range_clock
   schedule_hrtimeout
   wait_task_inactive
   __kthread_bind_mask
   __kthread_bind
   __kthread_unpark
   kthread_unpark
   cpuhp_online_idle
   cpu_startup_entry
   secondary_start_kernel

He analyzed correctly that a parked cpu hotplug thread of an offlined CPU
was still on the runqueue when the CPU came back online and tried to unpark
it. This causes the thread which invoked kthread_unpark() to call
wait_task_inactive() and subsequently schedule() with preemption disabled.
His proposed workaround was to "make sure" that a parked thread has
scheduled out when the CPU goes offline, so the situation cannot happen.

But that's still wrong because the root cause is not the fact that the
percpu thread is still on the runqueue and neither that preemption is
disabled, which could be simply solved by enabling preemption before
calling kthread_unpark().

The real issue is that the calling thread is the idle task of the upcoming
CPU, which is not supposed to call anything which might sleep.  The moron,
who wrote that code, missed completely that kthread_unpark() might end up
in schedule().

The solution is simpler than expected. The thread which controls the
hotplug operation is waiting for the CPU to call complete() on the hotplug
state completion. So the idle task of the upcoming CPU can set its state to
CPUHP_AP_ONLINE_IDLE and invoke complete(). This in turn wakes the control
task on a different CPU, which then can safely do the unpark and kick the
now unparked hotplug thread of the upcoming CPU to complete the bringup to
the final target state.

Control CPU                     AP

bringup_cpu();
  __cpu_up()  ------------>
                                bringup_ap();
  bringup_wait_for_ap()
    wait_for_completion();
                                cpuhp_online_idle();
                <------------    complete();
    unpark(AP->stopper);
    unpark(AP->hotplugthread);
                                while(1)
                                  do_idle();
    kick(AP->hotplugthread);
    wait_for_completion();      hotplug_thread()
                                  run_online_callbacks();
                                  complete();

Fixes: 8df3e07e7f21 ("cpu/hotplug: Let upcoming cpu bring itself fully up")
Reported-by: Vikram Mulukutla <markivx@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Tejun Heo <tj@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1707042218020.2131@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---
 kernel/cpu.c |   37 +++++++++++++++++++------------------
 1 file changed, 19 insertions(+), 18 deletions(-)

--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -410,11 +410,25 @@ static int notify_online(unsigned int cp
 	return 0;
 }
 
+static void __cpuhp_kick_ap_work(struct cpuhp_cpu_state *st);
+
 static int bringup_wait_for_ap(unsigned int cpu)
 {
 	struct cpuhp_cpu_state *st = per_cpu_ptr(&cpuhp_state, cpu);
 
+	/* Wait for the CPU to reach CPUHP_AP_ONLINE_IDLE */
 	wait_for_completion(&st->done);
+	BUG_ON(!cpu_online(cpu));
+
+	/* Unpark the stopper thread and the hotplug thread of the target cpu */
+	stop_machine_unpark(cpu);
+	kthread_unpark(st->thread);
+
+	/* Should we go further up ? */
+	if (st->target > CPUHP_AP_ONLINE_IDLE) {
+		__cpuhp_kick_ap_work(st);
+		wait_for_completion(&st->done);
+	}
 	return st->result;
 }
 
@@ -437,9 +451,7 @@ static int bringup_cpu(unsigned int cpu)
 		cpu_notify(CPU_UP_CANCELED, cpu);
 		return ret;
 	}
-	ret = bringup_wait_for_ap(cpu);
-	BUG_ON(!cpu_online(cpu));
-	return ret;
+	return bringup_wait_for_ap(cpu);
 }
 
 /*
@@ -974,31 +986,20 @@ void notify_cpu_starting(unsigned int cp
 }
 
 /*
- * Called from the idle task. We need to set active here, so we can kick off
- * the stopper thread and unpark the smpboot threads. If the target state is
- * beyond CPUHP_AP_ONLINE_IDLE we kick cpuhp thread and let it bring up the
- * cpu further.
+ * Called from the idle task. Wake up the controlling task which brings the
+ * stopper and the hotplug thread of the upcoming CPU up and then delegates
+ * the rest of the online bringup to the hotplug thread.
  */
 void cpuhp_online_idle(enum cpuhp_state state)
 {
 	struct cpuhp_cpu_state *st = this_cpu_ptr(&cpuhp_state);
-	unsigned int cpu = smp_processor_id();
 
 	/* Happens for the boot cpu */
 	if (state != CPUHP_AP_ONLINE_IDLE)
 		return;
 
 	st->state = CPUHP_AP_ONLINE_IDLE;
-
-	/* Unpark the stopper thread and the hotplug thread of this cpu */
-	stop_machine_unpark(cpu);
-	kthread_unpark(st->thread);
-
-	/* Should we go further up ? */
-	if (st->target > CPUHP_AP_ONLINE_IDLE)
-		__cpuhp_kick_ap_work(st);
-	else
-		complete(&st->done);
+	complete(&st->done);
 }
 
 /* Requires cpu_add_remove_lock to be held */

Re: Request for stable inclusion

[Greg KH]

On Wed, Jul 26, 2017 at 10:25:24AM +0200, Thomas Gleixner wrote:
> On Tue, 25 Jul 2017, Greg KH wrote:
> > On Thu, Jul 20, 2017 at 04:07:44PM +0200, Thomas Gleixner wrote:
> > > Hi!
> > > 
> > > I forgot to tag the following two commits for stable:
> > > 
> > > dea1d0f5f128 ("smp/hotplug: Replace BUG_ON and react useful")
> > > 9cd4f1a4e7a8 ("smp/hotplug: Move unparking of percpu threads to the control CPU")
> > > 
> > > Can you please pick them up?
> > > 
> > 
> > These applied to 4.12-stable, but not 4.9-stable, and I think they need
> > to go there too, right?  If so, can you provide backports?
> 
> Sure. Backport for 9cd4f1a4e7a8 below. dea1d0f5f128 then applies on top.

Thanks, now queued up.

greg k-h

Request for stable inclusion

[Kai-Heng Feng]

Hi,

Please include commit ("6cecdf7a161d drm/dp/mst: save vcpi with
payloads") to Stable tree.

In commit ("bb08c04dc867 drm/dp/mst: fix kernel oops when turning off
secondary monitor"), variable "mgr->payloads[i].vcpi" won't get update
without this patch.

bb08c04dc867 was backported to v3.18+, so this patch is also needed by v3.18+.

Thanks.

Re: Request for stable inclusion

[Greg KH]

On Thu, Oct 19, 2017 at 04:58:44PM +0800, Kai-Heng Feng wrote:
> Hi,
> 
> Please include commit ("6cecdf7a161d drm/dp/mst: save vcpi with
> payloads") to Stable tree.
> 
> In commit ("bb08c04dc867 drm/dp/mst: fix kernel oops when turning off
> secondary monitor"), variable "mgr->payloads[i].vcpi" won't get update
> without this patch.
> 
> bb08c04dc867 was backported to v3.18+, so this patch is also needed by v3.18+.

What stable tree(s) do you think this should be applied to?  If it
hasn't already been applied, odds are there was something preventing it
from going there (build error, or it doesn't apply?)

Do you have working backported versions?

thanks,

greg k-h

Re: Request for stable inclusion

[Greg KH]

On Thu, Oct 19, 2017 at 05:24:27PM +0800, Kai Heng Feng wrote:
> 
> 
> > On 19 Oct 2017, at 5:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > 
> > On Thu, Oct 19, 2017 at 04:58:44PM +0800, Kai-Heng Feng wrote:
> >> Hi,
> >> 
> >> Please include commit ("6cecdf7a161d drm/dp/mst: save vcpi with
> >> payloads") to Stable tree.
> >> 
> >> In commit ("bb08c04dc867 drm/dp/mst: fix kernel oops when turning off
> >> secondary monitor"), variable "mgr->payloads[i].vcpi" won't get update
> >> without this patch.
> >> 
> >> bb08c04dc867 was backported to v3.18+, so this patch is also needed by v3.18+.
> > 
> > What stable tree(s) do you think this should be applied to?  If it
> > hasn't already been applied, odds are there was something preventing it
> > from going there (build error, or it doesn't apply?)
> > 
> > Do you have working backported versions?
> 
> It should be applied to both v3.18 and v4.4. It can be cleanly cherry-picked into both linux-3.18.y and linux-4.4.y.
> 
> The patch doesn’t CC to stable, I think that’s why it didn’t get applied to stable kernels.

Ah, my appologies, I was looking at the wrong one in your email above.

> I can’t say for v3.18, but I can confirm that on v4.4, this patch is required to fix MST issue.

Now queued up, thanks.

greg k-h

request for stable inclusion

[Yijing Wang]

Hi Greg, Jiri or Liang Li

384e301e3519599b000c1a2ecd938b533fc15d85
pch_uart: fix a deadlock when pch_uart as console

This looks applicable to stable-3.4, and it
was built successful for me. What do you think?

Thanks!
Yijing.

Re: request for stable inclusion

[Luis Henriques]

Yijing Wang <wangyijing@huawei.com> writes:

> Hi Greg, Jiri or Liang Li
>
> 384e301e3519599b000c1a2ecd938b533fc15d85
> pch_uart: fix a deadlock when pch_uart as console
>
> This looks applicable to stable-3.4, and it
> was built successful for me. What do you think?
>
> Thanks!
> Yijing.
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I'm queuing it for the 3.5 as well.

Also, this seems to be applicable to older kernels as well.

Cheers,
-- 
Luis

Re: request for stable inclusion

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]

On Fri, 2013-06-28 at 17:04 +0800, Yijing Wang wrote:
> Hi Greg, Jiri or Liang Li
> 
> 384e301e3519599b000c1a2ecd938b533fc15d85
> pch_uart: fix a deadlock when pch_uart as console
> 
> This looks applicable to stable-3.4, and it
> was built successful for me. What do you think?

I've queued this up for 3.2 as well, thanks.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]