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 41A5AC433F5 for ; Fri, 18 Mar 2022 19:44:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C2688D0002; Fri, 18 Mar 2022 15:44:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84A998D0001; Fri, 18 Mar 2022 15:44:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C5058D0002; Fri, 18 Mar 2022 15:44:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 5B9AE8D0001 for ; Fri, 18 Mar 2022 15:44:42 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1224A18259C51 for ; Fri, 18 Mar 2022 19:44:42 +0000 (UTC) X-FDA: 79258534404.25.2AEA334 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf03.hostedemail.com (Postfix) with ESMTP id 8E30920029 for ; Fri, 18 Mar 2022 19:44:41 +0000 (UTC) Received: by mail-wr1-f47.google.com with SMTP id q8so1670775wrc.0 for ; Fri, 18 Mar 2022 12:44:41 -0700 (PDT) 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:references:cc:in-reply-to:content-transfer-encoding; bh=qXhYkigGj58/kff3HsWg1q2EAJtN0NrPwvHJP2N2yHs=; b=LCG+pqfyA51m/hQyZojANHy+BNe3EWJo1YAokXmurzvxmLacOfUkaY/6pMDWDTlK0Y BPJ0rnVo+BHnDiKqcP/PRk68U33Ftsrj7DoGV2SChBWeEKqpOWNm5weBNXd2QLsymktT UpQRq6jZ0U9uiiW005AqBADkgMEUTmwJJw8N4dMKDq4V8F814XBkt6zpnAeWk1KQpMC3 2XIlI5e6ltDBzoiRT8WowX9HWmnfTlv+6EuPP3TMa/5K8sonnV7Km997L7eTepQFayyR QL/s4Xtkl0KJwA6f+BFPCFJxI8j/3H2zCIgrppUzdXchGpSRfMKPSWYr89u2BxXu9iln Pr7Q== 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:references:cc:in-reply-to :content-transfer-encoding; bh=qXhYkigGj58/kff3HsWg1q2EAJtN0NrPwvHJP2N2yHs=; b=y2q/v5jnsachydvRcs0aZlPko5IEGC+UPTtki05yGNb3Ijm5qe044Vxzd8jgSucNKI 3v2/mFG323+vYyf7pAjQ9sIgZs8rIQXODsmhAerfCATxL0aB9Eo5n2RIO86yg23s3J96 bmYtdrpWFLAPsOjP9X5BeJZJxVq7jIxlnd1udyeJlVKsL02DlU5v9It1GLgckOllFwa9 yWQjEbYVwTb81ijDqR6tLrcxgBiMEbN3MKq60SGTwqiXsXWg2S4AhIVLMf7WcbZreU4T YKr6Kx2FCKVTf66ahsmy+9dewe4jJstkwMlgVTqgYat9yH5ZNCVB6XwK8cTHdtvfRMjV B3HA== X-Gm-Message-State: AOAM533yGf0HiI8kfBspRoVh7LhNxROib5UPJHb/WsOFz5Uy3cgGSExN W23jHnZHQaorrFZvVurVnjI= X-Google-Smtp-Source: ABdhPJz4d0DU/jd1bZak7G6edgrQW/g3NgZ42WbuYK61+AmFosseRfB0yCqCv26vE8P3n7ZLEo5dxw== X-Received: by 2002:a5d:6c6b:0:b0:1ea:77ea:dde8 with SMTP id r11-20020a5d6c6b000000b001ea77eadde8mr9533625wrz.690.1647632680165; Fri, 18 Mar 2022 12:44:40 -0700 (PDT) Received: from ?IPV6:2a00:a040:197:458f:39cc:ea22:7ce4:89b9? ([2a00:a040:197:458f:39cc:ea22:7ce4:89b9]) by smtp.gmail.com with ESMTPSA id w5-20020a5d5445000000b00203f8c96bcesm1767744wrv.49.2022.03.18.12.44.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 12:44:39 -0700 (PDT) Message-ID: <5d7caa39-9156-0db1-688c-eafe4007a492@gmail.com> Date: Fri, 18 Mar 2022 21:44:38 +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 References: <1e976df3-2925-f6c6-6723-67f127b9e544@gmail.com> Cc: christophe.leroy@csgroup.eu In-Reply-To: <1e976df3-2925-f6c6-6723-67f127b9e544@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Rspamd-Queue-Id: 8E30920029 X-Stat-Signature: memgm3n466ts8qwfnkenrxesmhoi69bg X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=LCG+pqfy; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of arielmarcovitch@gmail.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=arielmarcovitch@gmail.com X-Rspamd-Server: rspam02 X-HE-Tag: 1647632681-106966 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: Pinging again :) On 25/02/2022 0:27, Ariel Marcovitch wrote: > 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=20 >> kernel 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 dev= ice_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_HIGH= MEM) || 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 zon= e. >> >> 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=20 >> far as kmemleak_alloc_phys() is concerned, every memory is HIGHMEM (:=20 >> and the allocated memory is not tracked by kmemleak, causing=20 >> references to objects allocated later with kmalloc() to be ignored=20 >> and these objects 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! >>