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 51B46C433EF for ; Thu, 24 Feb 2022 22:27:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC13D8D0002; Thu, 24 Feb 2022 17:27:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B70F18D0001; Thu, 24 Feb 2022 17:27:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A37D28D0002; Thu, 24 Feb 2022 17:27:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id 932968D0001 for ; Thu, 24 Feb 2022 17:27:25 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 2CE6C181D7EC9 for ; Thu, 24 Feb 2022 22:27:25 +0000 (UTC) X-FDA: 79179110850.24.4C0B84D Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf07.hostedemail.com (Postfix) with ESMTP id D27EE40007 for ; Thu, 24 Feb 2022 22:27:24 +0000 (UTC) Received: by mail-wm1-f52.google.com with SMTP id l1-20020a7bcf01000000b0037f881182a8so656789wmg.2 for ; Thu, 24 Feb 2022 14:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language :from:to:content-transfer-encoding; bh=2Po0su4OQcLwD05ycOpYEUEszvD751jwueFeSIX1Bho=; b=Qyw2vcM4btgWfaluW8pKS/moQhpNh/TZ3cE53BIXTMb8mk9+SYXnRBax4x9Syyt/QD d9TkB1PDTkGrYzOzUQc4fHSOLZHM2O98a4kcp7cZG9sAzfxm7ZppiS4IFDeHo1/RdqCx 4lJrI6BAV4bvUNNTh32xWpGwCsDcv217oiPIDVyMETHxmTUN/3JsagXMYdNWt2qjxXWy bAu/0TM4vZalGHNMF/a1lzi7RJGBnwIv7bQtTgdNZkYiYM3KEYGHXagtY45+W8ucF+l4 pF5HULAt5uQC55NxUMFei/HVMfyrcrRkJV706QJT2OboiPhJpGkY+opjeNnZfjGtJ8M5 sMEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:from:to:content-transfer-encoding; bh=2Po0su4OQcLwD05ycOpYEUEszvD751jwueFeSIX1Bho=; b=DUnHOHL9exKJ3lGKMgtp5RsJVG7wyCyy6ZNBK4WXL4LZfo9rHcMrBmq0d7wzvnZrmM pyprmtd3Tj8mfw8y+GqgltA2cnRQNbmIzH96pZ132ijq9Pkxdj/98hSanNB1T9LPF3W0 2WILf1SZ5D3jeFCbgqVamWpa+OsD66+1nvOeXr6F0fY41+Gedeuc6btGvKfU9rLJK6/C Ib7k5iGhP49aVP7wrqmlz7Sy5L8aGWc6t4FKopZVJMbA8TdMP3nxqOC8BeqEpQLtFtAw dwgUEU2mds4jT1BFbjzzmaC6+CyaXvGFrv0nCVkW3YJlL5gRl8ALHt26baBkxt6lfYSf gEBw== X-Gm-Message-State: AOAM530VF2PIsIzipIM3/hai1p/ITndK908v8qn26e3bC6Abzyq92nRg Q/Tr6D5t9aFV+jUsivtBFec= X-Google-Smtp-Source: ABdhPJzOirp7GVopNHMhr7m/DqyvKKDcPOT5QKM44AbjfpcZHJBBYhn+3WKEhp5Ijabtkn/KpREwZQ== X-Received: by 2002:a1c:a483:0:b0:380:c27c:225b with SMTP id n125-20020a1ca483000000b00380c27c225bmr157750wme.121.1645741643402; Thu, 24 Feb 2022 14:27:23 -0800 (PST) Received: from ?IPV6:2a02:6680:1100:883:dfa4:b9d3:d1f9:d299? ([2a02:6680:1100:883:dfa4:b9d3:d1f9:d299]) by smtp.gmail.com with ESMTPSA id n8-20020a5d6608000000b001e73a0f21ffsm582697wru.6.2022.02.24.14.27.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Feb 2022 14:27:23 -0800 (PST) Message-ID: <1e976df3-2925-f6c6-6723-67f127b9e544@gmail.com> Date: Fri, 25 Feb 2022 00:27:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: False positive kmemleak report for dtb properties names on powerpc Content-Language: en-US From: Ariel Marcovitch To: catalin.marinas@arm.com, akpm@linux-foundation.org, mpe@ellerman.id.au, benh@kernel.crashing.org, paulus@samba.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Content-Type: text/plain; charset=UTF-8; format=flowed X-Rspamd-Queue-Id: D27EE40007 X-Stat-Signature: 5jimbckq9f1wimd4f8kz8f5w98pep4go X-Rspam-User: Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Qyw2vcM4; spf=pass (imf07.hostedemail.com: domain of arielmarcovitch@gmail.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=arielmarcovitch@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam05 X-HE-Tag: 1645741644-922865 Content-Transfer-Encoding: quoted-printable 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: Ping :) On 18/02/2022 21:45, Ariel Marcovitch wrote: > Hello! > > I was running a powerpc 32bit kernel (built using=20 > qemu_ppc_mpc8544ds_defconfig > buildroot config, with enabling DEBUGFS+KMEMLEAK+HIGHMEM in the kernel=20 > config) > on qemu and invoked the kmemleak scan (twice. for some reason the=20 > first time wasn't enough). > > (Actually the problem will probably reproduce on every ppc kernel with > HIGHMEM enabled, but I only checked this config) > > I got 97 leak reports, all similar to the following: > > ``` > > unreferenced object 0xc1803840 (size 16): > =C2=A0 comm "swapper", pid 1, jiffies 4294892303 (age 39.320s) > =C2=A0 hex dump (first 16 bytes): > =C2=A0=C2=A0=C2=A0 64 65 76 69 63 65 5f 74 79 70 65 00 00 00 00 00 devi= ce_type..... > =C2=A0 backtrace: > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] kstrdup+0x40/0x98 > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] __of_add_property_sysfs+0xa4/0x10c > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] __of_attach_node_sysfs+0xc0/0x110 > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] of_core_init+0xa8/0x15c > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] driver_init+0x24/0x3c > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] kernel_init_freeable+0xb8/0x23c > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] kernel_init+0x24/0x14c > =C2=A0=C2=A0=C2=A0 [<(ptrval)>] ret_from_kernel_thread+0x5c/0x64 > ``` > > The objects in the reports are the names of the sysfs files created=20 > for the dtb > nodes and properties. > > These are definitely not leaked, as they are even visible to the user=20 > as the sysfs file names. > > These strings (for dtb properties, in the case of the shown report,=20 > but the case with dtb nodes is very similar) are created in=20 > __of_add_property_sysfs() and the pointer to them is stored in=20 > pp->attr.attr.name (so, actually stored in the memory pointed by pp) > > pp is one of the dtb property objects which are allocated in=20 > early_init_dt_alloc_memory_arch() in of/fdt.c using memblock_alloc.=20 > This happens very early, in setup_arch()->unflatten_device_tree(). > > memblock_alloc lets kmemleak know about the allocated memory using=20 > kmemleak_alloc_phys (in mm/memblock.c:memblock_alloc_range_nid()). > > The problem is with the following code (mm/kmemleak.c): > > ```c > > void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int=20 > min_count, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gfp_t gfp) > { > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!IS_ENABLED(CONFIG_HIGHM= EM) || PHYS_PFN(phys) < max_low_pfn) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 kmemleak_alloc(__va(phys), size, min_count, gfp); > } > > ``` > > When CONFIG_HIGHMEM is enabled, the pfn of the allocated memory is=20 > checked against max_low_pfn, to make sure it is not in the HIGHMEM zone= . > > However, when called through unflatten_device_tree(), max_low_pfn is=20 > not yet initialized in powerpc. > > max_low_pfn is initialized (when NUMA is disabled) in=20 > arch/powerpc/mm/mem.c:mem_topology_setup() which is called only after=20 > unflatten_device_tree() is called in the same function (setup_arch()). > > Because max_low_pfn is global it is 0 before initialization, so as far=20 > as kmemleak_alloc_phys() is concerned, every memory is HIGHMEM (: and=20 > the allocated memory is not tracked by kmemleak, causing references to=20 > objects allocated later with kmalloc() to be ignored and these objects=20 > are marked as leaked. > > I actually tried to find out whether this happen on other arches as=20 > well, and it seems like arm64 also have this problem when dtb is used=20 > instead of acpi, although I haven't had the chance to confirm this. > > I don't suppose I can just shuffle the calls in setup_arch() around,=20 > so I wanted to hear your opinions first > > Thanks! >