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 AC2EFC001B0 for ; Mon, 14 Aug 2023 16:21:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDD448E0001; Mon, 14 Aug 2023 12:21:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8D5D6B0075; Mon, 14 Aug 2023 12:21:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D55658E0001; Mon, 14 Aug 2023 12:21:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C39E26B0074 for ; Mon, 14 Aug 2023 12:21:05 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7FE3F40A73 for ; Mon, 14 Aug 2023 16:21:05 +0000 (UTC) X-FDA: 81123224490.21.FF112CA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf06.hostedemail.com (Postfix) with ESMTP id 994B9180015 for ; Mon, 14 Aug 2023 16:21:03 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf06.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692030063; a=rsa-sha256; cv=none; b=SWMpJgL7IPzj9fexVPwkar5Casz+uui9SlAQ7stYY5nUIe59NsKSo2e1XK++hZNDsSOF02 lgS8BU/s0Hu2ZgqXmh2aDaLdPovDvFL2S3sY2qmiRxseAOoTsPj3Yre+fx+UZp9kfr3lBO SPvnIcM9nuJ6lFoK2jvbnFJCMo3sZjo= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf06.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692030063; 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: in-reply-to:in-reply-to:references:references; bh=JdsugeHN2olZQy91WfDgALRH/kaReSZQ+eQA7CVF3vc=; b=uVOFl9HGtqCFLFKTpY6phQ7XVfXZ/HXzAsUDNkWnRiY7seaoSNJPQT5r8x+CTKjGx8geqm 6u5R93rAbHmdHw00lYSz5o9zU2cOaE8hMt72MfXrHoiYz4V6y0OegEEVWFNlzjiF+U7qk6 4cH5eOMQ5d6An4lBLdY2yr9LcRmfygA= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B02166160E; Mon, 14 Aug 2023 16:21:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E82DC433C7; Mon, 14 Aug 2023 16:21:00 +0000 (UTC) Date: Mon, 14 Aug 2023 17:20:58 +0100 From: Catalin Marinas To: Vlastimil Babka Cc: wang xiaolei , akpm@linux-foundation.org, glider@google.com, andreyknvl@gmail.com, zhaoyang.huang@unisoc.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm/kmemleak: No need to check kmemleak_initialized in set_track_prepare() Message-ID: References: <20230810074704.2042664-1-xiaolei.wang@windriver.com> <20230810074704.2042664-3-xiaolei.wang@windriver.com> <37397d75-c95c-8730-cf22-79e283e0bd6c@suse.cz> <79deae0c-eeef-2370-9d8a-b2746389d38c@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 994B9180015 X-Stat-Signature: o69d5dqxhiuqqdyn1z9uxiwidjqw6k3m X-Rspam-User: X-HE-Tag: 1692030063-243800 X-HE-Meta: U2FsdGVkX1+XUhTwt9tAuFWPAFJMqxvtat+4tmSFRFs7PYbTD2Gk8dPGQvprno36cOz49uH3hjYkNvcgXNy8p3jAU6lSXqQY2uuuFg1iWSDhQZMR01hUqmEQv7GKBH789FdCKp9+Do/aRfEcb87qg9hsTV6RdwoPNZlpfsMthzZsumN5WGe2sPVkJjDfrxZTYWvtZnTaxjLLCtLkiwDnFHRe83qiVlVobEnemDNpQc/1Bzf1MTxhsNsSlm+FuswT6X6fgmU7HsS2VMCWHpkNvtRbTI/2j7J7sti6oZBy6trBBxAddsPBqKWu5+/3y1t68y+2IwRxyklAktZ7QnQHMpGJ/FgjBqS2/rBZeuj73Y39uZEhtUk6Uv9VpL41IWQYI2CrxDNePX7zBMLPxkZYGKhyMncIRLE5zwuR1XIHcxNAcz4IOURjUFMSJv/6bv2P/S2ESkDVge4Zanoj/sWh0kZ6aKFyqKUcRbD0BKy+Z9a5GXVe/xstzbyhCc2RXi9tQqECYbOfopTr+uFh3n0nqYnqgtjTfJLkYJkCDSuF+oiiIZW3iok0PuUjA0/VZD18YyUbDYDR9xKhwZrbMTBnPiwrU+0UIvakNG1Yqm8IhjoHvfcrfJLobyMZXtJlsoDIclYawg59ok1tc7QKvCI02e4rfNnQ0Xpv4sQbtYnrdxADzFm5rFNv2hcYb1TNF2URug7KWQpLRikoTVLCub2m2MgKsMxIc0n+iGoyuDRNeOO7dL+TrTdEJHVVWHu7P8eEkxVlLwGX+N0pYw2e3n37s6ezTfsw8liB9wlTGWDLAPmi27umkFzpV/ea8lKUdko+oIgcO6erMIwDBkUjECZe3jmLdOdRo5hjlnW7qzJgvkFiUeE2cpbf9JCoQZgMruxCXJRDVI4RD6Ob1a7Wf1WvV+6Q5LPVD/OH4wNyZ2WjwxnwtCNSuzR8SKdOFwAb0NLDr3BsrGEJV6KcLhSKRMo /aRES4PO q3mZaKGgW+TtMbp8qXnj6T9yAd9jgVmw/RuiR3YtwohxL/aWUY64eHPaPm2V0TQRUg6x5S4PTz0zeJVn0me42YkLDL9kNa/5V6kMSZx9ZQAJeU8qQeBc1AZpxVlcwoaX/deHuqUQrUC+HBJBvVscIGNVzmWXEXLdU3XkhMYlDQPqRKbn+fXiOspT9U/k6+oedA4PTZRJmamV1KUHxINmGw2gZaF29F5wFsPkdiOHvLot3YcSPkQwj4rzKUN28WNepjFzPebsbzZ5Snlot7wo9yTFko/APEnUbIp473L0GY/PxJTIGe45rtTHHkggZvHgrwqh1OD+IoXRdeHkYAme7wI066YKKSrFnsbDypxBKzJKzEILR8L4qlw4LSyLaRQ9FEyAW0x1LlCWVPS2fMp1jhblK2wZeyWZhAFxdvQ+nzT5x7L87Ww2xybYPhXCJzV82zcpRIl51PFBRDhCAXIfGjJFSUw== 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 Fri, Aug 11, 2023 at 10:09:08AM +0200, Vlastimil Babka wrote: > On 8/11/23 04:03, wang xiaolei wrote: > > On 8/10/23 9:16 PM, Vlastimil Babka wrote: > >> 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? > > > > Before kmemleak_init, many places also need to allocate kmemleak_object, > > > > and also need to save stack in advance, but kmemleak_object is allocated > > > > in the form of an array, after kmemleak_init 'object_cache = > > KMEM_CACHE(kmemleak_object, SLAB_NOLEAKTRACE);' > > Hm I see, kmemleak has this static mempool so it really can record some > objects very early. Indeed, otherwise we'd get a lot of false positives. > > I think there is still some memory not recorded on the backtrace before > > > > stack_depot_early_init(), does anyone have a better suggestion? > > No we can't record the backtrace earlier. But I don't think it's a problem > in practice. AFAIU kmemleak needs to record these very early allocations so > if they point to further objects, those are not suspected as orphans. But > the early allocations themselves also are very unlikely to be leaks, so does > it really matter that we don't have a backtrace for their allocation? > Because the backtrace is the only thing that's missing - the object is > otherwise recorded even if set_track_prepare() returns 0. It's not a functional problem, just a reporting one. There are rare early leaks (usually false positives) so identifying them would help. That said, I think set_track_prepare() is too conservative in waiting for kmemleak_initialized to be set in kmemleak_late_init(). That's a late_initcall() meant for the scanning thread etc. not the core kmemleak functionality (which is on from early boot). We can instead use a different variable to check in set_track_prepare(), e.g. object_cache. stack_depot_early_init() is called prior to kmemleak_init(), so it should be fine. If "kmemleak_initialized" is confusing, we could rename it to "kmemleak_late_initialized" or "kmemleak_fully_initialized". I'm not too fussed about this as long as we add some comment on why we check object_cache instead of kmemleak_initialized. -- Catalin