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 <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
