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 B25A9C433F5 for ; Fri, 27 May 2022 13:39:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D29B48D0010; Fri, 27 May 2022 09:39:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD5BE8D0002; Fri, 27 May 2022 09:39:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC6E28D0010; Fri, 27 May 2022 09:39:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AE5BC8D0002 for ; Fri, 27 May 2022 09:39:25 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7F8D535650 for ; Fri, 27 May 2022 13:39:25 +0000 (UTC) X-FDA: 79511629890.01.457EDEA Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) by imf09.hostedemail.com (Postfix) with ESMTP id 9BD8D1400A6 for ; Fri, 27 May 2022 13:39:11 +0000 (UTC) Received: by mail-vs1-f44.google.com with SMTP id m2so4285876vsr.8 for ; Fri, 27 May 2022 06:39:24 -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; bh=hqlg/w/fu3XfRPgdp6en7FxQt+ggN/0l4WsjVJitcVw=; b=E2N132fvML6LrBTQk8CEDkWoE7iy6xHPtSdsWWbkkJ9qx2SDmdbsk/2gZz41g52LIE TcZrptshVkbF1zidVo3NqoiA1Uj+rRgGCrItspUx/MsbD65NZ8wCsJ+43tj4gSeOdyJT PDceHpT5Vc6O6aiNnu+WO7zRsm/ZUcsQBLdfKAu0+d55JKS4L707dtA0tKPlQhZPO4AQ oOFpQsdwi00qCGrzgNViGIUY0Y1RE5lk7BpBlg5pEVPibtdTb9whrFBl5rzaxws2CT+a sBxIiY+cNOSyLigrEBXnMpZvAUdhsyip742SYxRJRmSF4QJYeqSgWjShR9cflZxibk0M Uodw== 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; bh=hqlg/w/fu3XfRPgdp6en7FxQt+ggN/0l4WsjVJitcVw=; b=3D+lwWs/vUhgJl+ezo1lapjX3dFHcoHvBKl+/AJD88O5V+ZFUijbBGELBHDfq9WC5C TtTWiJ+Z/lUK2QSxltDDh4V4cejoeCq5I3RmrRMZBsJDMkiHUyNLolo7At5ZV5mcksHc okZ61tLeyhzKeNAd4294be0ZoU7yCd0fm5jSqoZL2Vwe+aknPI2DiwbARYKQhvQCm1Ml RvUuzuWEz8p+3TK+fm+lnkj+Mpn0FArlMl6J3WG1l9lyjnZMrQEoxLymt1q2wez+42cw 2kf8n4egn9KBdOEZ9v9yhapEivkf2/Vqy/qIYGlR2Wzinjns2sBLcoX2wULcJu+D2vNX gdWQ== X-Gm-Message-State: AOAM533oHHx6Btc2pdEGXTOZAm/uouuHMVORB8xWdWJTqdx+bGnPJ+Uy NbWBXriu95cp+CgmPZ/M51OMDJ1uDIvyNRg2amU= X-Google-Smtp-Source: ABdhPJySDv0PWTGe7FNJUI4axliR/+waikOZH4xVOoaC6lc/giZe/1RKNxnwujNEmpiXphYOtn97ISHWrkU6BVu3v/M= X-Received: by 2002:a67:d808:0:b0:337:8cab:6c00 with SMTP id e8-20020a67d808000000b003378cab6c00mr14451432vsj.66.1653658764178; Fri, 27 May 2022 06:39:24 -0700 (PDT) MIME-Version: 1.0 References: <20220527032504.30341-1-yee.lee@mediatek.com> In-Reply-To: <20220527032504.30341-1-yee.lee@mediatek.com> From: patrick wang Date: Fri, 27 May 2022 21:39:11 +0800 Message-ID: Subject: Re: [PATCH] mm: kmemleak: Skip check in kmemleak_*_phys when pfn bound is not ready To: yee.lee@mediatek.com Cc: linux-kernel@vger.kernel.org, Kuan-Ying.lee@mediatek.com, Andrew.Yang@mediatek.com, Sunny.Kao@mediatek.com, chinwen.chang@mediatek.com, Catalin Marinas , Andrew Morton , Matthias Brugger , "open list:MEMORY MANAGEMENT" , "moderated list:ARM/Mediatek SoC support" , "moderated list:ARM/Mediatek SoC support" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: q6y19p9aw987iu7o1uf7qfrar5hm7iqi X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=E2N132fv; spf=pass (imf09.hostedemail.com: domain of patrick.wang.shcn@gmail.com designates 209.85.217.44 as permitted sender) smtp.mailfrom=patrick.wang.shcn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9BD8D1400A6 X-HE-Tag: 1653658751-314749 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, May 27, 2022 at 11:25 AM wrote: > > From: Yee Lee > > In some archs (arm64), memblock allocates memory in boot time when > the pfn boundary (max_pfn/min_pfn) is not ready. The lowmen checks in > kmemleak_*_phys() drop those blocks and cause some false leak alarms > 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) > 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, int min_count, > gfp_t gfp) > { > - if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) > + if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn && PHYS_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. > kmemleak_alloc(__va(phys), size, min_count, gfp); > } > EXPORT_SYMBOL(kmemleak_alloc_phys); > @@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys); > */ > void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size) > { > - if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) > + if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)) > kmemleak_free_part(__va(phys), size); > } > EXPORT_SYMBOL(kmemleak_free_part_phys); > @@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys); > */ > void __ref kmemleak_not_leak_phys(phys_addr_t phys) > { > - if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) > + if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)) > kmemleak_not_leak(__va(phys)); > } > EXPORT_SYMBOL(kmemleak_not_leak_phys); > @@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys); > */ > void __ref kmemleak_ignore_phys(phys_addr_t phys) > { > - if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn) > + if (!max_low_pfn || (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)) > kmemleak_ignore(__va(phys)); > } > EXPORT_SYMBOL(kmemleak_ignore_phys); > -- > 2.18.0 >