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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111027134824.20916.46845.stgit@srivatsabhat.in.ibm.com>
Date:	Thu, 27 Oct 2011 19:18:59 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	unlisted-recipients:; (no To-header on input)
Cc:	a.p.zijlstra@...llo.nl, rjw@...k.pl, stern@...land.harvard.edu,
	pavel@....cz, len.brown@...el.com, mingo@...e.hu,
	akpm@...ux-foundation.org, suresh.b.siddha@...el.com,
	lucas.demarchi@...fusion.mobi, linux-pm@...r.kernel.org,
	rusty@...tcorp.com.au, vatsa@...ux.vnet.ibm.com,
	ashok.raj@...el.com, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, rdunlap@...otime.net
Subject: [PATCH v4 0/2] CPU hotplug,
 Freezer: Fix race between CPU hotplug and freezer

The CPU hotplug notifications sent out by the _cpu_up() and _cpu_down()
functions depends on the value of the 'tasks_frozen' argument passed to them.
(Examples: CPU_ONLINE, CPU_ONLINE_FROZEN, CPU_DEAD, CPU_DEAD_FROZEN).

Thus, it is essential that while the callbacks for those notifications are
running, the state of the system with respect to the tasks being frozen or
not remains unchanged, *throughout that duration*. Hence there is a need for
synchronizing the CPU hotplug code with the freezer subsystem.

This patchset introduces two freezer notifications PM_FREEZE_PREPARE and
PM_POST_THAW to announce the freezer's activities to other interested
subsystems. The CPU hotplug code hooks onto these notifications and prevents
the race between CPU hotplug and freezer, thus ensuring that CPU hotplug
notifications will always be run with the state of the system really being
what the notifications mean.


v4: * Retained the value 0 for the 'tasks_frozen' argument, while calling
      _cpu_up() and _cpu_down().
      Removed the unnecessary PM_POST_FREEZE and PM_THAW_PREPARE notifications.

v3: * Added synchronization between CPU hotplug and the freezer subsystem
      without introducing any new locks in the CPU hotplug call path.

v2: * Removed the atomic_t declaration of tasks_frozen flag and the
      atomic_[set|read] functions since they were unnecessary.
    * Updated the changelog to give an example scenario where things could go
      wrong due to the bug in the CPU hotplug call path.

References:
v1 -> http://thread.gmane.org/gmane.linux.kernel/1198312/
v2 -> http://thread.gmane.org/gmane.linux.kernel/1198312/focus=1199087
v3 -> http://thread.gmane.org/gmane.linux.documentation/3472

--
Srivatsa S. Bhat (2):
      PM / Freezer: Introduce PM_FREEZE_PREPARE and PM_POST_THAW notifications
      CPU hotplug, Freezer: Synchronize CPU hotplug and Freezer


 Documentation/power/notifiers.txt |    4 ++
 include/linux/suspend.h           |    4 +-
 kernel/cpu.c                      |   76 +++++++++++++++++++++++++++++++++++++
 kernel/power/process.c            |    8 +++-
 4 files changed, 90 insertions(+), 2 deletions(-)


--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ