From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: menage@google.com
Cc: akpm@linux-foundation.org, dev@sw.ru, xemul@sw.ru,
serue@us.ibm.com, vatsa@in.ibm.com, ebiederm@xmission.com,
haveblue@us.ibm.com, svaidy@linux.vnet.ibm.com,
balbir@in.ibm.com, pj@sgi.com, ckrm-tech@lists.sourceforge.net,
linux-kernel@vger.kernel.org, rohitseth@google.com,
mbligh@google.com, containers@lists.osdl.org, devel@openvz.org
Subject: Re: [PATCH 3/9] Containers (V9): Add tasks file interface
Date: Tue, 01 May 2007 23:42:33 +0530 [thread overview]
Message-ID: <46378311.6000703@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070427111300.406327000@menage.corp.google.com>
> +static int attach_task_by_pid(struct container *cont, char *pidbuf)
> +{
> + pid_t pid;
> + struct task_struct *tsk;
> + int ret;
> +
> + if (sscanf(pidbuf, "%d", &pid) != 1)
> + return -EIO;
> +
> + if (pid) {
> + read_lock(&tasklist_lock);
You could just use rcu_read_lock() and rcu_read_unlock() instead
of read_lock(&tasklist_lock) and read_unlock(&tasklist_lock).
> +
> + tsk = find_task_by_pid(pid);
> + if (!tsk || tsk->flags & PF_EXITING) {
> + read_unlock(&tasklist_lock);
> + return -ESRCH;
> + }
> +
> + get_task_struct(tsk);
> + read_unlock(&tasklist_lock);
> +
> + if ((current->euid) && (current->euid != tsk->uid)
> + && (current->euid != tsk->suid)) {
> + put_task_struct(tsk);
> + return -EACCES;
> + }
> + } else {
> + tsk = current;
> + get_task_struct(tsk);
> + }
> +
> + ret = attach_task(cont, tsk);
> + put_task_struct(tsk);
> + return ret;
> +}
> +
> /* The various types of files and directories in a container file system */
>
> typedef enum {
> @@ -684,6 +789,54 @@ typedef enum {
> FILE_TASKLIST,
> } container_filetype_t;
>
> +static ssize_t container_common_file_write(struct container *cont,
> + struct cftype *cft,
> + struct file *file,
> + const char __user *userbuf,
> + size_t nbytes, loff_t *unused_ppos)
> +{
> + container_filetype_t type = cft->private;
> + char *buffer;
> + int retval = 0;
> +
> + if (nbytes >= PATH_MAX)
> + return -E2BIG;
> +
> + /* +1 for nul-terminator */
> + if ((buffer = kmalloc(nbytes + 1, GFP_KERNEL)) == 0)
> + return -ENOMEM;
> +
> + if (copy_from_user(buffer, userbuf, nbytes)) {
> + retval = -EFAULT;
> + goto out1;
> + }
> + buffer[nbytes] = 0; /* nul-terminate */
> +
> + mutex_lock(&container_mutex);
> +
> + if (container_is_removed(cont)) {
> + retval = -ENODEV;
> + goto out2;
> + }
Can't we make this check prior to kmalloc() and copy_from_user()?
> +int container_task_count(const struct container *cont) {
> + int count = 0;
> + struct task_struct *g, *p;
> + struct container_subsys_state *css;
> + int subsys_id;
> + get_first_subsys(cont, &css, &subsys_id);
> +
> + read_lock(&tasklist_lock);
Can be replaced with rcu_read_lock() and rcu_read_unlock()
> + do_each_thread(g, p) {
> + if (task_subsys_state(p, subsys_id) == css)
> + count ++;
> + } while_each_thread(g, p);
> + read_unlock(&tasklist_lock);
> + return count;
> +}
> +
> +static int pid_array_load(pid_t *pidarray, int npids, struct container *cont)
> +{
> + int n = 0;
> + struct task_struct *g, *p;
> + struct container_subsys_state *css;
> + int subsys_id;
> + get_first_subsys(cont, &css, &subsys_id);
> + rcu_read_lock();
> + read_lock(&tasklist_lock);
The read_lock() and read_unlock() are redundant
> +
> + do_each_thread(g, p) {
> + if (task_subsys_state(p, subsys_id) == css) {
> + pidarray[n++] = pid_nr(task_pid(p));
> + if (unlikely(n == npids))
> + goto array_full;
> + }
> + } while_each_thread(g, p);
> +
> +array_full:
> + read_unlock(&tasklist_lock);
> + rcu_read_unlock();
> + return n;
> +}
> +
[snip]
> +static int container_tasks_open(struct inode *unused, struct file *file)
> +{
> + struct container *cont = __d_cont(file->f_dentry->d_parent);
> + struct ctr_struct *ctr;
> + pid_t *pidarray;
> + int npids;
> + char c;
> +
> + if (!(file->f_mode & FMODE_READ))
> + return 0;
> +
> + ctr = kmalloc(sizeof(*ctr), GFP_KERNEL);
> + if (!ctr)
> + goto err0;
> +
> + /*
> + * If container gets more users after we read count, we won't have
> + * enough space - tough. This race is indistinguishable to the
> + * caller from the case that the additional container users didn't
> + * show up until sometime later on.
> + */
> + npids = container_task_count(cont);
> + pidarray = kmalloc(npids * sizeof(pid_t), GFP_KERNEL);
> + if (!pidarray)
> + goto err1;
> +
> + npids = pid_array_load(pidarray, npids, cont);
> + sort(pidarray, npids, sizeof(pid_t), cmppid, NULL);
> +
> + /* Call pid_array_to_buf() twice, first just to get bufsz */
> + ctr->bufsz = pid_array_to_buf(&c, sizeof(c), pidarray, npids) + 1;
> + ctr->buf = kmalloc(ctr->bufsz, GFP_KERNEL);
> + if (!ctr->buf)
> + goto err2;
> + ctr->bufsz = pid_array_to_buf(ctr->buf, ctr->bufsz, pidarray, npids);
> +
> + kfree(pidarray);
> + file->private_data = ctr;
> + return 0;
> +
> +err2:
> + kfree(pidarray);
> +err1:
> + kfree(ctr);
> +err0:
> + return -ENOMEM;
> +}
> +
Any chance we could get a per-container task list? It will
help subsystem writers as well. Alternatively, subsystems
could use the attach_task() callback to track all tasks,
but a per-container list will avoid duplication.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
next prev parent reply other threads:[~2007-05-01 18:12 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-27 10:46 [PATCH 0/9] Containers (V9): Generic Process Containers menage
2007-04-27 10:46 ` [PATCH 1/9] Containers (V9): Basic container framework menage
2007-04-29 3:12 ` [ckrm-tech] " Paul Jackson
2007-05-01 17:40 ` Balbir Singh
2007-05-01 17:46 ` Paul Menage
2007-05-01 18:40 ` [ckrm-tech] " Paul Jackson
2007-05-02 3:44 ` Balbir Singh
2007-05-02 6:12 ` Paul Jackson
2007-05-10 4:09 ` Balbir Singh
2007-05-10 4:47 ` Paul Jackson
2007-05-10 4:49 ` Balbir Singh
2007-04-27 10:46 ` [PATCH 2/9] Containers (V9): Example CPU accounting subsystem menage
2007-05-01 17:52 ` Balbir Singh
2007-04-27 10:46 ` [PATCH 3/9] Containers (V9): Add tasks file interface menage
2007-05-01 18:12 ` Balbir Singh [this message]
2007-05-01 20:37 ` [ckrm-tech] " Paul Menage
2007-05-02 3:25 ` Srivatsa Vaddagiri
2007-05-02 3:25 ` Paul Menage
2007-05-02 3:46 ` Srivatsa Vaddagiri
2007-05-08 14:51 ` Balbir Singh
2007-05-10 21:21 ` Paul Menage
2007-05-11 2:31 ` Balbir Singh
2007-05-02 3:58 ` Balbir Singh
2007-04-27 10:46 ` [PATCH 4/9] Containers (V9): Add fork/exit hooks menage
2007-04-27 10:46 ` [PATCH 5/9] Containers (V9): Add container_clone() interface menage
2007-04-27 10:46 ` [PATCH 6/9] Containers (V9): Add procfs interface menage
2007-04-27 10:46 ` [PATCH 7/9] Containers (V9): Make cpusets a client of containers menage
2007-04-27 10:46 ` [PATCH 8/9] Containers (V9): Share css_group arrays between tasks with same container memberships menage
2007-04-27 10:46 ` [PATCH 9/9] Containers (V9): Simple debug info subsystem menage
2007-04-29 1:47 ` [PATCH 0/9] Containers (V9): Generic Process Containers Paul Jackson
2007-04-29 9:37 ` Paul Jackson
2007-04-30 17:12 ` Srivatsa Vaddagiri
2007-04-30 17:09 ` Paul Menage
2007-04-30 18:06 ` Srivatsa Vaddagiri
2007-04-30 17:23 ` Christoph Hellwig
2007-04-30 18:16 ` [ckrm-tech] " Srivatsa Vaddagiri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46378311.6000703@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@in.ibm.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=containers@lists.osdl.org \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=menage@google.com \
--cc=pj@sgi.com \
--cc=rohitseth@google.com \
--cc=serue@us.ibm.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.com \
--cc=xemul@sw.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox