From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933589AbbIDNfq (ORCPT ); Fri, 4 Sep 2015 09:35:46 -0400 Received: from mail.bmw-carit.de ([62.245.222.98]:45851 "EHLO linuxmail.bmw-carit.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933545AbbIDNfP (ORCPT ); Fri, 4 Sep 2015 09:35:15 -0400 From: Daniel Wagner To: linux-kernel@vger.kernel.org Cc: Daniel Wagner , "Rafael J. Wysocki" , Akinobu Mita , Jonathan Corbet , Len Brown , Pavel Machek , linux-doc@vger.kernel.org Subject: [RFC v0 9/9] doc: Update cpu-hotplug documents on removal of CPU_TASKS_FROZEN Date: Fri, 4 Sep 2015 15:35:02 +0200 Message-Id: <1441373702-31796-10-git-send-email-daniel.wagner@bmw-carit.de> X-Mailer: git-send-email 2.4.3 In-Reply-To: <1441373702-31796-1-git-send-email-daniel.wagner@bmw-carit.de> References: <1441373702-31796-1-git-send-email-daniel.wagner@bmw-carit.de> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org CPU_*_FROZEN states are gone update the documentation accordingly. I am not completely convinced that the listed known race condition can be removed as it is done in this patch. If a suspend/resume is ongoing while cpu_{down|up}() is called renders at least the 'always passing 0 as tasks_frozen in cpu_up()' argument false. Signed-off-by: Daniel Wagner Cc: "Rafael J. Wysocki" Cc: Akinobu Mita Cc: Jonathan Corbet Cc: Len Brown Cc: Pavel Machek Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Documentation/cpu-hotplug.txt | 12 +++++------- Documentation/fault-injection/notifier-error-inject.txt | 2 -- Documentation/power/suspend-and-cpuhotplug.txt | 13 ++----------- 3 files changed, 7 insertions(+), 20 deletions(-) diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index f9ad5e0..e362f42 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -244,9 +244,9 @@ Q: What happens when a CPU is being logically offlined? A: The following happen, listed in no particular order :-) - A notification is sent to in-kernel registered modules by sending an event - CPU_DOWN_PREPARE or CPU_DOWN_PREPARE_FROZEN, depending on whether or not the - CPU is being offlined while tasks are frozen due to a suspend operation in - progress + CPU_DOWN_PREPARE. Via freeze_active it is possible to inquire if a suspend + operation is ongoing, that is a CPU is beeing offlined while tasks + are frozen. - All processes are migrated away from this outgoing CPU to new CPUs. The new CPU is chosen from each process' current cpuset, which may be a subset of all online CPUs. @@ -255,8 +255,8 @@ A: The following happen, listed in no particular order :-) - Once all services are migrated, kernel calls an arch specific routine __cpu_disable() to perform arch specific cleanup. - Once this is successful, an event for successful cleanup is sent by an event - CPU_DEAD (or CPU_DEAD_FROZEN if tasks are frozen due to a suspend while the - CPU is being offlined). + CPU_DEAD (if tasks are frozen due to a suspend while the + CPU is being offlined can be probed via freeze_active()). "It is expected that each service cleans up when the CPU_DOWN_PREPARE notifier is called, when CPU_DEAD is called its expected there is nothing @@ -274,11 +274,9 @@ A: This is what you would need in your kernel code to receive notifications. switch (action) { case CPU_ONLINE: - case CPU_ONLINE_FROZEN: foobar_online_action(cpu); break; case CPU_DEAD: - case CPU_DEAD_FROZEN: foobar_dead_action(cpu); break; } diff --git a/Documentation/fault-injection/notifier-error-inject.txt b/Documentation/fault-injection/notifier-error-inject.txt index 09adabe..1ec4e84 100644 --- a/Documentation/fault-injection/notifier-error-inject.txt +++ b/Documentation/fault-injection/notifier-error-inject.txt @@ -23,9 +23,7 @@ the error code to debugfs interface Possible CPU notifier events to be failed are: * CPU_UP_PREPARE - * CPU_UP_PREPARE_FROZEN * CPU_DOWN_PREPARE - * CPU_DOWN_PREPARE_FROZEN Example1: Inject CPU offline error (-1 == -EPERM) diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt index 2fc9095..ab657cd 100644 --- a/Documentation/power/suspend-and-cpuhotplug.txt +++ b/Documentation/power/suspend-and-cpuhotplug.txt @@ -232,7 +232,7 @@ d. Handling microcode update during suspend/hibernate: hibernate/restore cycle.] In the current design of the kernel however, during a CPU offline operation - as part of the suspend/hibernate cycle (the CPU_DEAD_FROZEN notification), + as part of the suspend/hibernate cycle (see freeze_active()), the existing copy of microcode image in the kernel is not freed up. And during the CPU online operations (during resume/restore), since the kernel finds that it already has copies of the microcode images for all the @@ -248,16 +248,7 @@ III. Are there any known problems when regular CPU hotplug and suspend race Yes, they are listed below: -1. When invoking regular CPU hotplug, the 'tasks_frozen' argument passed to - the _cpu_down() and _cpu_up() functions is *always* 0. - This might not reflect the true current state of the system, since the - tasks could have been frozen by an out-of-band event such as a suspend - operation in progress. Hence, it will lead to wrong notifications being - sent during the cpu online/offline events (eg, CPU_ONLINE notification - instead of CPU_ONLINE_FROZEN) which in turn will lead to execution of - inappropriate code by the callbacks registered for such CPU hotplug events. - -2. If a regular CPU hotplug stress test happens to race with the freezer due +1. If a regular CPU hotplug stress test happens to race with the freezer due to a suspend operation in progress at the same time, then we could hit the situation described below: -- 2.4.3