On Thu 28-01-21 13:28:10, Cristopher Lameter wrote: > On Thu, 28 Jan 2021, Michal Hocko wrote: > > > > So, if I understand your concerns correct this implementation has two > > > issues: > > > 1) allocation failure at page fault that causes unrecoverable OOM and > > > 2) a possibility for an unprivileged user to deplete secretmem pool and > > > cause (1) to others > > > > > > I'm not really familiar with OOM internals, but when I simulated an > > > allocation failure in my testing only the allocating process and it's > > > parent were OOM-killed and then the system continued normally. > > > > If you kill the allocating process then yes, it would work, but your > > process might be the very last to be selected. > > OOMs are different if you have a "constrained allocation". In that case it > is the fault of the process who wanted memory with certain conditions. > That memory is not available. General memory is available though. In that > case the allocating process is killed. I do not see this implementation would do anything like that. Neither anything like that implemented in the oom killer. Constrained allocations (cpusets/memcg/mempolicy) only do restrict their selection to processes which belong to the same domain. So I am not really sure what you are referring to. The is only a global knob to _always_ kill the allocating process on OOM. -- Michal Hocko SUSE Labs
