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, May 26, 2005 at 11:00:10AM +0200, Simon Derr wrote:
> > 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 ?

This would have to be in addition to the existing cpuset_sem wont it ??
Not sure if we need to add any more complexity unless the scaling problem
is really huge.

However if we do end up making any changes then IMO locking can be made
more granular, instead of one sem for cpus, memory and all operations
on cpusets

-Dinakar
-
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 15:49    [W:0.073 / U:1.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site