[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180503124943.GB12217@hirez.programming.kicks-ass.net>
Date: Thu, 3 May 2018 14:49:43 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Mike Galbraith <efault@....de>
Cc: Matt Fleming <matt@...eblueprint.co.uk>,
Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
Michal Hocko <mhocko@...e.com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: cpu stopper threads and load balancing leads to deadlock
On Thu, May 03, 2018 at 02:40:21PM +0200, Mike Galbraith wrote:
> On Thu, 2018-05-03 at 14:28 +0200, Peter Zijlstra wrote:
> >
> > Hurm.. I don't see how this is 'new'. We moved the wakeup out from under
> > stopper lock, but that should not affect the RCU state.
>
> No, not new, just an additional woes from same spot.
Ah, ok. Does somsething like this make it go away?
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index f89014a2c238..a32518c2ba4a 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -650,8 +650,10 @@ int stop_machine_from_inactive_cpu(cpu_stop_fn_t fn, void *data,
/* Schedule work on other CPUs and execute directly for local CPU */
set_state(&msdata, MULTI_STOP_PREPARE);
cpu_stop_init_done(&done, num_active_cpus());
- queue_stop_cpus_work(cpu_active_mask, multi_cpu_stop, &msdata,
- &done);
+
+ RCU_NONIDLE(queue_stop_cpus_work(cpu_active_mask, multi_cpu_stop,
+ &msdata, &done));
+
ret = multi_cpu_stop(&msdata);
/* Busy wait for completion. */
Powered by blists - more mailing lists