On Tue, 20 Sep 2005, Robin Holt wrote:
> This makes things even easier!!!
>
> When you create a cpuset, set the refcount to 0. The root
> cpuset is the exception and has a refcount of 1.
>
> When tasks are added to the cpuset, increment the refcount.
>
> When child cpusets are created, increment the refcount. Each
> cpuset has a list of children that is protected by a single
> lock.
>
> Whenever you are decrementing the cpuset's refcount, use
> atomic_dec_and_lock on the parents child list lock. If the
> notify_on_release property is set, you remove the child from
> the list.
>
> When the vfs code is traversing the list, you need to ensure
> that it does not iterate unless the child list lock is held.
> I have not looked at how you implemented the vfs stuff, but
> that should be easily accomplished.
IIRC, that's the key.
There was never a real issue about notify_on_release on the internal
locking of the cpusets. But with the VFS...
The problem lies in how the VFS takes the semaphores on the inodes
when doing a rmdir(). It locks the parent's inode, and then the child's
inode. And because of the cascading cpuset removal with the previous
'autoclean' feature, the cpuset code tried to do the same thing, but in
the reverse order. There was once a version of the code that seemed to
work, but with inodes semaphores released and re-taken in the good order.
Ugly, and unsafe.
(All this from memory, I don't guarantee its accuracy).
Simon.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |