On Thu, 26 May 2005, Paul Jackson wrote:
> 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.
Good catch.
>
> 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.
I'm a bit concerned about this. Since there might well be
'notify_on_release' cpusets all over the system, and that there is only
one cpuset_sem semaphore, I feel like this 'scaling problem' still exists
even with:
if (notify_on_release(cs)) {
down(&cpuset_sem);
...
Maybe adding more per-cpuset data such as a per-cpuset removal_sem might
be worth it ?
Simon.
-
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]
