Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
On Fri, Mar 27, 2015 at 08:41:05AM +1100, Aleksa Sarai wrote: > > You can't pin css_set from inside cgroup callbacks. It's a construct > > which in general shouldn't be accessible outside cgroup core. > > Yeah, sorry I meant css (you aren't pinning, but you're still saving under RCU > and dealing with the association-related stuff inside post_fork). How would that work without pinning? What'd keep the css from going away between pre and post? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
Hi, >> callback if the association changes [we could call it something else if you >> like, since reapply_fork() is a pids-specific name -- what about >> switch_fork(), >> reassoc_fork(), re_fork() or something to show that it's a callback if the >> association changes?] (the subsystem can decide if they want to ignore it / >> if >> they don't want to touch it) and we deal with pinning / dropping the ref of >> the >> css_set for the current task inside the cgroup_* callbacks. That way, we >> don't >> start messing around with post-fork() callbacks that aren't related to the >> new >> conditional stuff. > > You can't pin css_set from inside cgroup callbacks. It's a construct > which in general shouldn't be accessible outside cgroup core. Yeah, sorry I meant css (you aren't pinning, but you're still saving under RCU and dealing with the association-related stuff inside post_fork). >> I mean, if you want to have a random, completely unused and essentially >> vestigial argument to ss->fork() [if you don't use the new can_fork() >> callbacks >> (and actually care about storing private data)] then I can just write that. >> It >> just looks like a weird callback API imho. > > It's an opaque token from pre. If a subsys doesn't have pre, it's > NULL. I don't see anything weird about that, so let's please go that > way. Alright, if you think that's the best way. I still think it's weird, but I guess that's probably just down to personal taste. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
On Sat, Mar 21, 2015 at 10:25:56PM +1100, Aleksa Sarai wrote: > > Also, what pins the cset between task_css_set() and get_css_set()? > > task_css_set() is protected by RCU and the above should have triggered > > RCU warning if the debug option is enabled. Please always test with > > the debug options enabled, especially the lockdep and RCU ones. > > Debug was enabled AFAIK and I didn't get anything in `dmesg`. I've fixed it > anyway. So, this is worrying. If you have RCU debugging enabled, it should have triggered the warning. If it hadn't, maybe there's something else protecting it and we don't need the extra rcu locking around it. Can you please investigate what's going on? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
Hello, On Fri, Mar 27, 2015 at 01:38:54AM +1100, Aleksa Sarai wrote: > The issue I can see with passing around an opaque pointer to fork() is that > you > have a random private (void **) argument that is completely useless if you > don't use can_fork(). This is why I think we should call the reapply_fork() Just pass NULL? I really don't like having another callback. pre and post do make sense because the operation is essentially a transaction. The problem with adding additional callbacks is that they aren't essential and as such arbitrary to a certain degree. reapply_fork or whatnot may fit this case but may not others, so let's please stick with what the logic dictates to be essential. > callback if the association changes [we could call it something else if you > like, since reapply_fork() is a pids-specific name -- what about > switch_fork(), > reassoc_fork(), re_fork() or something to show that it's a callback if the > association changes?] (the subsystem can decide if they want to ignore it / if > they don't want to touch it) and we deal with pinning / dropping the ref of > the > css_set for the current task inside the cgroup_* callbacks. That way, we don't > start messing around with post-fork() callbacks that aren't related to the new > conditional stuff. You can't pin css_set from inside cgroup callbacks. It's a construct which in general shouldn't be accessible outside cgroup core. > I mean, if you want to have a random, completely unused and essentially > vestigial argument to ss->fork() [if you don't use the new can_fork() > callbacks > (and actually care about storing private data)] then I can just write that. It > just looks like a weird callback API imho. It's an opaque token from pre. If a subsys doesn't have pre, it's NULL. I don't see anything weird about that, so let's please go that way. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
Hi Tejun, Here's a bit more of a follow-up on two of your points: Since > Do we really need a separate callback for this? Can't we just add > @old_css param to ss->fork() which is NULL if it didn't change since > can_fork()? and > Did you explore the idea of passing an opaque pointer from can_fork to > post_fork? If so, why did you choose this direction instead of that > one? Are quite similar (they essentially both result in each other, since if you use void pointers for state you can't check if the association changed without doing completely separate accounting which wouldn't be used by the callbacks), I'll respond to both in the same go: The issue I can see with passing around an opaque pointer to fork() is that you have a random private (void **) argument that is completely useless if you don't use can_fork(). This is why I think we should call the reapply_fork() callback if the association changes [we could call it something else if you like, since reapply_fork() is a pids-specific name -- what about switch_fork(), reassoc_fork(), re_fork() or something to show that it's a callback if the association changes?] (the subsystem can decide if they want to ignore it / if they don't want to touch it) and we deal with pinning / dropping the ref of the css_set for the current task inside the cgroup_* callbacks. That way, we don't start messing around with post-fork() callbacks that aren't related to the new conditional stuff. I mean, if you want to have a random, completely unused and essentially vestigial argument to ss->fork() [if you don't use the new can_fork() callbacks (and actually care about storing private data)] then I can just write that. It just looks like a weird callback API imho. In fact, it seems even more single purpose than just pinning the ref and dealing with it for the general case of an association switching (because now you have a single-purpose parameter to the general fork() call, as opposed to doing some ref pinning and accounting of the current css_set for (currently) only the pids subsystem in the cgroup core. Since we know that pids will need to pin the ref, then we're not doing any extra work in doing it for the general cgroup fork callback -- and we get to both separate "association changed" logic from "post fork" logic in the callbacks, as well as not blindly trusting the cgroup subsystem to properly deal with a changing association. -- Aleksa Sarai (cyphar) www.cyphar.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
Hi Tejun,
>> +int cgroup_can_fork(struct task_struct *child, void **state)
>> +{
>> + struct cgroup_subsys *ss;
>> + struct css_set *cset;
>> + int i, j, retval;
>> +
>> + cset = task_css_set(current);
>> + get_css_set(cset);
>
> So, you stuck with css_set refcnting. That's fine, but please do
> finish discussing in the original thread instead of throwing out new
> version without explaining why you reached a particular conclusion.
> Did you explore the idea of passing an opaque pointer from can_fork to
> post_fork? If so, why did you choose this direction instead of that
> one?
The reason for using css_set is for future-proofness. If we stick with just
passing around the css, then we'd be stuck with only working with one
particular cgroup subsystem (and it would also make the code unwieldy). I'll
post this to that thread too, but the main reason is that it would make the
generic callback pids-specific.
> Also, what pins the cset between task_css_set() and get_css_set()?
> task_css_set() is protected by RCU and the above should have triggered
> RCU warning if the debug option is enabled. Please always test with
> the debug options enabled, especially the lockdep and RCU ones.
Debug was enabled AFAIK and I didn't get anything in `dmesg`. I've fixed it
anyway.
>> + *state = cset;
>
> There's no reason for css_set pointer to be passed around as an opaque
> pointer. The type is fixed. I suppose this is from me mentioning
> void pointer in the previous thread but that was about the cpuset
> can_fork() implementation returning its css pointer, not css_set.
> Please conclude discussions before working on the following version.
Yes, I misunderstood what you wanted the opaque pointer to point to. But I had
thought of doing it like that before, and decided against it for the reasons
outlined above.
>> @@ -5249,6 +5315,24 @@ void cgroup_post_fork(struct task_struct *child)
>> }
>>
>> /*
>> + * Deal with tasks that were migrated mid-fork. If the css_set
>> + * changed between can_fork() and post_fork() an organisation
>> + * operation has occurred, and we need to revert/reapply the
>> + * the can_fork().
>> + */
>> + for_each_subsys_which(need_canfork_callback, ss, i) {
>> + struct cgroup_subsys_state *css = cset->subsys[i],
>> +*old_css = old_cset->subsys[i];
>> +
>> + /*
>> + * We only reapply for subsystems whose
>> + * association changed in the interim.
>> + */
>> + if (old_css != css && ss->reapply_fork)
>> + ss->reapply_fork(css, old_css, child);
>> + }
>
> Do we really need a separate callback for this? Can't we just add
> @old_css param to ss->fork() which is NULL if it didn't change since
> can_fork()?
I feel that reapply_fork() being a special case of fork() (or vice versa) just
feels like a weird API. The two actions are fundamentally different -- one is
basically confirming that the fork went through and the other is alerting the
subsystem that the association changed during a fork.
--
Aleksa Sarai (cyphar)
www.cyphar.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
Hello, Aleksa.
On Sat, Mar 14, 2015 at 03:37:14PM +1100, Aleksa Sarai wrote:
> +/* Ditto for the can_fork/cancel_fork/reapply_fork callbacks. */
> +static int need_canfork_callback __read_mostly = 0,
> +need_reapplyfork_callback __read_mostly = 0;
Please separate the two definitions. Please consult
Documentation/CodingStyle and in general try not to be creative with
style.
> +int cgroup_can_fork(struct task_struct *child, void **state)
> +{
> + struct cgroup_subsys *ss;
> + struct css_set *cset;
> + int i, j, retval;
> +
> + cset = task_css_set(current);
> + get_css_set(cset);
So, you stuck with css_set refcnting. That's fine, but please do
finish discussing in the original thread instead of throwing out new
version without explaining why you reached a particular conclusion.
Did you explore the idea of passing an opaque pointer from can_fork to
post_fork? If so, why did you choose this direction instead of that
one?
Also, what pins the cset between task_css_set() and get_css_set()?
task_css_set() is protected by RCU and the above should have triggered
RCU warning if the debug option is enabled. Please always test with
the debug options enabled, especially the lockdep and RCU ones.
> + *state = cset;
There's no reason for css_set pointer to be passed around as an opaque
pointer. The type is fixed. I suppose this is from me mentioning
void pointer in the previous thread but that was about the cpuset
can_fork() implementation returning its css pointer, not css_set.
Please conclude discussions before working on the following version.
> @@ -5249,6 +5315,24 @@ void cgroup_post_fork(struct task_struct *child)
> }
>
> /*
> + * Deal with tasks that were migrated mid-fork. If the css_set
> + * changed between can_fork() and post_fork() an organisation
> + * operation has occurred, and we need to revert/reapply the
> + * the can_fork().
> + */
> + for_each_subsys_which(need_canfork_callback, ss, i) {
> + struct cgroup_subsys_state *css = cset->subsys[i],
> +*old_css = old_cset->subsys[i];
> +
> + /*
> + * We only reapply for subsystems whose
> + * association changed in the interim.
> + */
> + if (old_css != css && ss->reapply_fork)
> + ss->reapply_fork(css, old_css, child);
> + }
Do we really need a separate callback for this? Can't we just add
@old_css param to ss->fork() which is NULL if it didn't change since
can_fork()?
> @@ -1196,6 +1196,7 @@ static struct task_struct *copy_process(unsigned long
> clone_flags,
> {
> int retval;
> struct task_struct *p;
> + void *cfs;
If we're gonna do css_set, there's no need to make this an opaque
pointer.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/3] cgroups: allow a cgroup subsystem to reject a fork
Add a new cgroup subsystem callback can_fork that conditionally
states whether or not the fork is accepted or rejected by a cgroup
policy.
In addition, add a cancel_fork callback so that if an error occurs later
in the forking process, any state modified by can_fork can be reverted.
In order to ensure that the fork charged the right hierarchy, save the
"current" css_set before doing ss->can_fork and compare it with the
"current" css_set that gets committed to the task *proper* in post_fork.
If they do not match, revert the can_fork's charging of the wrong
hierarchy and forcefully reapply it to the right hierarchy using the
reapply_fork callback. Since a changing "current" css_set in
copy_process indicates an organisation operation took place, we can
break the cgroup policy in this case.
This is in preparation for implementing the pids cgroup subsystem.
Signed-off-by: Aleksa Sarai
---
include/linux/cgroup.h | 13 ++-
kernel/cgroup.c| 92 --
kernel/fork.c | 18 --
3 files changed, 117 insertions(+), 6 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index b9cb94c..9592f6e 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -32,7 +32,9 @@ struct cgroup;
extern int cgroup_init_early(void);
extern int cgroup_init(void);
extern void cgroup_fork(struct task_struct *p);
-extern void cgroup_post_fork(struct task_struct *p);
+extern int cgroup_can_fork(struct task_struct *p, void **state);
+extern void cgroup_cancel_fork(struct task_struct *p, void **state);
+extern void cgroup_post_fork(struct task_struct *p, void **old_state);
extern void cgroup_exit(struct task_struct *p);
extern int cgroupstats_build(struct cgroupstats *stats,
struct dentry *dentry);
@@ -649,6 +651,13 @@ struct cgroup_subsys {
struct cgroup_taskset *tset);
void (*attach)(struct cgroup_subsys_state *css,
struct cgroup_taskset *tset);
+ int (*can_fork)(struct cgroup_subsys_state *css,
+ struct task_struct *task);
+ void (*cancel_fork)(struct cgroup_subsys_state *css,
+ struct task_struct *task);
+ void (*reapply_fork)(struct cgroup_subsys_state *css,
+struct cgroup_subsys_state *old_css,
+struct task_struct *task);
void (*fork)(struct task_struct *task);
void (*exit)(struct cgroup_subsys_state *css,
struct cgroup_subsys_state *old_css,
@@ -948,6 +957,8 @@ struct cgroup_subsys_state;
static inline int cgroup_init_early(void) { return 0; }
static inline int cgroup_init(void) { return 0; }
static inline void cgroup_fork(struct task_struct *p) {}
+static inline int cgroup_can_fork(struct task_struct *p) { return 0; }
+static inline void cgroup_cancel_fork(struct task_struct *p) {}
static inline void cgroup_post_fork(struct task_struct *p) {}
static inline void cgroup_exit(struct task_struct *p) {}
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index d60107e..1a77790 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -183,6 +183,10 @@ static u64 css_serial_nr_next = 1;
*/
static int need_forkexit_callback __read_mostly;
+/* Ditto for the can_fork/cancel_fork/reapply_fork callbacks. */
+static int need_canfork_callback __read_mostly = 0,
+ need_reapplyfork_callback __read_mostly = 0;
+
static struct cftype cgroup_dfl_base_files[];
static struct cftype cgroup_legacy_base_files[];
@@ -4947,6 +4951,8 @@ static void __init cgroup_init_subsys(struct
cgroup_subsys *ss, bool early)
init_css_set.subsys[ss->id] = css;
need_forkexit_callback |= !!(ss->fork || ss->exit) << ss->id;
+ need_canfork_callback |= !!(ss->can_fork || ss->cancel_fork) << ss->id;
+ need_reapplyfork_callback |= !!(ss->reapply_fork) << ss->id;
/* At system boot, before all subsystems have been
* registered, no tasks have been forked, so we don't
@@ -5200,6 +5206,66 @@ void cgroup_fork(struct task_struct *child)
}
/**
+ * cgroup_can_fork - called on a new task before the process is exposed.
+ * @child: the task in question.
+ *
+ * This calls the subsystem can_fork() callbacks. If the can_fork() callback
+ * returns an error, the fork aborts with that error code. This allows for
+ * a cgroup subsystem to conditionally allow or deny new forks.
+ */
+int cgroup_can_fork(struct task_struct *child, void **state)
+{
+ struct cgroup_subsys *ss;
+ struct css_set *cset;
+ int i, j, retval;
+
+ cset = task_css_set(current);
+ get_css_set(cset);
+ *state = cset;
+
+ for_each_subsys_which(need_canfork_callback, ss, i)
+ if (ss->can_fork) {
+ retval = ss->can_fork(cset->subsys[i], child);
+ if (retval)
+ goto out_revert;
+
