Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752292AbdI1Rts (ORCPT ); Thu, 28 Sep 2017 13:49:48 -0400 Received: from out0-219.mail.aliyun.com ([140.205.0.219]:39912 "EHLO out0-219.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751580AbdI1Rtq (ORCPT ); Thu, 28 Sep 2017 13:49:46 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R351e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03310;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---.9.j7h8K_1506620969; Subject: Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message To: Tetsuo Handa , mhocko@kernel.org Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1506548776-67535-1-git-send-email-yang.s@alibaba-inc.com> From: "Yang Shi" Message-ID: <7e8684c2-c9e8-f76a-d7fb-7d5bf7682321@alibaba-inc.com> Date: Fri, 29 Sep 2017 01:49:26 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 921 Lines: 30 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? >