aboutsummaryrefslogtreecommitdiff
path: root/include/acpi
diff options
context:
space:
mode:
authorPaul Jackson <pj@sgi.com>2005-05-27 02:02:43 -0700
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-05-27 08:07:26 -0700
commit2efe86b809d97debaaf9fcc13b041aedf15bd3d2 (patch)
tree87e039397918f4c5b0a21d798589a8ce517bfa2d /include/acpi
parent88c1834633341bbb94e315433067496338bff4ad (diff)
[PATCH] cpuset exit NULL dereference fix
There is a race in the kernel cpuset code, between the code to handle notify_on_release, and the code to remove a cpuset. The notify_on_release code can end up trying to access a cpuset that has been removed. In the most common case, this causes a NULL pointer dereference from the routine cpuset_path. However all manner of bad things are possible, in theory at least. The existing code decrements the cpuset use count, and if the count goes to zero, processes the notify_on_release request, if appropriate. However, once the count goes to zero, unless we are holding the global cpuset_sem semaphore, there is nothing to stop another task from immediately removing the cpuset entirely, and recycling its memory. The obvious fix would be to always hold the cpuset_sem semaphore while decrementing the use count and dealing with notify_on_release. However we don't want to force a global semaphore into the mainline task exit path, as that might create a scaling problem. The actual fix is almost as easy - since this is only an issue for cpusets using notify_on_release, which the top level big cpusets don't normally need to use, only take the cpuset_sem for cpusets using notify_on_release. This code has been run for hours without a hiccup, while running a cpuset create/destroy stress test that could crash the existing kernel in seconds. This patch applies to the current -linus git kernel. Signed-off-by: Paul Jackson <pj@sgi.com> Acked-by: Simon Derr <simon.derr@bull.net> Acked-by: Dinakar Guniguntala <dino@in.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'include/acpi')
0 files changed, 0 insertions, 0 deletions