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

[Georgi Nikolov <gnikolov@icdsoft.com>]

*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. Probably hard coded based on amount of RAM is a
good idea too.

>> __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.
> I absolutely agree. The whole __GFP_NORETRY is quite dubious TBH. I have
> used it to get the original behavior because the change wasn't really
> intended to make functional changes. But consideg ring this requires
> higher privileges then I fail to see where the distrust comes from. If
> this is really about untrusted root in a namespace then the proper way
> is to use __GFP_ACCOUNT and limit that via kmemc.
>
> __GFP_NORETRY can fail really easily if the kswapd doesn't keep the pace
> with the allocations which might be completely unrelated to this
> particular request.