Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1160973 > unrolled thread

Re: [PATCH v13 4/5] cgroup: allow a cgroup subsystem to reject a fork

Started byTejun Heo <tj@kernel.org>
First post2015-06-09 06:50 +0200
Last post2015-06-09 09:30 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH v13 4/5] cgroup: allow a cgroup subsystem to reject a fork Tejun Heo <tj@kernel.org> - 2015-06-09 06:50 +0200
    Re: [PATCH v13 4/5] cgroup: allow a cgroup subsystem to reject a fork Aleksa Sarai <cyphar@cyphar.com> - 2015-06-09 09:30 +0200
      Re: [PATCH v13 4/5] cgroup: allow a cgroup subsystem to reject a fork Tejun Heo <tj@kernel.org> - 2015-06-09 09:30 +0200

#1160973 — Re: [PATCH v13 4/5] cgroup: allow a cgroup subsystem to reject a fork

FromTejun Heo <tj@kernel.org>
Date2015-06-09 06:50 +0200
SubjectRe: [PATCH v13 4/5] cgroup: allow a cgroup subsystem to reject a fork
Message-ID<pzjE5-4hu-1@gated-at.bofh.it>
Hello, Aleksa.

Looks pretty good to me in general.  Some minor comments below.

On Sat, Jun 06, 2015 at 10:02:17AM +1000, Aleksa Sarai wrote:

> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index a593e29..17d0046 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -62,9 +62,15 @@ int proc_cgroup_show(struct seq_file *m, struct pid_namespace *ns,
>                      struct pid *pid, struct task_struct *tsk);

>  void cgroup_fork(struct task_struct *p);
> -void cgroup_post_fork(struct task_struct *p);
> +extern int cgroup_can_fork(struct task_struct *p,
> +                          void *ss_priv[CGROUP_CANFORK_COUNT]);
> +extern void cgroup_cancel_fork(struct task_struct *p,
> +                              void *ss_priv[CGROUP_CANFORK_COUNT]);
> +extern void cgroup_post_fork(struct task_struct *p,
> +                            void *old_ss_priv[CGROUP_CANFORK_COUNT]);
>  void cgroup_exit(struct task_struct *p);
> 
> +

Is this blank line intentional?

>  int cgroup_init_early(void);
>  int cgroup_init(void);
...
> @@ -4924,6 +4927,7 @@ static void __init cgroup_init_subsys(struct cgroup_subsys *ss, bool early)
>  
>  	have_fork_callback |= (bool)ss->fork << ss->id;
>  	have_exit_callback |= (bool)ss->exit << ss->id;
> +	have_canfork_callback |= (bool)ss->can_fork << ss->id;

Hmmm.... do we still need this mask?  We're already restricting
iteration pretty heavily.  I'd even suggest dropping both
have_fork_callback and have_exit_callback too and just put them inside
CGROUP_FORK_EXIT_START / STOP although that doesn't belong in this
patchset.

...
> +static void *subsys_canfork_priv(void *ss_priv[CGROUP_CANFORK_COUNT], int i)
> +{
> +	void **private;
> +	if ((private = subsys_canfork_priv_p(ss_priv, i)) != NULL)
> +		return *private;
> +	return NULL;
> +}

	void **private = subsys_canfork...;

	if (private)
		return *private;
	return NULL;

or even just

	return private ? *private : NULL;

We conventionally don't put assignments in if conditionals.

> +void cgroup_cancel_fork(struct task_struct *child,
> +			void *ss_priv[CGROUP_CANFORK_COUNT])
> +{
> +	struct cgroup_subsys *ss;
> +	int i;
> +
> +	for_each_subsys(ss, i)
> +		if(ss->cancel_fork)
                  ^
		  space

> +			ss->cancel_fork(child, subsys_canfork_priv(ss_priv, i));
> +}
> +
> +/**
>   * cgroup_post_fork - called on a new task after adding it to the task list
>   * @child: the task in question
>   *

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/

[toc] | [next] | [standalone]


#1161086

FromAleksa Sarai <cyphar@cyphar.com>
Date2015-06-09 09:30 +0200
Message-ID<pzm8V-83c-7@gated-at.bofh.it>
In reply to#1160973
>> @@ -4924,6 +4927,7 @@ static void __init cgroup_init_subsys(struct cgroup_subsys *ss, bool early)
>>
>>       have_fork_callback |= (bool)ss->fork << ss->id;
>>       have_exit_callback |= (bool)ss->exit << ss->id;
>> +     have_canfork_callback |= (bool)ss->can_fork << ss->id;
>
> Hmmm.... do we still need this mask?  We're already restricting
> iteration pretty heavily.

CGROUP_CANFORK_{START,END,COUNT} aren't used to restrict the
iteration. They're used for restricting the size of the @ss_priv
array. If you want, I can use CANFORK_{START,END} to restrict the
iteration -- I just prefer using the for_each_subsys_which API for
iterating over active cgroups. :/

--
Aleksa Sarai (cyphar)
www.cyphar.com
--
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/

[toc] | [prev] | [next] | [standalone]


#1161092

FromTejun Heo <tj@kernel.org>
Date2015-06-09 09:30 +0200
Message-ID<pzm8X-83c-21@gated-at.bofh.it>
In reply to#1161086
Hello,

On Tue, Jun 9, 2015 at 4:20 PM, Aleksa Sarai <cyphar@cyphar.com> wrote:
> CGROUP_CANFORK_{START,END,COUNT} aren't used to restrict the
> iteration. They're used for restricting the size of the @ss_priv
> array. If you want, I can use CANFORK_{START,END} to restrict the
> iteration -- I just prefer using the for_each_subsys_which API for
> iterating over active cgroups. :/

Ah, I see.  Hmm... yeah, let's keep the code for now, but I think it'd
be cheaper / cleaner to use those macro tags to restrict iteration and
drop all the masks in the future.

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/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web