On Wed, 16 Aug 2017, Roman Gushchin wrote: > It's natural to expect that inside a container there are their own sshd, > "activity manager" or some other stuff, which can play with oom_score_adj. > If it can override the upper cgroup-level settings, the whole delegation model > is broken. > I don't think any delegation model related to core cgroups or memory cgroup is broken, I think it's based on how memory.oom_kill_all_tasks is defined. It could very well behave as memory.oom_kill_all_eligible_tasks when enacted upon. > You can think about the oom_kill_all_tasks like the panic_on_oom, > but on a cgroup level. It should _guarantee_, that in case of oom > the whole cgroup will be destroyed completely, and will not remain > in a non-consistent state. > Only CAP_SYS_ADMIN has this ability to set /proc/pid/oom_score_adj to OOM_SCORE_ADJ_MIN, so it preserves the ability to change that setting, if needed, when it sets memory.oom_kill_all_tasks. If a user gains permissions to change memory.oom_kill_all_tasks, I disagree it should override the CAP_SYS_ADMIN setting of /proc/pid/oom_score_adj. I would prefer not to exclude oom disabled processes to their own sibling cgroups because they would require their own reservation with cgroup v2 and it makes the single hierarchy model much more difficult to arrange alongside cpusets, for example. > The model you're describing is based on a trust given to these oom-unkillable > processes on system level. But we can't really trust some unknown processes > inside a cgroup that they will be able to do some useful work and finish > in a reasonable time; especially in case of a global memory shortage. Yes, we prefer to panic instead of sshd, for example, being oom killed. We trust that sshd, as well as our own activity manager and security daemons are trusted to do useful work and that we never want the kernel to do this. I'm not sure why you are describing processes that CAP_SYS_ADMIN has set to be oom disabled as unknown processes. I'd be interested in hearing the opinions of others related to a per-memcg knob being allowed to override the setting of the sysadmin. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
