menage@xxxxxxxxxx wrote:
> This patch adds the main containers framework - the container
> filesystem, and the basic structures for tracking membership and
> associating subsystem state objects to tasks.
[snip]
> +*** notify_on_release is disabled in the current patch set. It may be
> +*** reactivated in a future patch in a less-intrusive manner
> +
Won't this break user space tools for cpusets?
[snip]
> +See kernel/container.c for more details.
> +
> +Subsystems can take/release the container_mutex via the functions
> +container_lock()/container_unlock(), and can
> +take/release the callback_mutex via the functions
> +container_lock()/container_unlock().
> +
Hmm.. looks like a documentation error. Both mutex's are obtained through
container_lock/container_unlock ?
> +Accessing a task's container pointer may be done in the following ways:
> +- while holding container_mutex
> +- while holding the task's alloc_lock (via task_lock())
> +- inside an rcu_read_lock() section via rcu_dereference()
> +
container_mutex() and task_lock() can be used for changing the pointer?
We needed the equivalent of container_remove_file() to be called
if container_add_file() failed.
Can't we derive the top_container from containerfs_root?
> + ssize_t (*read) (struct container *cont, struct cftype *cft,
> + struct file *file,
> + char __user *buf, size_t nbytes, loff_t *ppos);
> + u64 (*read_uint) (struct container *cont, struct cftype *cft);
Is this a new callback, a specialization of the read() callback?