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 D69F1C5AD49 for ; Thu, 29 May 2025 15:46:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 479F16B007B; Thu, 29 May 2025 11:46:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 42AB56B0083; Thu, 29 May 2025 11:46:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 367BE6B0085; Thu, 29 May 2025 11:46:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 141CF6B007B for ; Thu, 29 May 2025 11:46:49 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AE2E65C490 for ; Thu, 29 May 2025 15:46:48 +0000 (UTC) X-FDA: 83496373296.18.4E57478 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) by imf26.hostedemail.com (Postfix) with ESMTP id A6A88140014 for ; Thu, 29 May 2025 15:46:46 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=mEbWOO4g; spf=pass (imf26.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748533607; 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:dkim-signature; bh=eFCrQ4MA3Ql2DJrcPlXg6MIgdM2XiPph+P34wKI3KVc=; b=KY8leof4ibk3CunfnIu2pJeOMMdfcCjV7Wm0SBUtAkZQaIvShD+Z21TaWYbB8lRn8K1i4o IROzUt+efBoJCNiAxcmUp1ztCNt5zaLejRu5xlBlKrHVFedJ+FfIJM16W/zEgfTObM45gd gXL7JZLojx8vimD/fxPx+r8jordv7kI= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=mEbWOO4g; spf=pass (imf26.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748533607; a=rsa-sha256; cv=none; b=JmOcaHH/DEDw6CQNVZbSanXfokekqorgpvJRHSyt43lL2+mQcu6zahREZdi4RxEb0bruNY Vmp8fqiWSTIqPuNP6ABSmeC1HY9qO6YENpWiUSzmTbdPVUGJ6io/ntuFWxF53FxeoCSRk5 5U8DhtNC2S3mERvBTeoUGi/qf1xWv8Q= Date: Thu, 29 May 2025 15:46:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1748533604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eFCrQ4MA3Ql2DJrcPlXg6MIgdM2XiPph+P34wKI3KVc=; b=mEbWOO4gf7LLl4/uum/hHOTTfbaBYHsD4NbdD5Ws6eW/wEG7DPeYeI1BccoG7UVfvc899S 4fVN0JSHzdblnaurxY/oF5tVuCTOVmIg1gyF3FrhsB+LBbaftQk+2AyLR3BmIxgU09W2dN oO64eGezp84UJJBC0eOpFNsOWc+T8Dg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Vlastimil Babka Cc: Christoph Lameter , David Rientjes , Andrew Morton , Harry Yoo , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm, slab: use frozen pages for large kmalloc Message-ID: References: <20250529-frozen-pages-for-large-kmalloc-v1-0-b3aa52a8fa17@suse.cz> <20250529-frozen-pages-for-large-kmalloc-v1-1-b3aa52a8fa17@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250529-frozen-pages-for-large-kmalloc-v1-1-b3aa52a8fa17@suse.cz> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: A6A88140014 X-Rspamd-Server: rspam09 X-Stat-Signature: b8zdqpi16kaumme8chrdq4iq9fcxpkex X-HE-Tag: 1748533606-346122 X-HE-Meta: U2FsdGVkX193mJ1frqja7mrPsl+F6oR6faAbN2+G0din7YMNG/xiSgKlDHI7uPjzil59xiuy7rU08FMAIkvIrJ4LoDNnN/+4X4Tew+hnBmfa8Wt0YG52iZHwywxbrYWR0mvinK3dxEjllsRcfjDYXY89jtbiyClzRkhnQ3s2MC8qYuNZA5xOGGx+UMAtwoCjla5wYi4DY8wES/rN6/+URpbR5gUlYoo30+HOfJ5PMA2AqaE9ZJHOO8wE3GLZg2tNIW+MB8ND74RKrB1+RyCW1h/MEEOeHJgDG+4OJabHWzD1bvUR5Vjie2y4LfJo6Cc2TtZGYRAI1X0jh/F8qdh7z2R9Bae3wYBTgPAr8Emaz299FIAM6nSSFe3GSBjpms7Zdn9iDXosoIwdOr2eUPicwFn9S0cVAuN2wpH340PW4HAY9SxkGIqpyry88+UcVIOluzgqZHmQIliq/SZLQIWob3UJy2veoU75GDnZKRyfAyMHyz2H9d+2JAY2vobH+jikBM45SzSMx059zC2qvfPUBBxTm6x/Hx+k1yPI+zl1Qk3hM6541uhNKWRehJEE9iKjn3QNk+7iwLTPkE66vy1ZI3Xv9bBTxgokfFVMru348C8YAd5B76CJ3J8e8oVx8AIZIGjCvrZtWgKSbycBc9kM0jEDMJ7aTawyYAdShzZ6H+a1QONPkRCKN+ybmq4+WK2mJPhSrXevBWFHioETHqGeY9Pz/5bS7JGmLBpqxdcpBbKhDJLfb2djt+DHgtUv7IuOv0+GRmgs5tlklPt046E83wzUmnOxgB60E7hYX25GCSr7E0oKUQdsnQw9CmXJIGmHbmQ1Ieewh5W2a+2faIhoDdoLqcFbjVlh4e3Cn8JNCx9ztnF56HViTqS8frbg1NSDyP+iVDswMzKOeWCLWbatXMYXt0nc4m5YJt6ck7FyIin+yE7y1Ajn6HPK4FMzoiiMfIph1iCN7msSSQrk7ss IwiNhdzu FIup3J2cUVbyFHlgvQEmnV3mAzFzq7uTwPyIw1dnPaT8kgEgCxE1sFpK2DDGGA/gYI2dyrYUy3qGZ0XCAGiSDbSTTHbmzNgL8pJNbAGG5IPh0JutSg+NNganKq/oWh9BNzJOMxErZtgm81NT1+uKwjS0ivxPofsg2WBEl+SRN4sVzD/m46y/wN4KRDzUp6li5rKKzx2wWZ4zj9MHfbjGzOs8Z2By+gTJys19HHitsN//SBr8/eBVvdFoHrA== 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: On Thu, May 29, 2025 at 10:56:26AM +0200, Vlastimil Babka wrote: > Since slab pages are now frozen, it makes sense to have large kmalloc() > objects behave same as small kmalloc(), as the choice between the two is > an implementation detail depending on allocation size. > > Notably, increasing refcount on a slab page containing kmalloc() object > is not possible anymore, so it should be consistent for large kmalloc > pages. > > Therefore, change large kmalloc to use the frozen pages API. > > Because of some unexpected fallout in the slab pages case (see commit > b9c0e49abfca ("mm: decline to manipulate the refcount on a slab page"), > implement the same kind of checks and warnings as part of this change. > > Notably, networking code using sendpage_ok() to determine whether the > page refcount can be manipulated in the network stack should continue > behaving correctly. Before this change, the function returns true for > large kmalloc pages and page refcount can be manipulated. After this > change, the function will return false. > > Signed-off-by: Vlastimil Babka Acked-by: Roman Gushchin > diff --git a/include/linux/mm.h b/include/linux/mm.h > index bf55206935c467f7508e863332063bb15f904a24..d3eb6adf9fa949fbd611470182a03c743b16aac7 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1549,6 +1549,8 @@ static inline void get_page(struct page *page) > struct folio *folio = page_folio(page); > if (WARN_ON_ONCE(folio_test_slab(folio))) > return; > + if (WARN_ON_ONCE(folio_test_large_kmalloc(folio))) > + return; > folio_get(folio); I guess eventually we can convert them to VM_WARN_ON_ONCE()?