Quoting Paul Jackson <[EMAIL PROTECTED]>:
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?
Yes, but the cpuset is not made invisible to userspace (in filesystem)
yet. So as cpuset_exit() discovers that cpuset B has zero refcount now
and blocks on mutex_lock(&manage_mutex) [ to do a check_for_release
later ], someone could have done a attach_task to that cpuset.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
