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 B0B79C433EF for ; Tue, 31 May 2022 15:07:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42F8F6B0073; Tue, 31 May 2022 11:07:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DDE66B0075; Tue, 31 May 2022 11:07:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A4476B0078; Tue, 31 May 2022 11:07:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1AC596B0073 for ; Tue, 31 May 2022 11:07:30 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C9E1F12A1 for ; Tue, 31 May 2022 15:07:29 +0000 (UTC) X-FDA: 79526367018.29.5E28B27 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by imf31.hostedemail.com (Postfix) with ESMTP id 15C3720072 for ; Tue, 31 May 2022 15:06:48 +0000 (UTC) Received: by mail-vk1-f175.google.com with SMTP id ay20so6334208vkb.5 for ; Tue, 31 May 2022 08:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=S9GnfEHaSBA3h8Z8c3Ga5zWpFlXSYvFHz3qXRMFx33A=; b=RHaSGOpQtN8fHKsZoAdjCPk0ydta8EnxZfEIRUYF+QGxY7uMWVArGeqLiHv7alh+iQ i5xgibjzMKCHru2f/jV7YNkrzuJbi4lEagEUwtbIXahnHixtkzXBl3uOAvxugCfg2PH3 r5qyxchTsFJgUfZ429zdcsgyHape4XS1G4i6LPol5ObgYMw9RniuKJS9HLHsuz4lehF8 LYlcDaEEqV2CJIDT8r54NnXoi0B0AAoVyD25J37i96IeiHyXVm+clE8vUOcFIZk8iFnN w7YM4aa+GiHwh8wwbvZlV+ED6C8Wu6rW+8maOZj8PQVtrGN45xZVUKB/kEjs2pDbAqNC k0RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=S9GnfEHaSBA3h8Z8c3Ga5zWpFlXSYvFHz3qXRMFx33A=; b=cwDBovomaLBRtAatbYtCP4CPm+h7J5sw5gd7A/QQLxFXobtB/H1wIUVTcWQSeSDf4X V42J23fy1vMGeNNuodINp/UjXtwL9MMD8+NRPYfIrn6nWCQxgwiWapFw62zzAK93oZzm vqfibWsBDWkawCFJfok5BOV+KtlcEa9nc/1CUOKs/TfSXpd90zJlj9zLdLdr6eEJQgdc WmcfsbzdCwoIowHW+z1ePBryKxjaqhxzqenC6leXWsfBimbk8rCOrB5uhR7PWvtCy6VU L2BCgMg16kXjR4CWeJ3x/QZhMW5JOVLI62VU/wOw5wK60N402QkhEeO2rEv4MEnfUG+z dDVA== X-Gm-Message-State: AOAM533Mnpmh72qVPxptffoX0WPMEr+3QMqDjz1006Wt0f8n6n8GwSFG q45k3nLc9eXK2at7B34k45IgKLY+KTzj2+iKkfU= X-Google-Smtp-Source: ABdhPJxkpe2eweO03GnAdVw6MTsZhaesQdgnccVMHj/rdeXRTqToErbZ8HpgVo4GMXEnS+x8MC4xe4DyBZ86efyJaCk= X-Received: by 2002:a05:6122:2089:b0:357:d4b4:e02f with SMTP id i9-20020a056122208900b00357d4b4e02fmr15592420vkd.35.1654009648432; Tue, 31 May 2022 08:07:28 -0700 (PDT) MIME-Version: 1.0 References: <20220527032504.30341-1-yee.lee@mediatek.com> <05cfaf936a0c5f37f2e7ba779a8a1b0a6252be96.camel@mediatek.com> <64281aab-0301-7237-d72c-b7ab41bf50e4@gmail.com> In-Reply-To: From: patrick wang Date: Tue, 31 May 2022 23:07:16 +0800 Message-ID: Subject: Re: [PATCH] mm: kmemleak: Skip check in kmemleak_*_phys when pfn bound is not ready To: Catalin Marinas Cc: Yee Lee , linux-kernel@vger.kernel.org, Kuan-Ying.lee@mediatek.com, Andrew.Yang@mediatek.com, Sunny.Kao@mediatek.com, chinwen.chang@mediatek.com, Andrew Morton , Matthias Brugger , "open list:MEMORY MANAGEMENT" , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" , Ariel Marcovitch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 15C3720072 X-Stat-Signature: rzjfiqwp78du15doy1fptp931cmh4sua Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RHaSGOpQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf31.hostedemail.com: domain of patrick.wang.shcn@gmail.com designates 209.85.221.175 as permitted sender) smtp.mailfrom=patrick.wang.shcn@gmail.com X-HE-Tag: 1654009608-156135 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 Mon, May 30, 2022 at 10:57 PM Catalin Marinas wrote: > > Hi Patrick, > > On Mon, May 30, 2022 at 09:32:18PM +0800, Patrick Wang wrote: > > On 2022/5/30 10:27, Yee Lee wrote: > > > On Fri, 2022-05-27 at 21:39 +0800, patrick wang wrote: > > > > On Fri, May 27, 2022 at 11:25 AM wrote: > > > > > From: Yee Lee > > > > > > > > > > In some archs (arm64), memblock allocates memory in boot time whe= n > > > > > the pfn boundary (max_pfn/min_pfn) is not ready. The lowmen check= s in > > > > > kmemleak_*_phys() drop those blocks and cause some false leak ala= rms > > > > > on common kernel objects. > > > > > > > > > > Kmemleak output: (Qemu/arm64) > > > > > unreferenced object 0xffff0000c0170a00 (size 128): > > > > > comm "swapper/0", pid 1, jiffies 4294892404 (age 126.208s) > > > > > hex dump (first 32 bytes): > > > > > 62 61 73 65 00 00 00 00 00 00 00 00 00 00 00 00 base.......= ..... > > > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...........= ..... > > > > > backtrace: > > > > > [<(____ptrval____)>] __kmalloc_track_caller+0x1b0/0x2e4 > > > > > [<(____ptrval____)>] kstrdup_const+0x8c/0xc4 > > > > > [<(____ptrval____)>] kvasprintf_const+0xbc/0xec > > > > > [<(____ptrval____)>] kobject_set_name_vargs+0x58/0xe4 > > > > > [<(____ptrval____)>] kobject_add+0x84/0x100 > > > > > [<(____ptrval____)>] __of_attach_node_sysfs+0x78/0xec > > > > > [<(____ptrval____)>] of_core_init+0x68/0x104 > > > > > [<(____ptrval____)>] driver_init+0x28/0x48 > > > > > [<(____ptrval____)>] do_basic_setup+0x14/0x28 > > > > > [<(____ptrval____)>] kernel_init_freeable+0x110/0x178 > > > > > [<(____ptrval____)>] kernel_init+0x20/0x1a0 > > > > > [<(____ptrval____)>] ret_from_fork+0x10/0x20 > > > > > > > > > > This patch relaxs the boundary checking in kmemleak_*_phys api > > > > > if max_low_pfn is uninitialzed. > > > > > > > > > > Fixes: 23c2d4 (mm: kmemleak: take a full lowmem check in kmemleak= _*_phy) > > BTW, please use at least 12 characters for the git sha1, the above is > ambiguous. > > > > > > Signed-off-by: Yee Lee > > > > > --- > > > > > mm/kmemleak.c | 8 ++++---- > > > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/mm/kmemleak.c b/mm/kmemleak.c > > > > > index a182f5ddaf68..6b2af544aa0f 100644 > > > > > --- a/mm/kmemleak.c > > > > > +++ b/mm/kmemleak.c > > > > > @@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan); > > > > > void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, i= nt min_count, > > > > > gfp_t gfp) > > > > > { > > > > > - if (PHYS_PFN(phys) >=3D min_low_pfn && PHYS_PFN(phys) < m= ax_low_pfn) > > > > > + if (!max_low_pfn || (PHYS_PFN(phys) >=3D min_low_pfn && P= HYS_PFN(phys) < max_low_pfn)) > > > > > > > > Just skip checking will bring the crash possibility back. Seems > > > > it's beyond these interfaces' handle scope for this situation, > > > > since "min_low_pfn" and "max_low_pfn" are depending on arches. > > > > > > Yes, for the cases beyond the pfn guard, users have to take care the > > > boundary by themselves. > > > > Could we record these early calling and deal with them when it's > > ready? Is this appropriate? > > > > I have an implementation based on this approach. Could you please > > help to have a test on your machine as well? And someone to take > > a look or review? > > We had something similar until 5.4, removed by commit c5665868183f ("mm: > kmemleak: use the memory pool for early allocations"). It was a bit > painful as we never had the right buffer, so I'm not keen on adding it > back. Agreed. > > From 82cae75dfaa78f414faf85bb49133e95159c041a Mon Sep 17 00:00:00 2001 > > From: Patrick Wang > > Date: Mon, 30 May 2022 18:38:23 +0800 > > Subject: [PATCH] mm: kmemleak: record early operations and handle later > > > > The kmemleak_*_phys() interface uses "min_low_pfn" and > > "max_low_pfn" to check address. But on some architectures, > > kmemleak_*_phys() is called before those two variables > > initialized. Record these early operations and handle them > > when kmemleak_*_phys() are ready. > > Could we instead record everything (no checks) but later avoid scanning > if below min or above max_low_pfn? We can add an OBJECT_PHYS flag to all > objects allocated via kmemleak_*_phys() and always check the > virt_to_phys() boundaries at scan time. It may actually help with this > problem as well: > > https://lore.kernel.org/r/9dd08bb5-f39e-53d8-f88d-bec598a08c93@gmail.com Check in kmemleak_*_phys() even recorded early operations, the condition still relies on archs somewhat and is not that clear. Checking at scan time should be a proper direction. So that kmemleak doesn't have to rely on archs. I have implemented it in this direction, and I believe it=E2=80=98s also helpful for the above false positive report. Thanks, Patrick > > -- > Catalin