| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1441373702-31796-10-git-send-email-daniel.wagner@bmw-carit.de>
Date: Fri, 4 Sep 2015 15:35:02 +0200
From: Daniel Wagner <daniel.wagner@...-carit.de>
To: linux-kernel@...r.kernel.org
Cc: Daniel Wagner <daniel.wagner@...-carit.de>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Akinobu Mita <akinobu.mita@...il.com>,
Jonathan Corbet <corbet@....net>,
Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
linux-doc@...r.kernel.org
Subject: [RFC v0 9/9] doc: Update cpu-hotplug documents on removal of CPU_TASKS_FROZEN
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 <daniel.wagner@...-carit.de>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Akinobu Mita <akinobu.mita@...il.com>
Cc: Jonathan Corbet <corbet@....net>
Cc: Len Brown <len.brown@...el.com>
Cc: Pavel Machek <pavel@....cz>
Cc: linux-doc@...r.kernel.org
Cc: linux-kernel@...r.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists