netdev - Re: [patch 1/1] net/netfilter/x_tables.c: make allocation less aggressive

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 31 Jan 2018 09:08:05 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     akpm@...ux-foundation.org, davem@...emloft.net,
        netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
        fw@...len.de
Subject: Re: [patch 1/1] net/netfilter/x_tables.c: make allocation less
 aggressive

On Tue 30-01-18 11:53:58, Eric Dumazet wrote:
[...]
> How is __GFP_NORETRY working exactly ?

this is what the documentation says.
 * __GFP_NORETRY: The VM implementation will try only very lightweight
 *   memory direct reclaim to get some memory under memory pressure (thus
 *   it can sleep). It will avoid disruptive actions like OOM killer. The
 *   caller must handle the failure which is quite likely to happen under
 *   heavy memory pressure. The flag is suitable when failure can easily be
 *   handled at small cost, such as reduced throughput

> Surely, if some firewall tools attempt to load a new iptables rules, we
> do not want to abort them if the request can be satisfied after few
> pages moved on swap or written back to disk.

I am not sure this really goes along with "namespace admin can request
arbitrary amount of memory" very well.

> We want to avoid huge allocations, but leave reasonable ones succeed.

Yes, that would be the best way forward. From the previous discussion
with Florian [1] it seems that "reasonable" is not that easy to figure
out. Anyway, this patch merely gets us back to pre eacd86ca3b03 times
where __GFP_NORETRY has been used for both kmalloc and vmalloc paths.
So it is more a quick band aid than a longterm solution.

[1] http://lkml.kernel.org/r/20180129165722.GF5906@breakpoint.cc
-- 
Michal Hocko
SUSE Labs