Re: [PATCH v2 1/2] cgroups: allow a cgroup subsystem to reject a fork

[Aleksa Sarai]

Hi Tejun,

>> The reason is that when cgroup_can_fork() is called, the css_set doesn't
>> contain the pids cgroup it's forking to. You can verify this by moving that
>> segment of code back to it's original position and compiling/rebooting/testing
>> the pids cgroup. You will get a WARN each time you try to attach to a new pids
>> cgroup, because when your shell forks the counter for the original pids cgroup
>> hierarchy gets incremented but when the command exits the counter for the *new*
>> pids cgroup hierarchy gets decremented. Essentially it's because we need to
>> reference the css_set of the newly forked process (as it exists when
>> cgroup_fork() runs) when incrementing the hierarchy -- otherwise we will
>> increment/decrement a different hierarchy between fork() and exit().
>>
>> If there's a correct way of doing this, I'm all ears. I had a bad feeling that
>> moving that section would break the whole visibility issue in the same fashion
>> as I did in v1 of this patchset. The thing is, I'm not sure there's a way to
>> access the new css_set of the task as though it is attached without making it
>> visible prematurely (because we need the css_set to refer to the right
>> hierarchy in order to conditionally decide the fork).
>
> You can charge the parent's at can_attach(), remember which one you
> charged, and at post_fork() if the parent's has changed inbetween, fix
> it up.  Again, you may end up breaking the hard limit of the new pids
> cgroup at this point but that's fine.  The cgroup membership changing
> inbetween pretty much implies that organization operation happened
> inbetween.

I'm not sure how to check for equality between two `css_set`s (or just two
`css`s). Is there a function to do so? Also, I'm not sure if there's a nice way
of doing a charge that stops if you hit a certain `css` (unless we start
passing `css_set`s to the fork/exit callbacks -- and then we can uncharge the
old css_set and charge the new one).

--
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/