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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 11 Mar 2019 22:49:24 -0700
From:   Y Song <>
To:     Martynas Pumputis <>
Cc:     netdev <>,,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
Subject: Re: [PATCH] bpf: Try harder when allocating memory for large maps

On Mon, Mar 11, 2019 at 12:32 PM Martynas Pumputis <> wrote:
> It has been observed that sometimes a higher order memory allocation
> for BPF maps fails when there is no obvious memory pressure in a system.
> E.g. the map (BPF_MAP_TYPE_LRU_HASH, key=38, value=56, max_elems=524288)
> could not be created due to vmalloc unable to allocate 75497472B,
> when the system's memory consumption (in MB) was the following:
>     Total: 3942 Used: 837 (21.24%) Free: 138 Buffers: 239 Cached: 2727
> Later analysis [1] by Michal Hocko showed that the vmalloc was not trying
> to reclaim memory from the page cache and was failing prematurely due to
> Considering dcda9b0471 ("mm, tree wide: replace __GFP_REPEAT by
> __GFP_RETRY_MAYFAIL with more useful semantic") and [1], we can replace
> __GFP_NORETRY with __GFP_RETRY_MAYFAIL, as it won't invoke OOM killer
> and will try harder to fulfil allocation requests.
> The change has been tested with the workloads mentioned above and by
> observing oom_kill value from /proc/vmstat.
> [1]:
> Signed-off-by: Martynas Pumputis <>
Acked-by: Yonghong Song <>

Powered by blists - more mailing lists