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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89045C001B0 for ; Thu, 10 Aug 2023 10:16:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F00856B0071; Thu, 10 Aug 2023 06:16:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAF436B0074; Thu, 10 Aug 2023 06:16:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D77D86B0075; Thu, 10 Aug 2023 06:16:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C80536B0071 for ; Thu, 10 Aug 2023 06:16:29 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 755E981031 for ; Thu, 10 Aug 2023 10:16:29 +0000 (UTC) X-FDA: 81107790498.08.EDB0940 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf19.hostedemail.com (Postfix) with ESMTP id 362A81A0003 for ; Thu, 10 Aug 2023 10:16:26 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=idSfT6UJ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ESg8ETSz; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691662587; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LHufn1qzvhw+lYkS+8BVJIOJlgyOqsBjGf2jcyrbwrs=; b=TsJKbRI2MlBQBexd9k/XHxY2o9/0moEipiu/SnfhoC2STfWTzyKvwBlwLNRJL9Dk5w3I81 o6/Gnyu2h9NsIhyL13P8ydKNdH7TR3hld21rjiR8wpnZRtM1elkuLGOEWliI29Qhowo3H9 tcYHsWusHrIirQmTXFOLhbj4Kp/YACc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691662587; a=rsa-sha256; cv=none; b=Dl83mEUWrFVIsshQEn4w130R5/Rw0naBT3qTWUceukSCp3Lb6aFyT0I9kPe0YgCzK1WWpL 1wnjBv0V6dBS1HIkWvD8Rm/0yInRdLUNuV7MxAi2xRm1tnki9I+g8jj3BSDX8EyEsqrqwu 8UNccBWTUO0rQx82/+24vut235TChrE= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=idSfT6UJ; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=ESg8ETSz; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none 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 8E10621867; Thu, 10 Aug 2023 10:16:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1691662585; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LHufn1qzvhw+lYkS+8BVJIOJlgyOqsBjGf2jcyrbwrs=; b=idSfT6UJ/DcmWXG8oZq/71L1nXeNfpAVfhHNiY7LbwkZZVT8kkQW9wmo5431H/oyo6qFLj bb52AEvkisR7ZFFS9yKvGdMDvwf7uoqksxuT1tVhTWnY0LuLRfynKyRemkOFSFN3wHxyO6 Oy/bbH9+0Dn0YlzqqYOgxQcClFO6eg4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1691662585; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LHufn1qzvhw+lYkS+8BVJIOJlgyOqsBjGf2jcyrbwrs=; b=ESg8ETSzCdzouowDLKb3Kl2h7ooB6/JyLlMiu9opacpM2cCQlvlaDuF6CyBLo96qWB0G61 5Yd2vkF6tvQyOsCQ== 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 6E91B138E0; Thu, 10 Aug 2023 10:16:25 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id y/5TGvm41GTYFQAAMHmgww (envelope-from ); Thu, 10 Aug 2023 10:16:25 +0000 Message-ID: <79deae0c-eeef-2370-9d8a-b2746389d38c@suse.cz> Date: Thu, 10 Aug 2023 12:16:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH 2/2] mm/kmemleak: No need to check kmemleak_initialized in set_track_prepare() Content-Language: en-US From: Vlastimil Babka To: Xiaolei Wang , catalin.marinas@arm.com, akpm@linux-foundation.org, glider@google.com, andreyknvl@gmail.com, zhaoyang.huang@unisoc.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230810074704.2042664-1-xiaolei.wang@windriver.com> <20230810074704.2042664-3-xiaolei.wang@windriver.com> <37397d75-c95c-8730-cf22-79e283e0bd6c@suse.cz> In-Reply-To: <37397d75-c95c-8730-cf22-79e283e0bd6c@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 362A81A0003 X-Rspam-User: X-Stat-Signature: ku4r1fr1ges95xu1fhnsjrqnssupi37q X-Rspamd-Server: rspam03 X-HE-Tag: 1691662586-202075 X-HE-Meta: U2FsdGVkX1+ZbqhWFo+CJpFEhTkHF/W6CkQqDNUXSBjdqebixdbiPvXEoJ5PXuebTfoK1DnvmMNqM5SwR6SPWDVDjs5k3Obps0KmeKxeeZuv53AYWPJ1MtdJ0w0Gco3Xke/BmG7hlT9VfEWxQIvULMavCYT1Bc4hUxbtTN4sAdGn+8jPooOp6hrXiXY5zR5l+LjTpPuNQLuCuJ9sdp8ZEFz2X1qJUKQdcLNW3DjavRChh1r2VXsRQ8bVOTEUG0uW7T2DrABbIYdGtfhuitWjhDHvNuXYqZY4A2NvKRRjIbNRh0roNVsuuFF9xCT1UpSa/whCkQB3tO0fx0OHVIzAScY6Ci37gLglDarnf/Usyh3smeVCwQoLjRIzBX0kSM5R/6vqI9b9F3WlnE7x6nVa6FRaluULMdXbgA2z6A4wvvsHkco3fyBQgkdrXWLcN4A85DWB/A9nhDRrU7H4mN0sUl6DgNslQYdxYT9HH9wStDXCNE9/uGe5BGKoqqPrmZSYvFWjyWBKxJ4ZsdI47xsVkq/dl0c0kOGKIXI6uJA/CWFF+N9eavNQYaC4LVkDRIpnG6kGok9iYFJdqJ6ccDfvxaw+KYnm1hUgc6OnvJw0Bab9R7i4YGtA73pftYKz3agrlbYdI/a6NpEJb4tD0B+PcHZ8StDxO/Meip1wjyTLu9nXH86dEwRmns7Vx6FWcm0ySz/OFRaFIQEpzuVUV+PYRCyueDj6in/XhnhlYEVGLZvB09bfldgztpiBFl1j7OLipVih+Hh4s/GkoPjxiq7PhmbAsaJak90+rUqJe2B865jENceLASGc92Ew4QZFFcMpHKhWN9dWZGOJZM1S6/HpKCTxU927CnewICt1/xtFBKCoaaHpo6yY2LQDYtobj4KhSL7HlH40ema34xQbfiUhOmBfODOFRqQqz5IcHckBEY0yviY0D1DV8uniZ3qk+x9cwdApLhHXKEsAWv7/gLH tr8AaL5x Uk0dPkOgGrnl8MggcwJwfHEF7yIRbYv0cq8AYqIRbgO/ZW3+qIJa+LeFGKxP5rf4GM7wUS/OH8eA9PqExGJFV9+w5XMiljbkfYZHj0H/ISBuI8eO2ZMWGXHkovFKo/hl8mwIIbbWm98cPJcGEfinUDTFaJWAg7J8r5qr0w8xPPwKibfooYaQUECJRYreKb17d9yE/kSAZdbmgMARyWlYdj0cusT8ZMI6dNy/jCuyG3QutFUto5+nOgxV1dVhMIJsZ3v40jrexOWiey1Z2gLhzSQUzxH3lSRNQslbMCergTdOj430= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 8/10/23 12:03, Vlastimil Babka wrote: > On 8/10/23 09:47, Xiaolei Wang wrote: >> The kmemleak_late_init() is defined as a late_initcall. The current >> implementation of set_track_prepare() depends on the kmemleak init. >> That also means there is no call trace for the memory leak which object >> is created before the kmemleak_late_init(). > > So if I understand correctly, we have the following sequence of events durin > boot > > ... > A: stack_depot is initialized > ... > B: kmemleak is initialized > ... > > before this patchset, we can miss allocations before B, aftewards only > before A (which can't be helped), so we now have between A and B. > > That's nice, but it's weird that can record kmemleak when > !kmemleak_initialized. Why can't it be initialized sooner in that case? Looking closer, I think what you want could be achieved by kmemleak_init() setting a variable that is checked in kmemleak_initialized() instead of the kmemleak_initialized that's set too late. I think this should work because: - I assume kmemleak can't record anything before kmemleak_init() - stack depot early init is requested one way or the other - mm_core_init() calls stack_depot_early_init() before kmemleak_init() But I also wonder how kmemleak can even reach set_track_prepare() before kmemleak_init(), maybe that's the issue? >> In a previous patch, we have fixed a bug in stack_depot_save() so that >> it can be invoked even before stack depot is initialized. So there is >> no reason to check the kmemleak_initialized in set_track_prepare(). >> So delete the kmemleak_initialized judgment in set_track_prepare() >> >> unreferenced object 0xc674ca80 (size 64): >> comm "swapper/0", pid 1, jiffies 4294938337 (age 204.880s) >> hex dump (first 32 bytes): >> 80 55 75 c6 80 54 75 c6 00 55 75 c6 80 52 75 c6 .Uu..Tu..Uu..Ru. >> 00 53 75 c6 00 00 00 00 00 00 00 00 00 00 00 00 .Su.......... >> >> Fixes: 56a61617dd22 ("mm: use stack_depot for recording kmemleak's backtrace") >> Signed-off-by: Xiaolei Wang >> --- >> mm/kmemleak.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c >> index a2d34226e3c8..c9f2f816db19 100644 >> --- a/mm/kmemleak.c >> +++ b/mm/kmemleak.c >> @@ -610,8 +610,6 @@ static noinline depot_stack_handle_t set_track_prepare(void) >> unsigned long entries[MAX_TRACE]; >> unsigned int nr_entries; >> >> - if (!kmemleak_initialized) >> - return 0; >> nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 3); >> trace_handle = stack_depot_save(entries, nr_entries, GFP_NOWAIT); >> >