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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
