Messages in this thread | | | Date | Mon, 2 Oct 2017 13:20:51 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message |
| |
On Thu 28-09-17 13:36:57, 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?
yes we are
> We can try mutex_trylock() from dump_unreclaimable_slab() at best. > But it is still remaining unsafe, isn't it?
using the trylock sounds like a reasonable compromise. -- Michal Hocko SUSE Labs
| |