Commit 2efe86b8 authored by Paul Jackson's avatar Paul Jackson Committed by Linus Torvalds
Browse files

[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: default avatarPaul Jackson <>
Acked-by: default avatarSimon Derr <>
Acked-by: default avatarDinakar Guniguntala <>
Signed-off-by: default avatarLinus Torvalds <>
parent 88c18346
......@@ -166,9 +166,8 @@ static struct super_block *cpuset_sb = NULL;
* The hooks from fork and exit, cpuset_fork() and cpuset_exit(), don't
* (usually) grab cpuset_sem. These are the two most performance
* critical pieces of code here. The exception occurs on exit(),
* if the last task using a cpuset exits, and the cpuset was marked
* notify_on_release. In that case, the cpuset_sem is taken, the
* path to the released cpuset calculated, and a usermode call made
* when a task in a notify_on_release cpuset exits. Then cpuset_sem
* is taken, and if the cpuset count is zero, a usermode call made
* to /sbin/cpuset_release_agent with the name of the cpuset (path
* relative to the root of cpuset file system) as the argument.
......@@ -1404,6 +1403,18 @@ void cpuset_fork(struct task_struct *tsk)
* Description: Detach cpuset from @tsk and release it.
* Note that cpusets marked notify_on_release force every task
* in them to take the global cpuset_sem semaphore when exiting.
* This could impact scaling on very large systems. Be reluctant
* to use notify_on_release cpusets where very high task exit
* scaling is required on large systems.
* Don't even think about derefencing 'cs' after the cpuset use
* count goes to zero, except inside a critical section guarded
* by the cpuset_sem semaphore. If you don't hold cpuset_sem,
* then a zero cpuset use count is a license to any other task to
* nuke the cpuset immediately.
void cpuset_exit(struct task_struct *tsk)
......@@ -1415,10 +1426,13 @@ void cpuset_exit(struct task_struct *tsk)
tsk->cpuset = NULL;
if (atomic_dec_and_test(&cs->count)) {
if (notify_on_release(cs)) {
if (atomic_dec_and_test(&cs->count))
} else {
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment