On Wed 01-08-18 09:34:23, Vlastimil Babka wrote: > 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. 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. -- Michal Hocko SUSE Labs
