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 cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
