Re: [PATCH 2.6.12-rc4] cpuset exit NULL dereference fix

[Dinakar Guniguntala <dino@in.ibm.com>]

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/