From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Gleixner Subject: Re: [patch 10/20] cpu/hotplug: Make target state writeable Date: Sun, 28 Feb 2016 15:49:33 +0100 (CET) Message-ID: References: <20160226164321.657646833@linutronix.de> <6355023.m2RKuauZef@vostro.rjw.lan> <1490843.2y32Taz9fS@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-Reply-To: <1490843.2y32Taz9fS@vostro.rjw.lan> Sender: linux-kernel-owner@vger.kernel.org To: "Rafael J. Wysocki" Cc: LKML , Linus Torvalds , Andrew Morton , Ingo Molnar , Peter Zijlstra , Peter Anvin , Oleg Nesterov , linux-arch@vger.kernel.org, Tejun Heo , Steven Rostedt , Rusty Russell , Paul McKenney , Rafael Wysocki , Arjan van de Ven , Rik van Riel , "Srivatsa S. Bhat" , Sebastian Siewior , Paul Turner List-Id: linux-arch.vger.kernel.org Rafael, On Sat, 27 Feb 2016, Rafael J. Wysocki wrote: > Say we've taken all of them offline and now we are ready to eject. If an > online from sysfs (or any other place) comes in at this point, we'll be > ejecting a CPU that's potentially doing something which is not awesome. > > That's why we have device_hotplug_lock and some ugly code related to it. > > It extends to parents and children somewhat because of device objects > representing packages (we want those to be "offline" only if all their > children are offline) and that's why the lock is held around offline from > sysfs too. > > I'm not entirely happy with this for quite obvious reasons, but it gets > the job done ATM. Understood. I'll fix that thing up so that won't happen and I put it on the list of things to look at deeper. Thanks, tglx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from www.linutronix.de ([62.245.132.108]:37477 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757489AbcB1OvJ (ORCPT ); Sun, 28 Feb 2016 09:51:09 -0500 Date: Sun, 28 Feb 2016 15:49:33 +0100 (CET) From: Thomas Gleixner Subject: Re: [patch 10/20] cpu/hotplug: Make target state writeable In-Reply-To: <1490843.2y32Taz9fS@vostro.rjw.lan> Message-ID: References: <20160226164321.657646833@linutronix.de> <6355023.m2RKuauZef@vostro.rjw.lan> <1490843.2y32Taz9fS@vostro.rjw.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Rafael J. Wysocki" Cc: LKML , Linus Torvalds , Andrew Morton , Ingo Molnar , Peter Zijlstra , Peter Anvin , Oleg Nesterov , linux-arch@vger.kernel.org, Tejun Heo , Steven Rostedt , Rusty Russell , Paul McKenney , Rafael Wysocki , Arjan van de Ven , Rik van Riel , "Srivatsa S. Bhat" , Sebastian Siewior , Paul Turner Message-ID: <20160228144933.e8JutHylAZf3i53wm8viMveP4J1j-lFLU6cmm-O2lCw@z> Rafael, On Sat, 27 Feb 2016, Rafael J. Wysocki wrote: > Say we've taken all of them offline and now we are ready to eject. If an > online from sysfs (or any other place) comes in at this point, we'll be > ejecting a CPU that's potentially doing something which is not awesome. > > That's why we have device_hotplug_lock and some ugly code related to it. > > It extends to parents and children somewhat because of device objects > representing packages (we want those to be "offline" only if all their > children are offline) and that's why the lock is held around offline from > sysfs too. > > I'm not entirely happy with this for quite obvious reasons, but it gets > the job done ATM. Understood. I'll fix that thing up so that won't happen and I put it on the list of things to look at deeper. Thanks, tglx