Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp2002099lfo; Sat, 28 May 2022 13:26:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsj5JPkfg2z+GP3DWewwDpH8pMm2YNuTK3LKuRizxFZLljsSdqcxLbJ5HWvMnTk3CA9UHP X-Received: by 2002:a05:6a00:1897:b0:518:8bc7:9a82 with SMTP id x23-20020a056a00189700b005188bc79a82mr36106081pfh.26.1653769565796; Sat, 28 May 2022 13:26:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653769565; cv=none; d=google.com; s=arc-20160816; b=FXeWXcn4ONh3ox6BAOEyEfR2PJPi6c3MoMwPhK/BrvR4DXbPp1AQhtW1wJvgNHghqY pFbQ8EKGvA7yICTFpUv45fxS6H2RLchbrgtB6EcJNPWQGW4e2ji6jQI7QmKiPdW6iTcH Ts92teABsTQpNJl42vHktrJh72QvnMc7c53/TiMy/JpLfcdkQ/Qs3FLb7qi/BIBtOpgn WTUt2PvFWKJJVcsKAO5U/EkRXZ4YS2vj7fT1V2g+yG3JzMBluJqvyTf6XhFgoI/WOPFq yZta5kJtS47W1yQj+X+O3eTbP/1gdouk15xtVNF2IuIK+BZup7EmFL0TDkAmQ/vlJObw dL7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=hqlg/w/fu3XfRPgdp6en7FxQt+ggN/0l4WsjVJitcVw=; b=U8gDWmO/u3/CGUtp3Dgg2ydai7L68VcE2iLbftjT2R3okkk4pzAJ0go/uSGhojw/YJ x3tQpkpCtx+qodkDzGu0ARnLK16IsZ3KSIz1z4FEB3QgaAniTIl49oSBT8R6u3ozqe0+ n/4XyrpmMegJ37sEhtixGw1ZLHpyrb14agCPZrkC4LI4RxzMZPXfMi9IG5HQQ+419Yxl u2si1UHGbnveR19njgmRtsf92SWcEiRF3ZR/P/ekXE42/4+H9lE3nr7bAlevpkzi5obC lRqzn3mQZi5/TeCsM+ezGG7AB6rIcc4vm0APp4UL33iughU1WeYJtGRjkMxqZpnkBG4g OVjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=E2N132fv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id l2-20020a170903244200b0015d1614f31asi12630903pls.376.2022.05.28.13.26.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 13:26:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=E2N132fv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 35BF517EC2A; Sat, 28 May 2022 12:33:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352335AbiE0Nja (ORCPT + 99 others); Fri, 27 May 2022 09:39:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240544AbiE0Nj2 (ORCPT ); Fri, 27 May 2022 09:39:28 -0400 Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F70A146741 for ; Fri, 27 May 2022 06:39:25 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id j7so4267728vsp.12 for ; Fri, 27 May 2022 06:39:25 -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=AyB24sn5t2FkFSZbK1AsC02C59xYUEty4/YUi6YxB5SmsUxZC6M0Q5QHKJUmrH4rNr 8wX1VXnHOcKfhh3XGP+sZ7RgMsy7Wfo4C5vu0rvdKNPdcXCC7kxBEM0QeYlnDBkH3dvG Do/PnOYMwU2eKJ/JbfRORJ5bOHJHv+fRH2NvJMc6Eg8LKVhGLLvX6yP9PUJM+ZV7Mp2R 2YKxtypHFftnPOi6zl64rwZAQMC0mA6fViM7QHy27FzO3MQra9TMqQFWVLjeGMaG6moo ZGyNOE7JTQHBb5wq4eO35aSwAyBMN+/oWAOI8ZGSQkAOjH+irBMUPHekj2JnB8nahkXL 67JQ== X-Gm-Message-State: AOAM530rFMwToG3J0TtDBq4npjHX0IbNqEQuTnf19vYrFme/1Cvtf6ve hHSBjVSqypy1AKqIgLsWgu8YcMR43ZP1hfg4b2M= 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-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 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 >