Messages in this thread | | | Date | Thu, 26 May 2005 11:00:10 +0200 (CEST) | From | Simon Derr <> | Subject | Re: [PATCH 2.6.12-rc4] cpuset exit NULL dereference fix |
| |
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 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/
| |