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=1793279833; b=expX1xqVTKM66T0Fzy6ttJKv+lFn2CJSxn1lGNB8s1QJ1Si+WR/Vqh19giZ26Oo2lZOp 01t4pz9dLR3KKQngaI9i/3RfrFYBaTzbQKRmi12VpCogKfdFTSLMvB7UVwKd3js0i6PJZ rad8yrWaWJHj4vRF8ktEMCdGZdWd6uVxB6MnkaKjRRyFo8v3aBZ49AuCNAtg4GVJs+iFA 7OVXaDufI4YmyJsCYK7TA3/bfsqtBbcZzuxGh0bFzh8wXbVN5z8Wr1YKe8zKCA44G6XU3 qkESuOAP/5Jnjk8FGanZ/do8DhblVzueern3TEI4r+a9Fspq0O83M0o0MWGWl+8J2gA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793279833; 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=JRA+EBscIjB3Wf85Kdsp3ZllP4NjhEMks6pJspoVgFI=; b=RJx87mx+TbSaVoatdMOTSAjnLJd6S/WT8zk/+OVDQRZaAbkJtAyMoearycKQwf338TTJ InX7X95sGuMquuoN3ePuPMZbRw0Qj7ZxDwCdctc3xYbibcsPJmSUrV50qUiPGTMKwELSL esT7PV+naodId2O5jNZ+EjsOsCXRW9DULyBIzBm5+bE2+2nEJcpVw/SsyRAg+CpBRY1/X 9SGBwkSdeWQ2uFETeS4GVMmYPtD2YvT+OcTiLrmfMay0ZWuQssNM9B8qFFKlool9oe7F6 x86ThTNEWC/MuAyK6YTLvhVpYdyP28I2Wum1q+fft9IGPJ/ZO6xjYvJ/gUWmYacu3mg== 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=ExxhoTgL; 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)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 865B4606A31F for ; Thu, 29 Oct 2026 13:17:13 +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=ExxhoTgL Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B59C1F01825; Thu, 29 Oct 2026 13:17:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793279833; bh=JRA+EBscIjB3Wf85Kdsp3ZllP4NjhEMks6pJspoVgFI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ExxhoTgLpmardw03fYqQ5Z99pOOg/9EAf9OCNy5IikWuNrxOwziwwMHkyQVfLkB8e sMzz0mutTiCjvLQoDVRf098zOXBcYIFzKeEtegeOIRrRxv5orNNGPegzkhjdfoZJC1 /gAMFi2JSfCWG2LXfQ5EAHCGJY1yfFPmHsKvuHaE0Y/CUHe2z6j1Mz6L0cKItab5S7 ZwqCTD2Qy9UrXj7q1MjE9mdA8HFWbcFJZn9h3xdU8PHdI8qH/53okMpOnQuPVgNCu8 besGbjfbWqJvlZMND2HOyHx+USOJ/tUzdAyH4SLjOp9EN2Ydz3dU82NTDCzxsGS9ci hcfDaDdOB+LSw== Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfauth.ams.internal (Postfix) with ESMTP id 4A423198003A; Thu, 29 Oct 2026 09:17:09 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Thu, 29 Oct 2026 09:17:11 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTG2EVxsiXqZOd32Nkq2kAun5pY6dWfNhhCiR95p6LBReaqvq03sPl8TN9erfkk0z1 KTntpfrqVGeL9x1bmG/wkYLrULDdbe73UgZsxUYteqXu1qb0r7PB55VdGOox5cUZ8co7/u dZbZ+V6ErfeNzekxowVgsvUXTTLpyn1piwccOyRtMMzxlCZuo0WPOsQWlntSkDidJIMQOv M6pCN+bMHlsgaa39ZsrwapEieXGuHAHcOWGc5Xhy0nxxCCPOwgRQYpCME/wA2YaTZmhDqi 4EI4t32GKL0L2I+7TH+Z4hmIQymqAMCSwo/Eo6zjbX7Z0/2jj2hpmJ+TCsn8bdUzJkaNMO NCOMRe0lPsiH+E7VCC1pn/jknH5q21qyXXvkMF8BvXyNlwqi8BXYHqrbSYz/p+kTM8ppnc Glxuv07CuB9+LYt8gGuoZ8+RyNP+ugGlrw8bUKCJxfD1iA+n/nbk0fl84/DHo7JF7OJSL/ azpUfXoZIrzopbX6exR9zJfgSx/M+Pmb9BdzqThL04B/Me6eoaNpqmsqarnS1hSCcvP4Ko dWs8Swn0FcYhOmmn7GISdaF5jIHXSOukDmxJyK2yDIP4JnbymtkEZAMjs1EMZZIIFZieew GOaKtvWvMdRwmDdQ2BrXWWW3bcgwJxHRQ8J1XCaToGBh8UV/zjIuwFKJ6DrA X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Oct 2026 09:17:07 -0400 (EDT) Date: Thu, 29 Oct 2026 13:17:06 +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 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. 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. -- Kiryl Shutsemau / Kirill A. Shutemov