From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C747622D7B9 for ; Wed, 25 Mar 2026 15:28:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774452525; cv=none; b=C6Ql0yTi4VYF4T7b9beryVWoJbixwttu6DNnwV9fgUjLrqVDn90qYbqVWSjliKvQhlX5YgVYgLsqghkpjTt0Vw3wiiug0W8GMJuA1UpDpV81o2rEyF2qumsGi6lgo/9SCntjJzgsR7QVKvsVTyjRNda+wBIJQVtvufczIG175G8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774452525; c=relaxed/simple; bh=3mqgTH00b9m+SuJ9T0rVu6D+F6S6YGfYN+NbRnsXAbA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=M8u6CiAkBHdIZa3er1m+0ZEra3TY0h/Up8H2IkU7gDZE69C7gxPqbBwe2ti03SpBD/TOKMrzylwPo8j53DpFtNq83uef2952eQPBx+HtezbIrS7lg9QKGQBb9mlX3GNeSiIZ+10Hhk/89T/XHxycpZapiV9fjh+vtvk7mkeILHQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=g+6UZMLU; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="g+6UZMLU" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aAaE1cmct4Ax0hsF4P3343EFIFASkKmlY++QqxjAvYQ=; b=g+6UZMLU6OPQTahV7L1Or45Qhk teEyLF1KRx8BhTgUFvG1thOrA1Xv0GZL6YaRCjndq9v9zKSpSyX6ou8ICcdBGBBt2gBEEwAgRDjnk PtSWnYIjviyGCH3Txk7PIepvcN5vclndlCx73JxK1M6bA5HEkt0zlsMjK0GfI/mBQABLEohi6D9wN NaGwB67xEeqnq6I8KGxoIGBetL8nMHS2PwDgTU6Gv96qYVQLWqjs92rNs3+eVO7ctO1ac3C3ra9xP 5PTIiliCrujAHucK5CVuuROFTGwuQruIicSlp8xf9k+Mr2TWRXMZMFUh/3WNRQ+3GN5diElo3g0Xd CijWneog==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1w5Q9l-0000000G4b2-2rml; Wed, 25 Mar 2026 15:28:30 +0000 Date: Wed, 25 Mar 2026 15:28:29 +0000 From: Matthew Wilcox To: Zi Yan Cc: "David Hildenbrand (Arm)" , "Garg, Shivank" , Andrew Morton , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/migrate: rename PAGE_ migration flags to FOLIO_ Message-ID: References: <20260324114720.864478-2-shivankg@amd.com> <54398FC0-2F68-410C-B9C4-2802810C119B@nvidia.com> <41cd005e-3702-4c67-8d32-0c09274194e9@amd.com> <857B5E73-94AC-41B9-A3BE-953E59A5DB40@nvidia.com> <27b1b602-129f-4bc5-a553-386e8d1f5d90@kernel.org> <539EA481-9CA0-4B2A-B0B4-C254E34BA7EC@nvidia.com> <218144c5-6f51-44c9-bd70-e171005d3606@kernel.org> <925CC2D7-D525-4272-A01D-2A1E50127401@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <925CC2D7-D525-4272-A01D-2A1E50127401@nvidia.com> On Wed, Mar 25, 2026 at 11:05:44AM -0400, Zi Yan wrote: > On 25 Mar 2026, at 11:04, David Hildenbrand (Arm) wrote: > > > On 3/25/26 16:00, Zi Yan wrote: > >> On 25 Mar 2026, at 10:53, David Hildenbrand (Arm) wrote: > >> > >>> On 3/25/26 15:21, Zi Yan wrote: > >>>> > >>>> > >>>> Hi David, > >>> > >>> Hi, > >>> > >>>> > >>>> In terms of folio_change_private(), I did not think it is related to > >>>> folio_{attach,detach}_private(), since the latter change folio refcount during > >>>> the operation. If folio_change_private() is related to attach/detach, > >>>> I imagine it would check folio refcount before touches ->private. But > >>>> that is my interpretation. > >>> > >>> I mean, given that > >>> > >>> a) It's located in pagemap.h in between folio_attach_private() and > >>> folio_detach_private() > >>> > >>> b) It clearly states that "The page must previously have had data > >>> attached and the data must be detached before the folio will be freed." > >>> > >>> This is the wrong API to use? > >>> > >>> Sure, it sets folio->private but in different context. > >>> > >>> I can spot one user in mm/hugetlb.c, that likely also should not be > >>> using this API, because there likely was no previous attach/detach. > >>> > >>>> > >>>> BTW, do you know why we have set_page_private() but no folio_set_private()? > >>>> I would suggest folio_set_private() if it exists. > >>> > >>> folio_set_private() sets ... PG_private. :) > >>> > >>> folio_test_private() checks PG_private and folio_get_private() returns > >>> page->private. > >>> > >>> A cursed interface. > >> > >> Oh man. folio_get_private() should be renamed to folio_get_private_data(), > >> so that we can have folio_set_private_data(). > > > > Likely we should strive towards only using folio->private (and the API) > > really for fs-private data (i.e., the pagemap.h interface), and add > > proper custom members for all other use cases. > > > > For page->private it's a different discussion (requires more work I > > guess, because there are many more use cases. > > > Makes sense to me. The long term plan ... - Remove PG_private (we're pretty close actually). That kills off folio_set_private() / folio_clear_private() - Reimplement folio_test_private(). It just checks whether folio->private is NULL. - Remove folio_get_private(). It's actually longer than just using folio->private and offers no advantages.