On 07/31/2018 04:05 PM, Florian Westphal wrote: > Georgi Nikolov <gnikolov@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx/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.
