linux-kernel - Re: [PATCH 0/3 v8] oom: capture unreclaimable slab info in oom message

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <5b652442-d737-656d-2f54-ce69664a946b@alibaba-inc.com>
Date:   Wed, 04 Oct 2017 02:10:38 +0800
From:   "Yang Shi" <yang.s@...baba-inc.com>
To:     cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        mhocko@...nel.org
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3 v8] oom: capture unreclaimable slab info in oom
 message

This round should be v9. Sorry for the typo.

Yang


On 10/3/17 11:06 AM, Yang Shi wrote:
> 
> Recently we ran into a oom issue, kernel panic due to no killable process.
> The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump doesn't capture vmcore due to some reason.
> 
> So, it may sound better to capture unreclaimable slab info in oom message when kernel panic to aid trouble shooting and cover the corner case.
> Since kernel already panic, so capturing more information sounds worthy and doesn't bother normal oom killer.
> 
> With the patchset, tools/vm/slabinfo has a new option, "-U", to show unreclaimable slab only.
> 
> And, oom will print all non zero (num_objs * size != 0) unreclaimable slabs in oom killer message.
> 
> For details, please see the commit log for each commit.
> 
> Changelog v8 —> 9:
> * Adopted Tetsuo’s suggestion to protect global slab list traverse with mutex_trylock() to prevent from sleeping. Without the mutex acquired unreclaimable slbas will not be dumped.
> * Adopted the suggestion from Christoph to dump CONFIG_SLABINFO since it is pointless to keep it.
> * Rebased to 4.13-rc3
> 
> Changelog v7 —> v8:
> * Adopted Michal’s suggestion to dump unreclaim slab info when unreclaimable slabs amount > total user memory. Not only in oom panic path.
> 
> Changelog v6 -> v7:
> * Added unreclaim_slabs_oom_ratio proc knob, unreclaimable slabs info will be dumped when unreclaimable slabs amount : all user memory > the ratio
> 
> Changelog v5 —> v6:
> * Fixed a checkpatch.pl warning for patch #2
> 
> Changelog v4 —> v5:
> * Solved the comments from David
> * Build test SLABINFO = n
> 
> Changelog v3 —> v4:
> * Solved the comments from David
> * Added David’s Acked-by in patch 1
> 
> Changelog v2 —> v3:
> * Show used size and total size of each kmem cache per David’s comment
> 
> Changelog v1 —> v2:
> * Removed the original patch 1 (“mm: slab: output reclaimable flag in /proc/slabinfo”) since Christoph suggested it might break the compatibility and /proc/slabinfo is legacy
> * Added Christoph’s Acked-by
> * Removed acquiring slab_mutex per Tetsuo’s comment
> 
> 
> Yang Shi (3):
>        tools: slabinfo: add "-U" option to show unreclaimable slabs only
>        mm: slabinfo: dump CONFIG_SLABINFO
>        mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory
> 
>   init/Kconfig        |  6 ------
>   mm/memcontrol.c     |  2 --
>   mm/oom_kill.c       | 22 ++++++++++++++++++++++
>   mm/slab.c           |  2 --
>   mm/slab.h           |  2 ++
>   mm/slab_common.c    | 35 ++++++++++++++++++++++++++++++++---
>   mm/slub.c           |  2 --
>   tools/vm/slabinfo.c | 11 ++++++++++-
>   8 files changed, 66 insertions(+), 16 deletions(-)
>