Re: [Bug 200651] New: cgroups iptables-restor: vmalloc: allocation failure

[Michal Hocko <mhocko@kernel.org>]

On Wed 01-08-18 19:03:03, Georgi Nikolov wrote:
> 
> *Georgi Nikolov*
> System Administrator
> www.icdsoft.com <http://www.icdsoft.com>
> 
> On 08/01/2018 11:33 AM, Michal Hocko wrote:
> > On Wed 01-08-18 09:34:23, Vlastimil Babka wrote:
> >> On 07/31/2018 04:05 PM, Florian Westphal wrote:
> >>> Georgi Nikolov <gnikolov@icdsoft.com> wrote:
> >>>>> No, I think that's rather for the netfilter folks to decide. However, it
> >>>>> seems there has been the debate already [1] and it was not found. The
> >>>>> conclusion was that __GFP_NORETRY worked fine before, so it should work
> >>>>> again after it's added back. But now we know that it doesn't...
> >>>>>
> >>>>> [1] https://lore.kernel.org/lkml/20180130140104.GE21609@dhcp22.suse.cz/T/#u
> >>>> Yes i see. I will add Florian Westphal to CC list. netfilter-devel is
> >>>> already in this list so probably have to wait for their opinion.
> >>> It hasn't changed, I think having OOM killer zap random processes
> >>> just because userspace wants to import large iptables ruleset is not a
> >>> good idea.
> >> If we denied the allocation instead of OOM (e.g. by using
> >> __GFP_RETRY_MAYFAIL), a slightly smaller one may succeed, still leaving
> >> the system without much memory, so it will invoke OOM killer sooner or
> >> later anyway.
> >>
> >> I don't see any silver-bullet solution, unfortunately. If this can be
> >> abused by (multiple) namespaces, then they have to be contained by
> >> kmemcg as that's the generic mechanism intended for this. Then we could
> >> use the __GFP_RETRY_MAYFAIL.
> >> The only limit we could impose to outright deny the allocation (to
> >> prevent obvious bugs/admin mistakes or abuses) could be based on the
> >> amount of RAM, as was suggested in the old thread.
> 
> Can we make this configurable - on/off switch or size above which
> to pass GFP_NORETRY.

Yet another tunable? How do you decide which one to select? Seriously,
configuration knobs sound attractive but they are rarely a good idea.
Either we trust privileged users or we don't and we have kmem accounting
for that.

> Probably hard coded based on amount of RAM is a good idea too.

How do you scale that?

In other words, why don't we simply do the following? Note that this is
not tested. I have also no idea what is the lifetime of this allocation.
Is it bound to any specific process or is it a namespace bound? If the
later then the memcg OOM killer might wipe the whole memcg down without
making any progress. This would make the whole namespace unsuable until
somebody intervenes. Is this acceptable?
---