From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CC4EC43460 for ; Sun, 16 May 2021 19:52:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1101F6108D for ; Sun, 16 May 2021 19:52:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233050AbhEPTxi (ORCPT ); Sun, 16 May 2021 15:53:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:32884 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230507AbhEPTxf (ORCPT ); Sun, 16 May 2021 15:53:35 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5C7ABAFC6; Sun, 16 May 2021 19:52:19 +0000 (UTC) From: Vlastimil Babka To: glittao@gmail.com Cc: akpm@linux-foundation.org, cl@linux.com, iamjoonsoo.kim@lge.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, penberg@kernel.org, rientjes@google.com, vbabka@suse.cz, paulmck@kernel.org, oliver.sang@intel.com Subject: [PATCH] mm/slub: use stackdepot to save stack trace in objects-fix Date: Sun, 16 May 2021 21:51:50 +0200 Message-Id: <20210516195150.26740-1-vbabka@suse.cz> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210414163434.4376-1-glittao@gmail.com> References: <20210414163434.4376-1-glittao@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Paul reports [1] lockdep splat HARDIRQ-safe -> HARDIRQ-unsafe lock order detected. Kernel test robot reports [2] BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c The stack trace might be saved from contexts where we can't block so GFP_KERNEL is unsafe. So Use GFP_NOWAIT. Under memory pressure we might thus fail to save some new unique stack, but that should be extremely rare. [1] https://lore.kernel.org/linux-mm/20210515204622.GA2672367@paulmck-ThinkPad-P17-Gen-1/ [2] https://lore.kernel.org/linux-mm/20210516144152.GA25903@xsang-OptiPlex-9020/ Reported-and-tested-by: Paul E. McKenney Reported-by: kernel test robot Signed-off-by: Vlastimil Babka --- mm/slub.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index 6b896b8c36f0..04824dae2e32 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -623,7 +623,7 @@ static void set_track(struct kmem_cache *s, void *object, if (addr) { #ifdef CONFIG_STACKDEPOT - p->handle = save_stack_depot_trace(GFP_KERNEL); + p->handle = save_stack_depot_trace(GFP_NOWAIT); #endif p->addr = addr; p->cpu = smp_processor_id(); -- 2.31.1