On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote:
If a user has a setup where they wait for notifications on changes to
pids.event, and then auto-adjust the cgroup limits based on the number of
failures you have a race condition between reading the pids.event file and
then setting the new limit. Then, upon getting notified again there may have
been many failed forks with the old limit set, so you might decide to bump
up the limit again.
It's not a huge deal, I just though it could be useful to alleviate problems
like the above.
This is something which can easily be avoided from userland. I don't
think we need to add extra facilities for this.
Maybe I'm misunderstanding what the purpose of pids.events is meant to
be. If it's just meant to be a "hint" to the administrator, then that
seems like an awfully odd way of giving hints (the kernel logging should
be enough for that). If it's meant so that the administrator can make
policy decisions, then she won't know if the change in failures happened
before or after she adjusted the limit.
I also don't see what you mean by "it can be avoided from userland".
There's a race between changing pids.max and a process forking that
causes pids.events to be updated.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
