lkml.org 
[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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    [W:0.091 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site