linux-kernel - Re: Trying to understand OOM killer

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]

Message-ID: <20170219150037.GB24890@dhcp22.suse.cz>
Date:   Sun, 19 Feb 2017 16:00:37 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Paul Menzel <paulepanter@...rs.sourceforge.net>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: Trying to understand OOM killer

On Sun 12-02-17 14:47:13, Paul Menzel wrote:
> Dear Linux folks,
> 
> 
> since some time, at Linux 4.8, 4.9, and 4.10-rc6, the OOM kicks in on a
> 8 GB machine.
> 
> ```
> Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat invoked oom-killer: gfp_mask=0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRACK), nodemask=

The output is truncated. Could you send the full oom report? But this
smells like an example of the lowmem exhaustion. This is a lowmem
request on 32b system
[...]
> Feb 12 08:21:53 asrocke350m1 kernel: Node 0 active_anon:479572kB inactive_anon:70712kB active_file:125844kB inactive_file:876364kB unevictable
> Feb 12 08:21:53 asrocke350m1 kernel: DMA free:3840kB min:788kB low:984kB high:1180kB active_anon:0kB inactive_anon:0kB active_file:0kB inactiv
> Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 763 7663 7663
> Feb 12 08:21:53 asrocke350m1 kernel: Normal free:38764kB min:38828kB low:48532kB high:58236kB active_anon:0kB inactive_anon:0kB active_file:16
> Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 0 55201 55201

lowmem is on the min watermark while there is no anonymous memory to be
reclaimed and we cannot really tell how much of the page cache as it is
truncated. We also do not know how large is the request because the
order part is missing. __GFP_COMP would suggest higher order request.

In short it is very likely that the OOM killer is genuine because the
given allocation request cannot be satisfied because the low mem
(~896MB) is depleted. This is an inherent problem of 32b kernels
unfortunately. Maybe there is a larger memory consumer in newer
kernels which changed the picture for you.
-- 
Michal Hocko
SUSE Labs