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?
--
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>
