Messages in this thread | | | Date | Mon, 24 Jan 2011 10:32:28 -0500 | From | Ben Blum <> | Subject | Re: [PATCH v7 2/3] cgroups: add atomic-context per-thread subsystem callbacks |
| |
On Mon, Jan 24, 2011 at 12:38:06AM -0800, Paul Menage wrote: > Hi Ben, > > Finally finding a moment to actually look at these patches. Sorry it's > been a while. Can you send the patches inline rather than as > attachments in future?
Whoops, sure thing.
> > Reviewed-by: Paul Menage <menage@google.com> > > This patch looks fine, although I think that freezer_can_attach_task() > could be simplified to: > > static int freezer_can_attach_task(struct cgroup *cgrp, struct task_struct *tsk) > { > if (__cgroup_freezing_or_frozen(tsk)) > return -EBUSY; > return 0; > } > > since we guarantee that rcu_read_lock() is held across this call.
I put a note there that "rcu_read_lock allows recursive locking", to denote that it's okay to double-lock when it's called from cgroup_attach_proc. I guess this isn't very clear: the reason the lock is there is because in cgroup_attach_task, I call it without rcu_read_lock (not necessary in most cases), but freezer needs RCU there in either case. I wrote in the documentation: "This may run in rcu_read-side", which I guess isn't very clear either.
> > There appears to be a tiny bit of rot in kernel/cpu.c (due to the > addition of the exit() callback) and memcontrol.c (due to some changes > at the start of mem_cgroup_move_task()) but neither impact actual > code. > > I think that before actually pushing to mainline, we'll need to sort > out the cpuset mempolicy yielding issue, since that could be a > user-visible API change. > > > Paul
Hmm. The quirks caused by this are specific to using cgroup.procs, and since cgroup.procs is new, I wouldn't say this is an API "change"?
Thanks, Ben
| |