Re: [PATCH 2.6.12-rc4] cpuset exit NULL dereference fix

[Paul Jackson <pj@sgi.com>]

On rereading my post above, I realize that it is confusingly presented.

Let me try again ...

Issue (1) is that we might need parts of the cpuset to process
notify_on_release after we have released the cpuset by decrementing its
reference count to zero.  Unless we hold the global cpuset_sem
semaphore, if we try to access that released cpuset to get what we need,
we can crash the kernel.  This is the issue that prompted this patch.

Issue (2) is that we have two ways of tracking users of a cpuset, with
both a reference count of tasks linked to the cpuset, and also a linked
list of child cpusets.  Unless we hold the global cpuset_sem semaphore,
there is no atomicly safe way to answer the question "is this cpuset
free now?"

The solution to Issue (1) is to make local variable copies of the
information we need from the cpuset, before we let go of it (before we
decrement its reference count).

The solution to Issue (2) is to have child cpusets also manipulate the
cpuset reference count, so that the cpuset reference count provides an
atomic way to detect all uses of a cpuset.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/