Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp446667rwi; Mon, 31 Oct 2022 03:37:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7Lj5B2WPR+DZEFxf38IMFThrtjX30lZiO6uGR6WAORZPZJX0c7kxAKhu/F/Og8yeIJB0yp X-Received: by 2002:a05:6402:5cb:b0:452:e416:2bc4 with SMTP id n11-20020a05640205cb00b00452e4162bc4mr12688046edx.114.1667212678233; Mon, 31 Oct 2022 03:37:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667212678; cv=none; d=google.com; s=arc-20160816; b=XlBW2SOkTcIReW3NViZm7XMDo8QV4tk+cb6dJleaUnG8YFngTBZMOKyxE8RCR3d5QW lSe5Injv1UijSCaaibmOXFIU4Ldqz5wmDmKJs9x8KmHOvHSFUX6JudHwVRRzP1+kdjie qGoeb8O5f7aoCRwWPvoC2TA2o6zPdB90KFJ5U7F62Vqog3ZYOesYoB8HK475eRpCFv7K 07qtww6eDB+RykxqLTsqi958qqi+Kfs3i59icL/prOxj59YtzMabxcBJGPCYI+b4muEE qS/rsfw9ZKRdM5DpQQ+KB/k/+UKX2T1RUT4h9Tf5gRD27OmMt02tsABTLCAOa/5DLRFd E3Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature:dkim-signature; bh=9NSYUTg7UfCJA+CQRR8S+uUBhAxqW3ri0yU6NXT2ryE=; b=DEdUaV0nZAXx888RMPi0ZJjW9Btng4RtWMu3kGAH9X7LFKCn2xfWzC/txyq0yWmLsl x4lTsfdH0QVNeYPEYkg1ODOlvxkT5b2spQjEmAwvVaY3qw3o3s1ocjGxt6FC7exdyO0q D/RKV2OeTX8hzRHNC2Skmrsx2603rbxiZQvce+sgs6qryHgamIJ6RcR4YzbqOve9E377 /wSM4LaMPBrv+cYPUupKCXqkBIuKHi916Ks45wfoNGj9b1P77eKpoxqyk8EHjdqAY6wW okmHrAseogcYWXO9p5CHtERtyqoF+vm42b1H1BBxe8ds0cXvvA4ArEnxRk5udfodw6cw HUIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=AcuKRECf; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ec4-20020a0564020d4400b0045731196587si6051774edb.64.2022.10.31.03.37.34; Mon, 31 Oct 2022 03:37:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=AcuKRECf; dkim=neutral (no key) header.i=@suse.cz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229913AbiJaKP2 (ORCPT + 98 others); Mon, 31 Oct 2022 06:15:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229620AbiJaKPX (ORCPT ); Mon, 31 Oct 2022 06:15:23 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B84FCE3B for ; Mon, 31 Oct 2022 03:15:21 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id ABBD533712; Mon, 31 Oct 2022 10:15:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1667211315; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9NSYUTg7UfCJA+CQRR8S+uUBhAxqW3ri0yU6NXT2ryE=; b=AcuKRECfDXYjYNPUktvOEBKP9Y0tVTVk7/3W1GHkRWddmNwa+8k91t+TV+ixrMuDqrhWHe JmgdKjKRqcUIsk+465p6RwhRG+cBEnwkSRhfOvEF8LyyJG9HjcKSVYDx91JqFE1qngLuIz GPiClrNoZyZN5SAp54aIZPTdNuV04jM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1667211315; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9NSYUTg7UfCJA+CQRR8S+uUBhAxqW3ri0yU6NXT2ryE=; b=8Mm8FxEH+lKsazmIC1gH5khi2+2/lsvlozLz0q65Bnu54lqqrCrTZQFFUu96003BtRk+ln on5jxT7ZxQb1L2DA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 807D713451; Mon, 31 Oct 2022 10:15:15 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Z+pJHjOgX2N3dAAAMHmgww (envelope-from ); Mon, 31 Oct 2022 10:15:15 +0000 Message-ID: Date: Mon, 31 Oct 2022 11:15:15 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCHv3] mm: use stack_depot for recording kmemleak's backtrace Content-Language: en-US To: "zhaoyang.huang" , Andrew Morton , Catalin Marinas , Matthew Wilcox , Zhaoyang Huang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com, steve.kang@unisoc.com References: <1667101354-4669-1-git-send-email-zhaoyang.huang@unisoc.com> From: Vlastimil Babka In-Reply-To: <1667101354-4669-1-git-send-email-zhaoyang.huang@unisoc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/30/22 04:42, zhaoyang.huang wrote: > From: Zhaoyang Huang > > Using stack_depot to record kmemleak's backtrace which has been implemented > on slub for reducing redundant information. > > Signed-off-by: Zhaoyang Huang > Acked-by: Catalin Marinas > Cc: ke.wang > Cc: Matthew Wilcox (Oracle) > Cc: Vlastimil Babka > Cc: Zhaoyang Huang > Signed-off-by: Andrew Morton > --- > changes of v2: fix bugs of stack_depot_init related issue > changes of v3: have DEBUG_KMEMLEAK select STACK_DEPOT by default > remove unuse functions > --- > --- > lib/Kconfig.debug | 1 + > mm/kmemleak.c | 48 +++++++++++++++++++++++++++++------------------- > 2 files changed, 30 insertions(+), 19 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index bcbe60d..0def8e0 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -717,6 +717,7 @@ config DEBUG_KMEMLEAK > select STACKTRACE if STACKTRACE_SUPPORT > select KALLSYMS > select CRC32 > + select STACKDEPOT Should be also "if STACKTRACE_SUPPORT" as for the "select STACKTRACE" above, but then you would have to deal with the case that stackdepot isn't available - e.g. like in mm/slub.c use #ifdef CONFIG_STACKDEPOT where needed. However, the "select STACKTRACE if STACKTRACE_SUPPORT" above was AFAICS already subtly broken as the existing stacktrace handling calls in kmemleak would also fail to compile/link on architectures/configs where STACKTRACE_SUPPORT was not available and thus STACKTRACE not selected. I assume it all relies on "depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK" where HAVE_DEBUG_KMEMLEAK is explicitly selected in a number of arch/$arch/Kconfig files, and I assume all those have STACKTRACE_SUPPORT selected as well. But it's subtle and in that case we could just be more explicit, like page_owner is, which just requires STACKTRACE/STACKDEPOT explicitly on Kconfig level: depends on DEBUG_KERNEL && STACKTRACE_SUPPORT (for kmemleak we would add HAVE_DEBUG_KMEMLEAK too) select STACKTRACE select STACKDEPOT bonus points for moving the kmemleak config from lib/Kconfig.debug to mm/Kconfig.debug - looks like we missed it in the cleanups earlier this year. > help > Say Y here if you want to enable the memory leak > detector. The memory allocation/freeing is traced in a way ... > > -/* > - * Save stack trace to the given array of MAX_TRACE size. > - */ > -static int __save_stack_trace(unsigned long *trace) > +static noinline depot_stack_handle_t set_track_prepare(void) > { > - return stack_trace_save(trace, MAX_TRACE, 2); > + depot_stack_handle_t trace_handle; > + unsigned long entries[MAX_TRACE]; > + unsigned int nr_entries; > + > + if (!kmemleak_initialized) > + return 0; I suspect this check might not be necessary if you switched from stack_depot_init() to stack_depot_want_early_init(), see how page_owner does this in early_page_owner_param(). Here we have kmemleak_boot_config() but it's more tricky as not having any kmemleak param means it should be enabled by default and then the function is not called at all, hm. Maybe use an early_initcall()? > + nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 3); > + trace_handle = stack_depot_save(entries, nr_entries, GFP_NOWAIT); > + > + return trace_handle; > } > > /* > @@ -654,7 +664,7 @@ static struct kmemleak_object *__create_object(unsigned long ptr, size_t size, > } > > /* kernel backtrace */ > - object->trace_len = __save_stack_trace(object->trace); > + object->trace_handle = set_track_prepare(); > > raw_spin_lock_irqsave(&kmemleak_lock, flags); > > @@ -694,7 +704,6 @@ static struct kmemleak_object *__create_object(unsigned long ptr, size_t size, > rb_link_node(&object->rb_node, rb_parent, link); > rb_insert_color(&object->rb_node, is_phys ? &object_phys_tree_root : > &object_tree_root); > - > list_add_tail_rcu(&object->object_list, &object_list); > out: > raw_spin_unlock_irqrestore(&kmemleak_lock, flags); > @@ -1094,7 +1103,7 @@ void __ref kmemleak_update_trace(const void *ptr) > } > > raw_spin_lock_irqsave(&object->lock, flags); > - object->trace_len = __save_stack_trace(object->trace); > + object->trace_handle = set_track_prepare(); > raw_spin_unlock_irqrestore(&object->lock, flags); > > put_object(object); > @@ -2064,6 +2073,7 @@ void __init kmemleak_init(void) > if (kmemleak_error) > return; > > + stack_depot_init(); > jiffies_min_age = msecs_to_jiffies(MSECS_MIN_AGE); > jiffies_scan_wait = msecs_to_jiffies(SECS_SCAN_WAIT * 1000); >