From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933987AbbJHOyW (ORCPT ); Thu, 8 Oct 2015 10:54:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33913 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933747AbbJHOyS (ORCPT ); Thu, 8 Oct 2015 10:54:18 -0400 Date: Thu, 8 Oct 2015 16:50:59 +0200 From: Oleg Nesterov To: Peter Zijlstra Cc: heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, Tejun Heo , Ingo Molnar , Rik van Riel , Thomas Gleixner Subject: [PATCH 0/3] (Was: [RFC][PATCH] sched: Start stopper early) Message-ID: <20151008145059.GA17916@redhat.com> References: <20151007084110.GX2881@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151007084110.GX2881@worktop.programming.kicks-ass.net> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/07, Peter Zijlstra wrote: > > So Heiko reported some 'interesting' fail where stop_two_cpus() got > stuck in multi_cpu_stop() with one cpu waiting for another that never > happens. > > It _looks_ like the 'other' cpu isn't running and the current best > theory is that we race on cpu-up and get the stop_two_cpus() call in > before the stopper task is running. How about this series? Slightly tested. Note: - To me this also looks like a preparation for lg lock removal, no matter how exactly we will do this. - We can do more cleanups on top of this. Say remove preempt_disable in stop_two_cpus(). Oleg. include/linux/stop_machine.h | 1 kernel/cpu.c | 2 - kernel/stop_machine.c | 83 +++++++++++++++++++++++++++++-------------- 3 files changed, 58 insertions(+), 28 deletions(-)