linux-kernel - Re: [PATCH 0/2 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 for Android: free password hash cracker in your pocket

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

Message-ID: <7e8684c2-c9e8-f76a-d7fb-7d5bf7682321@alibaba-inc.com>
Date:   Fri, 29 Sep 2017 01:49:26 +0800
From:   "Yang Shi" <yang.s@...baba-inc.com>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        mhocko@...nel.org
Cc:     cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom
 message



On 9/27/17 9:36 PM, Tetsuo Handa wrote:
> On 2017/09/28 6:46, Yang Shi wrote:
>> 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.
> 
> Holding slab_mutex inside dump_unreclaimable_slab() was refrained since V2
> because there are
> 
> 	mutex_lock(&slab_mutex);
> 	kmalloc(GFP_KERNEL);
> 	mutex_unlock(&slab_mutex);
> 
> users. If we call dump_unreclaimable_slab() for non OOM panic path, aren't we
> introducing a risk of crash (i.e. kernel panic) for regular OOM path?

I don't see the difference between regular oom path and oom path other 
than calling panic() at last.

And, the slab dump may be called by panic path too, it is for both 
regular and panic path.

Thanks,
Yang

> 
> We can try mutex_trylock() from dump_unreclaimable_slab() at best.
> But it is still remaining unsafe, isn't it?
>