lkml.org 
[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateThu, 26 May 2005 11:00:10 +0200 (CEST)
FromSimon Derr <>
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-05-26 11:04    [from the cache]
©2003-2008