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

[Vlastimil Babka <vbabka@suse.cz>]

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.

__GFP_NORETRY might look like a good match at first sight as that stops
allocating when "reclaim becomes hard" which means the system is still
relatively far from OOM. But it's not reliable in principle, and as this
bug report shows. That's fine when __GFP_NORETRY is used for optimistic
allocations that have some other fallback (e.g. huge page with fallback
to base page), but far from ideal when failure means returning -ENOMEM
to userspace.