From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793288349; b=CZIGA7oFXUcK18njLISS3A0byCwf4Cz7Q4xZdmgAW5aZmebI9FaMR7nwr8hn51sZvfj4 oQWi1feU/5WfJA9ssmajgvEKi5HichiBsQmc6Etc8JY/BYfDNHGsFKE1oZr4gwCVQ+ESE UQG7ZQJGrBpiV3jKL9iTHt+C/QihBib+FCJZt+uTyRnNGFl3Rw6Jv8wIJux6UCEo5Ivqr x3vO2Pxy1UsiwcZq8HidoDoJGIzoNYHWaPqRgiyGIO1ARH5sKRyOLWNvEAZQlxs8xdf4C 1T5YXqlLAHAcMHmGLSklyaT6zrYJMrYCqzOc+P0mVJeZZMQMjf/Gmm666+QTYqmIujg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793288349; h=Received:DKIM-Signature:Received:Received:X-ME-Sender:X-ME-Received: X-ME-Proxy-Cause:X-ME-Proxy:Feedback-ID:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=+0yjXwf7zZ1/G1ToyAZvwzcg/8Wure4Qebgzn6jDw2o=; b=pgEenM4uNaTwLi5TrjapnHw/g/1q8O15f8pDjjXxMOHh2QYwmzjg2nMLDteDZkvgwmxR +y+fBR8YN6AMbHhciHeJvrPHDO3FpYDjzfobt0QOUAcpcN0x+F57YMbm8j8G2lipSKZQP ++FYWyuTIoUMbFDmN55ZvX1+v9NQWKY4FKUa+gwZDnvA7TXeI5wcDsxofjEzAKd4Ud5U3 rQ9nsbQ1t4VzscrP19O7gosDYP+YGOmW8rX7psa9CExl4EGRQ7YXc1PGAXF7bzBkIDLO0 WYP1LQmKQI80e0CeQhgr2nXNTJ+UPrqg3qVC6eqUCERgdiTYdTuk0msjozE1ZBc8q6w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=NwSQYbTJ; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BB9D606A31C for ; Thu, 29 Oct 2026 15:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=NwSQYbTJ Received: by smtp.kernel.org (Postfix) with ESMTPSA id C56F31F01825; Thu, 29 Oct 2026 15:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793288349; bh=+0yjXwf7zZ1/G1ToyAZvwzcg/8Wure4Qebgzn6jDw2o=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=NwSQYbTJTrPL0oFAsVqlle+FzVCxZ375RdLcNaTi4yV10IG8cfrYS2ytUoKb9PvUi VOtijXUSUC3CqjpdvjICVQAICF8fqb+HshnaXNCZVYabsA9Gwvwwt4LaAw4f4SAFpw Hh0kWDvB6T2X8Rcn0y44xJXhLFFjQBWIkg01YfY/sbs931kU2/NMBe9Qh3wyaVu3wx Iv/p9ursRxWKJLMbOEOa79GW4ESh6S5tRAEi2aAvKsYGcjLxMaKAuXv4PA+OMDrSdH p8eOnGiiv9/Fw4qZ/5xiDJP/lwAc6hUNVtvNK6UCrg2spoE0UhQSTUp0vGpkoBC229 6gfSgwX8Fr9gw== Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfauth.ams.internal (Postfix) with ESMTP id 8558C198003A; Thu, 29 Oct 2026 11:39:05 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 29 Oct 2026 11:39:07 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTFNlLI1IxnysmwtxDbPBbt2dqnvQhYipohEcx8dPwIJIrBgAtFUMCeSCRLUn7u/FW UJHxDkt0ROnXfFadeQtiCMM/RXRAtrrQVUGl5N58b1fgZRYRaTyROC31lQTfeZ8KbXzn3o 1iblUPv5lQsPi35OYZrwn0KFWjWElIqjIL9Q3FpGeATyjJJCw3m52D4TW5EsY55qwO5bwQ L4tJ3d6vs/G6neLrJOfICTE6JsI3AzVh2GvhCHK2ltNKIxcjHCQEoOcYmbZqhhQ3GkH72f H2adk7ABosF30oW/TTEpL65vQG5ZxGrmyE0nmd55Y2l6qH+ynwtzmGxyCXtI0WrAcjz3an Q4xGGzYI/IoTBk/VX9AsQAiiMVBH0c+EfrLUzzx/Abe3/LQ4nGf0hfBf94strHo2SHnGDv AlOBnZXY5b2Qu2gRP73I3htQpOZ1IxTQ1ycrS11vSBwv5A782pALFSZYBhGeMc8g1ZjJYc 9Svn6Dgwjqs6YNAmffDusdRny6sr54vrgPHIWYQMEp8V8oHexi7SJCCaJTltC9F0v1LdLg EaTsM0e7JVAMdOyh+f+bkRx4yvtjD6InTFZvLkcgMVymvw6BwaPpheLKCEntVPvCbMop2J hPmtr+CHw4FXrXFxZrPj/8MyZLBO2+D9DxeCxvFuzbQQ9Zcsvl5khQqZbDLw X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Oct 2026 11:39:04 -0400 (EDT) Date: Thu, 29 Oct 2026 15:39:03 +0000 From: Kiryl Shutsemau To: Mike Rapoport Cc: Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Lorenzo Stoakes , Michal Hocko , Suren Baghdasaryan , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH 0/2] mm/cma: accept memory of CMA areas reserved with memblock_reserve() Message-ID: References: <20261029-cma-multi-v1-0-2cbced8b5cb7@kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Oct 29, 2026 at 05:03:33PM +0200, Mike Rapoport wrote: > On Thu, Oct 29, 2026 at 01:17:06PM +0000, Kiryl Shutsemau wrote: > > On Thu, Oct 29, 2026 at 02:40:21PM +0200, Mike Rapoport wrote: > > > On Thu, Oct 29, 2026 at 12:27:23PM +0000, Kiryl Shutsemau wrote: > > > > On Thu, Oct 29, 2026 at 12:18:36PM +0200, Mike Rapoport (Microsoft) wrote: > > > > > Pages of allocated CMA areas are released to the buddy allocator with > > > > > __free_pages(), which does not check for unaccepted memory. > > > > > > > > > > This usually works because memblock accepts the memory it allocates. > > > > > > > > > > However, multi-range CMA areas, used by hugetlb_cma, and fixed CMA areas > > > > > requested with cma=@ are reserved with memblock_reserve() and > > > > > their memory is never accepted. > > > > > > > > It feels like memblock_reserve() abuse, no? > > > > > > > > crashkernel=size@base already uses memblock_phys_alloc_range() for this. > > > > Should the fixed and multi-range CMA paths go through the allocation API > > > > as well. > > > > > > Fixed path already has the range, why would it use allocation APIs? > > > > Having the range doesn't make it a reservation. Both paths take free > > memory for the kernel's use, which is an allocation, and an allocation > > has to be accepted. memblock_reserve() is for memory that is already in > > use: kernel image, initrd, firmware tables. Using it for allocations > > leaves acceptance to every caller, and both CMA paths missed it. > > memblock_reserve() predates any allocation APIs and it is used to say "I > know this memory is free, I'm taking it". So memory acceptance should have > take it into account. > > > If memblock_phys_alloc_range() is the wrong tool, let's add a > > memblock_*alloc*() helper that takes the exact range and does the reserve > > plus memblock_prep_allocation(), the way memblock_alloc_hugetlb() finishes > > its own search. There is no search, so the multi-range path doesn't get > > slower, and accept_memory() stays inside memblock. > > A new helper that does reserve and accept makes sense, but let's do it on > top and also audit other callers of memblock_reserve(). Fair enough. Feel free to use for this patchset: Reviewed-by: Kiryl Shutsemau (Meta) -- Kiryl Shutsemau / Kirill A. Shutemov