Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752787AbbDAQDG (ORCPT ); Wed, 1 Apr 2015 12:03:06 -0400 Received: from mail-qc0-f170.google.com ([209.85.216.170]:35639 "EHLO mail-qc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752042AbbDAQDD (ORCPT ); Wed, 1 Apr 2015 12:03:03 -0400 Date: Wed, 1 Apr 2015 12:02:58 -0400 From: Tejun Heo To: Aleksa Sarai Cc: lizefan@huawei.com, mingo@redhat.com, peterz@infradead.org, richard@nod.at, fweisbec@gmail.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH v8 3/4] cgroups: allow a cgroup subsystem to reject a fork Message-ID: <20150401160258.GP9974@htj.duckdns.org> References: <1427878641-5273-1-git-send-email-cyphar@cyphar.com> <1427878641-5273-4-git-send-email-cyphar@cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1427878641-5273-4-git-send-email-cyphar@cyphar.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3066 Lines: 108 Hello, Aleksa. On Wed, Apr 01, 2015 at 07:57:20PM +1100, Aleksa Sarai wrote: > +struct cgroup_fork_state { > + void *ss_state[CGROUP_SUBSYS_COUNT]; > +}; Can we collect the subsystems which require pre/post fork callbacks to the front in group_subsys.h and do do CGROUP_SUBSYS_FORK_COUNT (or whatever) instead? Then, we don't need all these subsys bitmasks either we can just test the index against that and be done with it. > + > +/** > + * cgroup_cfs_alloc - allocates an empty cgroup_fork_state > + */ > +struct cgroup_fork_state *cgroup_cfs_alloc(void) > +{ > + struct cgroup_fork_state *cfs; > + > + cfs = kzalloc(sizeof(struct cgroup_fork_state), GFP_KERNEL); > + if (!cfs) > + return ERR_PTR(-ENOMEM); > + > + return cfs; > +} Just make it a void * array and put it on stack. Abstraction at this level doesn't serve any purpose. No controller code is gonna see this anyway. > +int cgroup_can_fork(struct task_struct *child, struct cgroup_fork_state *cfs) > +{ > + struct cgroup_subsys *ss; > + int i, j, retval; > + > + for_each_subsys_which(need_canfork_callback, ss, i) { > + retval = ss->can_fork(child, &cfs->ss_state[i]); > + if (retval) > + goto out_revert; > + } > + > + return 0; > + > +out_revert: > + for_each_subsys_which(need_cancelfork_callback, ss, j) { > + if (j >= i) > + break; > + ss->cancel_fork(child, &cfs->ss_state[i]); cancel_fork() has no reason to update the opaque pointer. No reason to pass pointer of it. > +void cgroup_cancel_fork(struct task_struct *child, struct cgroup_fork_state *cfs) > +{ > + struct cgroup_subsys *ss; > + int i; > + > + for_each_subsys_which(need_cancelfork_callback, ss, i) { > + void **state = NULL; > + > + /* > + * Only if %ss has a can_fork() callback is %cfs->ss_state[i] meaningful I don't think we do %var, do we? % is used for macros and consts. > + * -- otherwise just pass a NULL. > + */ > + if (need_canfork_callback & (1 << i)) > + state = &cfs->ss_state[i]; > + > + ss->cancel_fork(child, &cfs->ss_state[i]); Ditto, just pass the pointer itself. > @@ -5241,8 +5346,18 @@ void cgroup_post_fork(struct task_struct *child) > * css_set; otherwise, @child might change state between ->fork() > * and addition to css_set. > */ > - for_each_subsys_which(need_fork_callback, ss, i) > - ss->fork(child); > + for_each_subsys_which(need_fork_callback, ss, i) { > + void **state = NULL; > + > + /* > + * Only if %ss has a can_fork() callback is %old_cfs->ss_state[i] > + * meaningful -- otherwise just pass a NULL. > + */ Again, if you just passed the pointer, you wouldn't need the above. Just clear the array on init and pass in whatever value is in there. > + if (need_canfork_callback & (1 << i)) > + state = &old_cfs->ss_state[i]; > + > + ss->fork(child, state); > + } > } Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/