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 D75E3C38147 for ; Wed, 18 Jan 2023 17:16:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7AB536B0074; Wed, 18 Jan 2023 12:16:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75B596B0078; Wed, 18 Jan 2023 12:16:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64AE36B007B; Wed, 18 Jan 2023 12:16:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5884D6B0074 for ; Wed, 18 Jan 2023 12:16:56 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 13A7340975 for ; Wed, 18 Jan 2023 17:16:56 +0000 (UTC) X-FDA: 80368574832.29.F003091 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf21.hostedemail.com (Postfix) with ESMTP id 6EE611C000E for ; Wed, 18 Jan 2023 17:16:54 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf21.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674062214; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QqpOmftDwK/5fvANcwPPTY7qnf7kkztabeRrb8zMTRc=; b=i4wn8uslCUlldviZjgKNo5+OSfjTxSWwllMK44Juaa5pWXjgTCpxBNNm7vcv3kZZT4ra3C EhSSbJOP9sFTGSDrU0rxhDHLk/+5SKh+oIwYUrG9+tcqjNCmkV7zNtGnjFi6lZP/ASqPFy wCr18iqnLEpM67sEK3ttdO5RJLP3Sb4= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf21.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674062214; a=rsa-sha256; cv=none; b=U2WFUwReo0D9bWazmrPv/l/3LNx3hvMZ0iXqWVowxwz9U3u5cEE5PJNjlhkLNVdQga6diM bGgIuOK/BapNzJIgwCDZGPLdatGksVgQ3AYkWT6/42lzro+gYIzS88N4L9Cfy+cZXMgI0i fGL6o9vOkMXuTCpB4DRtWwNRr/I9rbc= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6F7A4B81DE6; Wed, 18 Jan 2023 17:16:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98E9EC433EF; Wed, 18 Jan 2023 17:16:49 +0000 (UTC) Date: Wed, 18 Jan 2023 17:16:46 +0000 From: Catalin Marinas To: "Isaac J. Manjarres" Cc: Andrew Morton , Saravana Kannan , Suren Baghdasaryan , kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 0/2] Fixes for kmemleak tracking with CMA regions Message-ID: References: <20230109221624.592315-1-isaacmanjarres@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230109221624.592315-1-isaacmanjarres@google.com> X-Rspamd-Queue-Id: 6EE611C000E X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: izcd4bhrnrcz41d7taw8ut9n77s4q9af X-HE-Tag: 1674062214-75507 X-HE-Meta: U2FsdGVkX1+DGsb9FlzVyiCk1Dow1VE+3ew2IY8kp0N5Y8BCpVmPCxzfNFYTVMisN/RajZdtJS8bA0JTKamX9ahWQ85C7RDA+FSVtGYGF74032XSp+ED7JGYpog09TvhHbLTlmvXKr/LPfOhmwImgAA66OJVhEKpcYIu9BdqMfe2xWXvN4lFyYb8mIL0/hFmanu5v2YkP0f43cFuxy7Ek4RJaRTaScer4j1t6d74tCUbK4UVTl90cN+gb7r8PIajBgVohEu6lniV19bDIgLd51ocbLvpszYx7gx0+OKmU+Tyyxm9LzOYVjGgHOGIXOitLMu8Obi0ojC+JkF3M9ZSFoEV7Q/lFqg9ovbVRyIs8u7ozYmHZ3PHiKm4K5NkMj+YEAPojJ4lgc52MR9OZbjJrj+wQZmt+f9dJArWZhD6QdYLIaEks8r2ar7ZU6IaRAJnWAQEz3SdN3ChyiZ9e3FXQe7IoVdbpi+fuBo5A+5Vip2TGiskTBe8wJxMOTg+KHCmYVGALkUOG5yC4grhoUcqI0Duxhx++9oTZIwd2sZzPF0vE8GDTiT01lWFDRRh3213r/LxWag69EpQpx/wrIfVZ3O6QXJM62ATSB5vGxTIEA1UilXeBISrI1KR2XcA/YwWGWIUqgKGm2bSYhT9VoCVGUiRF74rVC3w098EMXuV4Dp+ptHMxqZfPqx4RA80LlqeuLxFbV0xS3SbjGtD25vBv8SmkJAL1FwFibwTxEsjegEUjUYQnlY1uaukTDnGe8mlBAlCjF143LZCTyblKBV433g4tWRlNvS2DglG2Dja56+rCOvIFdqqF50nSYWrxEzirvhdK34O2Z1LIsp9zgsRcdpdCcfGIm3dxlsImbwesI+33cHgS52vw/RLyU3rS0PqeL8mIwxuaNU3e07yK6wJJh632505aoc5RkamjvO4Qb2MVouROU5R+0S6RQvXo+SJXpC1qcvSqzCVlOPOiHN xPxiujU4 /b10mJEQ6o/RhoIPfwPMPfw5bEX417At1U3MiWRuNN3pRhOe96QKkEzkQzX6fK15bEtDM+lpzt1e0ADU9FMLIB6bw8UYBHCZhspkBhsVjaOAViQPckeQwfo1g+894kFqd2HBXFGjZwrqcn5tpj1lIkiGEMX5Z16ZqutGh 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: Hi Isaac, Please cc me on kmemleak patches. I only noticed when Andrew picket them up. On Mon, Jan 09, 2023 at 02:16:21PM -0800, Isaac J. Manjarres wrote: > When trying to boot a device with an ARM64 kernel with the following > config options enabled: > > CONFIG_DEBUG_PAGEALLOC=y > CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT=y > CONFIG_DEBUG_KMEMLEAK=y > > a page-fault is encountered when kmemleak starts to scan the list of gray > or allocated objects that it maintains. Upon closer inspection, it was > observed that these page-faults always occurred when kmemleak attempted > to scan a CMA region. What I don't understand is why kmemleak scans such CMA regions. The only reason for a kmemleak_ignore_phys() call in cma_declare_contiguous_nid() is because the kmemleak_alloc_phys() hook was called on the memblock_alloc_range_nid() path, so we don't want this scanned. Do you have a backtrace? > At the moment, kmemleak is made aware of CMA regions that are specified > through the devicetree to be created at specific memory addresses or > dynamically allocated within a range of addresses. However, if the > CMA region is constrained to a certain range of addresses through the > command line, the region is reserved through the memblock_reserve() > function, but kmemleak_alloc_phys() is not invoked. The combination of kmemleak_alloc_phys() + kmemleak_free_part_phys() in your series is equivalent to not adding it at all in the first place. > Furthermore, > kmemleak is never informed about CMA regions being freed to buddy at > boot, which is problematic when CONFIG_DEBUG_PAGEALLOC is enabled, as > all CMA regions are unmapped from the kernel's address space, and > subsequently causes a page-fault when kmemleak attempts to scan any > of them. kmemleak would only scan such objects if it knows about them. So I think it's only the case where CMA does a memblock allocation. The kmemleak_ignore_phys() should tell kmemleak not to touch this region but it's probably better to just free it altogether (i.e. replace the ignore with the free kmemleak callback). Would this be sufficient for your scenario? > This series makes it so that kmemleak is aware of every CMA region before > they are freed to the buddy allocator, so that at that time, kmemleak > can be informed that each region is about to be freed, and thus it > should not attempt to scan those regions. I may be missing something but I don't get why kmemleak needs to be informed only to tell kmemleak shortly after to remove them from its list of objects. -- Catalin