From: Paul Menage <menage@google.com>
To: linux-kernel@vger.kernel.org,
containers@lists.linux-foundation.org, lizf@cn.fujitsu.com,
akpm@linux-foundation.org, menage@google.com
Cc: bblum@andrew.cmu.edu
Subject: Re: [RFC][PATCH 2/3] cgroups: subsystem module interface
Date: Wed, 4 Nov 2009 13:18:34 -0800 [thread overview]
Message-ID: <6599ad830911041318n3a07ef3dgd18dac00c772eeaf@mail.gmail.com> (raw)
In-Reply-To: <20091104203024.GA14471@andrew.cmu.edu>
On Wed, Nov 4, 2009 at 12:30 PM, Ben Blum <bblum@andrew.cmu.edu> wrote:
>> + init_cgroup_css(css, ss, dummytop);
>> + init_css_set.subsys[ss->subsys_id] = dummytop->subsys[ss->subsys_id];
>
> There is a problem here; namely, the init_css_set is supposed to be
> immutable after boot. Putting a new subsystem state in it seems like it
> will be impossible to get right, since a hierarchy might be mounted and
> already using the init_css_set. Perhaps it would be better to use
> find_css_set for this?
Hmm, it's not just init_css_set that needs to get a pointer to the new
css, it's all existing css_sets - since every task has to start off in
the root cgroup for the new subsystem. A css_set is just a flattened
cache of the css pointers from all the cgroups that a task is a member
of, so when we add a css pointer to the unmount cgroup, we need to
either update all css_set objects, or else run through every task in
the system and update its cgroups pointer to a new css_set that's
equivalent to its old css_set plus the new css pointer.
Given the races inherent in trying to find and update all tasks in the
system, I think the cleanest way to solve this is:
- copy the css_set_table hash table and clear the original table.
- for each bucket in the hash table:
- for each css_set in the bucket:
- add the new root css to the css_set
- rehash the css_set into the hash table
Unfortunately this issue also makes it a bit harder to support
modular-subsystem unloading.
Paul
next prev parent reply other threads:[~2009-11-04 21:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-02 21:28 [RFC][PATCH 0/3] cgroups: support for module-loadable subsystems Ben Blum
2009-11-02 21:29 ` [RFC][PATCH 1/3] cgroups: revamp subsys array Ben Blum
2009-11-02 21:30 ` [RFC][PATCH 2/3] cgroups: subsystem module interface Ben Blum
2009-11-04 20:30 ` Ben Blum
2009-11-04 21:18 ` Paul Menage [this message]
2009-11-02 21:31 ` [RFC][PATCH 3/3] cgroups: net_cls subsys as module Ben Blum
2009-11-02 21:46 ` Randy Dunlap
2009-11-03 2:03 ` [RFC][PATCH 0/3] cgroups: support for module-loadable subsystems Li Zefan
2009-11-03 2:11 ` Paul Menage
2009-11-03 2:42 ` Li Zefan
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=6599ad830911041318n3a07ef3dgd18dac00c772eeaf@mail.gmail.com \
--to=menage@google.com \
--cc=akpm@linux-foundation.org \
--cc=bblum@andrew.cmu.edu \
--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®