Re: [PATCH] Fix race between attach_task and cpuset_exit

[Paul Jackson <pj@sgi.com>]

vatsa wrote:
> Well, someone may have attached to this cpuset while we were waiting on the 
> mutex_lock(). So we need to do a atomic_read again to ensure it is still
> unused.

I don't see how this could happen.  If we hold the task lock that now
(thanks to your good work) guards this pointer, and if we decrement to
zero the reference count on the cpuset to which it points and then
-overwrite- this last remaining visible pointer to that cpuset with a
pointer to a different cpuset, then aren't we guaranteed to be holding
the last remaining reference to the old cpuset in our local variable,
making it impossible for anyone else to attach to it in any way?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401