From: Chris Wright <chrisw@osdl.org>
To: Erik Jacobson <erikj@subway.americas.sgi.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Process Aggregates (PAGG) support for the 2.6 kernel
Date: Mon, 26 Apr 2004 16:39:55 -0700 [thread overview]
Message-ID: <20040426163955.X21045@build.pdx.osdl.net> (raw)
In-Reply-To: <Pine.SGI.4.53.0404261656230.591647@subway.americas.sgi.com>; from erikj@subway.americas.sgi.com on Mon, Apr 26, 2004 at 05:04:39PM -0500
* Erik Jacobson (erikj@subway.americas.sgi.com) wrote:
> Here, I am proposing Process Aggregates support for the 2.6 kernel.
This looks like it's just the infrastructure, i.e. nothing is using it.
It seems like PAGG could be done on top of CKRM (albeit, with more
code). But if the goal is to do some basic accounting, scheduling, etc.
on a resource group, wouldn't CKRM be more generic?
Couple quick comments below.
> +struct pagg_hook {
> + struct module *module;
doesn't seem used.
> + char *name; /* Name Key - restricted to 32 characters */
why the restriction?
> +#define attach_pagg_list_chk(ct, pt) \
> +do { \
> + INIT_PAGG_LIST(&ct->pagg_list); \
> + if (!list_empty(&pt->pagg_list.head)) { \
> + if (attach_pagg_list(ct, pt) != 0) \
> + goto bad_fork_cleanup; \
> + } \
> +} while(0)
Goto a label defined elsewhere, buried in a macro. Please code this
openly.
> +#define detach_pagg_list_chk(t) \
> +do { \
> + if (!list_empty(&t->pagg_list.head)) { \
> + detach_pagg_list(t); \
> + } \
> +} while(0)
All these macros could be type safe inlined functions, and when config'd
off, use your alt. no-op macros.
> +#define read_lock_pagg_list(t) down_read(&t->pagg_list.sem)
> + /* Up the read semaphore for the task's pagg_list */
> +#define read_unlock_pagg_list(t) up_read(&t->pagg_list.sem)
> + /* Down the write semaphore for the task's pagg_list */
> +#define write_lock_pagg_list(t) down_write(&t->pagg_list.sem)
> + /* Up the write semaphore for the task's pagg_list */
> +#define write_unlock_pagg_list(t) up_write(&t->pagg_list.sem)
Just open code these. There's too much hidden in macros.
> @@ -488,11 +489,15 @@
>
> struct dentry *proc_dentry;
> struct backing_dev_info *backing_dev_info;
> -
> struct io_context *io_context;
>
> unsigned long ptrace_message;
> siginfo_t *last_siginfo; /* For ptrace use. */
> +
> +#if defined(CONFIG_PAGG)
> +/* List of pagg (process aggregate) attachments */
> + struct pagg_list pagg_list;
> +#endif
unused?
> +unregister_pagg_hook(struct pagg_hook *pagg_hook_old)
<snip>
> + down_write(&pagg_hook_list_sem);
> +
> + pagg_hook = get_pagg_hook(pagg_hook_old->name);
> + if (pagg_hook && pagg_hook == pagg_hook_old) {
> + /*
> + * Scan through processes on system and check for
> + * references to pagg containers for this pagg hook.
> + *
> + * The module cannot be unloaded if there are references.
> + */
> + read_lock(&tasklist_lock);
> + for_each_process(task) {
> + struct pagg *pagg = NULL;
> +
> + read_lock_pagg_list(task);
Uh-oh, grabbing a semaphore while holding tasklist_lock.
There's too much hidden in macros (like read_lock_pagg_list).
> +attach_pagg_list(struct task_struct *to_task, struct task_struct *from_task)
<snip>
> + to_pagg = alloc_pagg(to_task, from_pagg->hook);
> + if (!to_pagg) {
> + retcode = -ENOMEM;
> + goto error_return;
> + }
> + retcode = attach_pagg(to_task, to_pagg, from_pagg->data);
> + if (retcode != 0) {
> + /* attach should issue error message */
> + goto error_return;
> + }
This looks like it leaks the just alloc'd to_pagg.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
next prev parent reply other threads:[~2004-04-26 23:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-26 22:04 Erik Jacobson
2004-04-26 23:39 ` Chris Wright [this message]
2004-04-27 0:36 ` Jesse Barnes
2004-04-27 0:41 ` Chris Wright
2004-04-27 21:00 ` Erik Jacobson
2004-04-27 21:05 ` Chris Wright
2004-04-29 21:10 ` Rik van Riel
2004-04-27 20:51 ` Erik Jacobson
2004-04-27 22:28 ` Chris Wright
2004-04-28 14:55 ` Christoph Hellwig
2004-04-29 19:20 ` Paul Jackson
2004-04-29 19:27 ` Chris Wright
2004-04-29 19:29 ` Christoph Hellwig
2004-04-29 19:34 ` Paul Jackson
2004-04-29 19:53 ` Erik Jacobson
2004-04-29 21:20 ` Rik van Riel
2004-04-30 6:17 ` Christoph Hellwig
2004-04-30 11:08 ` Guillaume Thouvenin
2004-04-30 18:00 ` Shailabh
2004-04-30 18:28 ` Rik van Riel
2004-04-30 12:54 ` Rik van Riel
2004-04-30 13:06 ` Christoph Hellwig
2004-04-30 13:28 ` Chris Mason
2004-04-30 16:50 ` Shailabh
2004-04-30 15:22 ` Rik van Riel
2004-04-30 16:45 ` Christoph Hellwig
2004-04-30 17:53 ` Shailabh
2004-04-30 18:15 ` Chris Wright
2004-04-30 15:59 ` Chris Wright
2004-04-30 8:54 ` Guillaume Thouvenin
2004-05-20 21:16 ` Erik Jacobson
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=20040426163955.X21045@build.pdx.osdl.net \
--to=chrisw@osdl.org \
--cc=erikj@subway.americas.sgi.com \
--cc=linux-kernel@vger.kernel.org \
/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
Powered by JetHome