From: Paul Menage <menage@google.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: akpm@linux-foundation.org, containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] Support named cgroups hierarchies
Date: Wed, 22 Jul 2009 23:27:23 -0700 [thread overview]
Message-ID: <6599ad830907222327s31340956y9783db39d076520f@mail.gmail.com> (raw)
In-Reply-To: <4A68013A.2020302@cn.fujitsu.com>
On Wed, Jul 22, 2009 at 11:20 PM, Li Zefan<lizf@cn.fujitsu.com> wrote:
>> +The name should match [\w.-]+
>> +
>
> "[\w._-]+" ?
>
> But I double we need to check this.
\w includes '_'
>> static int cgroup_set_super(struct super_block *sb, void *data)
>> {
>> int ret;
>> - struct cgroupfs_root *root = data;
>> + struct cgroup_sb_opts *opts = data;
>> +
>> + /* If we don't have a new root, we can't set up a new sb */
>> + if (!opts->new_root)
>> + return -EINVAL;
>> +
>
> I think this should be BUG_ON(). If set_super() is called,
> we are allocating a new root, so opts->new_root won't be NULL.
Not true - if you try to mount a hierarchy by name, but with no
subsystem options, then we don't construct a new root, but we still
call sget(). If we find a superblock with the right name then we use
it, else sget() will allocate a new superblock and call
cgroup_set_super(), at which point we need to fail.
>
>> + struct cgroupfs_root *new_root = cgroup_root_from_opts(&opts);
>
> Why not just declare new_root in the beginning of cgroup_get_sb()?
Because it's not needed for the entire scope of the function. Keeping
its scope as small as possible makes it clearer what it's being used
for.
Paul
next prev parent reply other threads:[~2009-07-23 6:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-22 19:50 [PATCH 0/4] CGroup: Support for named and empty hierarchies Paul Menage
2009-07-22 19:50 ` [PATCH 1/4] Support named cgroups hierarchies Paul Menage
2009-07-23 6:20 ` Li Zefan
2009-07-23 6:27 ` Paul Menage [this message]
2009-07-23 6:50 ` Li Zefan
2009-07-28 23:17 ` Paul Menage
2009-07-23 6:47 ` KAMEZAWA Hiroyuki
2009-07-22 19:50 ` [PATCH 2/4] Move the cgroup debug subsys into cgroup.c to access internal state Paul Menage
2009-07-23 6:21 ` Li Zefan
2009-07-23 6:51 ` KAMEZAWA Hiroyuki
2009-07-22 19:50 ` [PATCH 3/4] Add a back-pointer from struct cg_cgroup_link to struct cgroup Paul Menage
2009-07-23 6:44 ` Li Zefan
2009-07-23 14:31 ` Paul Menage
2009-07-22 19:50 ` [PATCH 4/4] Allow cgroup hierarchies to be created with no bound subsystems Paul Menage
2009-07-23 8:19 ` KAMEZAWA Hiroyuki
2009-07-23 8:32 ` Li Zefan
2009-07-24 5:21 ` Li Zefan
2009-07-23 5:13 ` [PATCH 0/4] CGroup: Support for named and empty hierarchies KAMEZAWA Hiroyuki
2009-07-23 5:37 ` Paul Menage
2009-07-23 5:45 ` KAMEZAWA Hiroyuki
2009-07-28 23:26 Paul Menage
2009-07-28 23:26 ` [PATCH 1/4] Support named cgroups hierarchies Paul Menage
2009-07-29 10:43 ` Dhaval Giani
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=6599ad830907222327s31340956y9783db39d076520f@mail.gmail.com \
--to=menage@google.com \
--cc=akpm@linux-foundation.org \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
/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
all inboxes | Powered by JetHome®