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 E9080C433EF for ; Fri, 18 Feb 2022 19:45:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BD7E6B0075; Fri, 18 Feb 2022 14:45:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 56D3A6B0078; Fri, 18 Feb 2022 14:45:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E8B46B007B; Fri, 18 Feb 2022 14:45:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0113.hostedemail.com [216.40.44.113]) by kanga.kvack.org (Postfix) with ESMTP id 2C1E76B0075 for ; Fri, 18 Feb 2022 14:45:56 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E866D181AEF0B for ; Fri, 18 Feb 2022 19:45:55 +0000 (UTC) X-FDA: 79156931070.12.6CA8726 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf28.hostedemail.com (Postfix) with ESMTP id 61EECC0006 for ; Fri, 18 Feb 2022 19:45:55 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id k25so17306538ejp.5 for ; Fri, 18 Feb 2022 11:45:55 -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:content-language:to:from :subject:content-transfer-encoding; bh=TnkmE51UkNMsCcfFfMpS33esSVozAPP7mpptFWEYpDM=; b=dKSzoS/3aMC9ZRTMRyoosCDwk0ZSwBgTYl7XOfoKh4dfyzYc0fm4Gex4e8pwyOivcP SYAJlV3s0lYSSGU7TjYA717k0mEzY4L+r0w2xUh0A1LafHFru6PLi9IXvCbEDEaJRMQ1 5iKvU1QviQ6hvuziixKIgraX1Pj7S7s/2x7dMeeWDNMaCoOmeIE/NjNnBkB/c93f1ZCq wfY7XSIqb6EGClIXRzo95STJU1+3WiAyTHMdyyebIvKGEIhAo9eohREh9rW5BIvM+8vJ tCX59RL/RbirgTbFao0An00pgMqcG2xL2b+OXt/tKz2LHvzgECYKFJmZd16VU1r69UJw VMnA== 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 :content-language:to:from:subject:content-transfer-encoding; bh=TnkmE51UkNMsCcfFfMpS33esSVozAPP7mpptFWEYpDM=; b=Pdx48ui6s2Zqf4ZNtxOQ48Hk7rbGD8T5bl1nowUyYVWxVU/0hUToue+7RPX5ah/xjw 65ThCBxKCIjg6tOALqSfXaKYluCXT0bh+iI4hGeC48nd+a34aiL8LBgK9qVXONheamHE 1D8TE1vUTETroX01/Q+/Z77AX+51FuCZgNqjc70ZgwqmdH+SolAyNgSxzV2vRqlK7hjK MwxOzu9CvuLd8qmEI8hZ4nulcaEYFRQeUSZWgtRYWETxFN36ogSyn43lB+g5Yt9FtXmG 8E5mVwuTatpAGSLNEUE6OcoTlYg7jxl4SvBdpUBlyA38OiK6PRU1l8GV4ostAa8mh1Rz o49w== X-Gm-Message-State: AOAM532bYA1PLO/1sBx4V/m6oB+9CFRu1bJ4UOr+HejCLAs55DJbqDMc nOYlFcMqZzDNMozjcC512TU= X-Google-Smtp-Source: ABdhPJxHrwyJCxDhLFrjCzW69ZvfsjmR+IMuhgAuKO0gzs2uTEtYDNQO2rPGEtUNikscE07/abTwUw== X-Received: by 2002:a17:906:9b88:b0:6d0:f843:4068 with SMTP id dd8-20020a1709069b8800b006d0f8434068mr195022ejc.678.1645213554058; Fri, 18 Feb 2022 11:45:54 -0800 (PST) Received: from ?IPV6:2a00:a040:197:458f:c93a:90a3:1c34:c6d2? ([2a00:a040:197:458f:c93a:90a3:1c34:c6d2]) by smtp.gmail.com with ESMTPSA id o12sm412793ejg.105.2022.02.18.11.45.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Feb 2022 11:45:53 -0800 (PST) Message-ID: <9dd08bb5-f39e-53d8-f88d-bec598a08c93@gmail.com> Date: Fri, 18 Feb 2022 21:45:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US 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 From: Ariel Marcovitch Subject: False positive kmemleak report for dtb properties names on powerpc Content-Type: text/plain; charset=UTF-8; format=flowed Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="dKSzoS/3"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of arielmarcovitch@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=arielmarcovitch@gmail.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 61EECC0006 X-Stat-Signature: qijzqkiwgc9hi314rqkeawjd7u79zw1y X-HE-Tag: 1645213555-566459 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: 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 first=20 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 devic= e_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 for=20 the dtb nodes and properties. These are definitely not leaked, as they are even visible to the user as=20 the sysfs file names. These strings (for dtb properties, in the case of the shown report, but=20 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. This=20 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 min_cou= nt, =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_HIGHME= M) || 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 not=20 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, so=20 I wanted to hear your opinions first Thanks!