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 8851CE7718B for ; Tue, 31 Dec 2024 13:16:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7DF76B007B; Tue, 31 Dec 2024 08:16:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D2E246B0082; Tue, 31 Dec 2024 08:16:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1D0A6B0083; Tue, 31 Dec 2024 08:16:10 -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 A79076B007B for ; Tue, 31 Dec 2024 08:16:10 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6D3F0AE3CB for ; Tue, 31 Dec 2024 13:16:10 +0000 (UTC) X-FDA: 82955300568.27.268B009 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id B444440015 for ; Tue, 31 Dec 2024 13:15:47 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf12.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 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=1735650912; 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=yRwRWJqQ9bSMbo2kvw7IQkQGz+H2O6t84NphjWkZ2xc=; b=tAp4X5QWwgmvVHW15DKpcum5Mebsf6WnB9qCN+bx+aE7U8BCpwXGPYBOfH/WArnJm3Ds0o Mc+9Z1j4yRw0FhXtShvi14hi90LISoWdVNOfnxaATQLYqqjeoU+Tkp/zsrfrfPRItISFGK 7T13ELNr0y9MmFlMRaIpu3+utg5zaXk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735650912; a=rsa-sha256; cv=none; b=QmcpMnEiPhhakL2ai3cC4bDkReXWOrlpw2/G7X6wCGu8arJctRC1bIuMpPGAml4WZF/Y+5 qKbp8pUH3Sdp4zjj2dhPZSnIZZsAT0igxKzgLM5PygnmNWwC6DxgjT5wL/iQ92iE+11fPB kQFzm763TXSIlZwe/njfKyWSUCFKlp0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf12.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 30F8D5C5C85; Tue, 31 Dec 2024 13:15:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59FB8C4CED2; Tue, 31 Dec 2024 13:16:06 +0000 (UTC) Date: Tue, 31 Dec 2024 13:16:04 +0000 From: Catalin Marinas To: Weikang Guo Cc: Andrew Morton , Linux Memory Management List , linux-kernel@vger.kernel.org Subject: Re: Potential Double Scanning of struct page Physical Memory by kmemleak Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B444440015 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: znf9q86poznhn74yqmyj4pdkhf3hhdtu X-HE-Tag: 1735650947-852431 X-HE-Meta: U2FsdGVkX183h0ytymzKPIQIYMF9ohGpo3D/VNaXUdZ1EG9CQd5cGHtfHGq78F113DNRFm0UcTCCxN/FQXB9YjbaUdnQ0pz5dhvPJLKuRdz+VdqYrgoT+Ka7k/Es2XJU3wvIKgEAHHaFha8j4mb46vF0EI+vx1mwdmDhd7RSDu/P0sutkcqtFfQVOXclJhM98pkS1OBuDRlDJOojSZBB6aU3tNAufE7eNuznaAiTgg91Ub9LRsuTtWKbwOBqyjxCYCalQJTmWdD5eeAaaQaapRxzsCPS7uH3bVIx7I5AWVOGXOLNpQpwMvY/2BEh2RNGMZ4oq5vtTMn9kTkScN8gaaghqMoSCnj91yqtanNEKrsUuh7dDuYTqFEj0DbWseBx7bVDBTMPto/nzmZCw63vpZgzavC4enJb/iswYjGqpbd+E8bF0wl5/ENYCytAlbDYmAYsBlmdaUam+AlewUhS/DlWJpekaowBSPEpkyvJdSviRlVW8I0fuq3rq2ApBcC0jDi/VIbpzni4nu/1IQwBBTzrqE553W7Yv0sRSTSxWsZFZgr+8918JNuQdL64Zu4awyq9wUm/mruheR4LTAxbEKNpMoJgdL7xisXe0j3tx7Cu463UD83n1/UFW77MLKXojd7Bmiz4HpKvHnuykoJur2YDw48F9aom9AiZMx5aZDfyANTaAHPhdB/mraCTzOjdgKKWzqtlv3KjerrZM8XjM0Px133xDSmsQBQkz26BV8ryEsZfojQ/YIuYZGTEhgXYowzdjh/MATz02kwsZ87P3rmM73jfUNtVn13gysgldohoGR7cQ3Yb2TxxOd/X7WmdCdw1yfg7EKWxVNf8dfsq8qu7udP5yOaHQOMwNypN/xSWTYRMJiqBwvoE7T93MHZde9Nu8SNiA0dP8IvrpVBHlqdtwm2A5vvlOacHbOXv8HhIsOLxqraqEaBULOkI0Lx/M3syUqFMXdOw6fOH0uT 6B5sI7Af oJ4U2BKXZUU5DBMyG2J72dx4EwAv4uq9cbBAbaQCV6z81dUyDAkTSwxxhoFFCGzg6oBJzcmWyyxUUYvZeYzMGssdkn22dByjbdJRqiwdKhaTYPxs4GPtKzo35ae5znko9LUn+V2gdbd3xFQckJBxuoGDiVwPog7o2eVB1ZNm8k2SGE50mWixnbHeExPnUnxDHKh4J+bDXtrWwlMbCn9k/8DHtgXI3Wkp5YOAMGyeWKRQerKSZwCAvQGxS9Eg6lAYSqAltRk841NTsZn3SWW6pnI0TZqB3AkEAnIR4ChyyS5uWCkREd6Fu2SKAOTJ5bamvM1vBfqfOckbScNLHBxyQnNJjU0SkYJYRio743+l2Pg0oNqge/pxinDCf6ZtJ+4Me7GDSR/e812H5soqnKK2yaX/DBK59CzkJSnBJ 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: List-Subscribe: List-Unsubscribe: Hi Guo, On Wed, Dec 25, 2024 at 04:09:12PM +0800, Weikang Guo wrote: > Problem Description: > > When CONFIG_SPARSEMEM is enabled, the memory for `struct page`objects > in the sections is allocated via `sparse_buffer` using the > `memblock_alloc_xxx` interface. Since memblock does not explicitly > specify `MEMBLOCK_ALLOC_NOLEAKTRACE`, kmemleak will treat the memory > as a gray object with mincount=0. In other words, the physical memory > occupied by `struct page` will be scanned by kmemleak as a gray object > during the scan thread. > > Additionally, kmemleak also traverses and scans valid struct page > objects in the zone . As a result, the physical memory occupied by > struct page may end up being scanned twice by scan thread. Yes, I can see how this happens. I don't remember how we ended up like this, maybe kmemleak did not track memblock allocations in the early days. > Possible solution: Specify `MEMBLOCK_ALLOC_NOLEAKTRACE` when alloc > `struct page memory` I think that's the easiest and just let kmemleak scan the mem_map explicitly, whether it's in the linear map or vmemmap. The way we ended up with marking 'nokleaktrace' blocks in the memblock API isn't great. This "flag" used to be called MEMBLOCK_ALLOC_KASAN and only used by KASAN (implying accessible). But it's not an actual flag, just some random value passed as the 'end' argument to memblock_alloc() and friends. Luckily memmap_alloc() only needs MEMBLOCK_ALLOC_ACCESSIBLE which is implied by MEMBLOCK_ALLOC_NOLEAKTRACE (though I can't find any documentation about this). Anyway, if you fix memmap_alloc(), please add a comment that kmemleak scans this explicitly. Also add a comment where we define MEMBLOCK_ALLOC_NOLEAKTRACE to state that it implies MEMBLOCK_ALLOC_ACCESSIBLE. Ideally we should have named this MEMBLOCK_ALLOC_ACCESSIBLE_NOLEAKTRACE but it's nearly half the recommended line length. Thanks. -- Catalin