Re: [PATCH v10 3/4] cgroups: allow a cgroup subsystem to reject a fork

From: Tejun Heo <tj@kernel.org>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: lizefan@huawei.com, mingo@redhat.com,
	"Peter Zijlstra" <peterz@infradead.org>,
	richard@nod.at, "Frédéric Weisbecker" <fweisbec@gmail.com>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH v10 3/4] cgroups: allow a cgroup subsystem to reject a fork
Date: Thu, 14 May 2015 11:08:28 -0400	[thread overview]
Message-ID: <20150514150828.GG11388@htj.duckdns.org> (raw)
In-Reply-To: <CAOviyajt2MSG_N6VOOXwAM8YZ0ReCvgXyyvaj2yPYK2dztv8EA@mail.gmail.com>

Hello, Aleksa.

On Thu, May 14, 2015 at 08:57:49PM +1000, Aleksa Sarai wrote:
> >> +/* Ditto for the can_fork/cancel_fork/reapply_fork callbacks. */
> >> +static int need_canfork_callback __read_mostly;
> >> +static int need_cancelfork_callback __read_mostly;
> >
> > And given that the reason we have these masks is avoiding iteration in
> > relatively hot paths.  Does cancelfork mask make sense?
> 
> Do you still want me to remove it? I only added it because it made the
> callback code more consistent for cancel_fork and can_fork.

This doesn't make much sense to me.  Why don't we have masks for other
callbacks then?  This way, we're breaking the consistency regarding
why the mask is used in the first place.

> > Maybe we want a helper callback which does
> >
> >         if (CGROUP_PREFORK_START <= ssid && ssid < CGROUP_PREFORK_END)
> >                 return &ss_state[ssid - CGROUP_PREFORK_START];
> >         return NULL;
> 
> What would be a nice name for it? I can't think of anything better
> than __get_ss_private() and __get_ss_privatep().

Do we need the double underscores?  subsys_prefork_priv()?

Thanks.

-- 
tejun