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 7F05BC369C2 for ; Thu, 24 Apr 2025 03:20:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F195C6B0008; Wed, 23 Apr 2025 23:19:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA14E6B000A; Wed, 23 Apr 2025 23:19:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D41186B000C; Wed, 23 Apr 2025 23:19:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B22A86B0008 for ; Wed, 23 Apr 2025 23:19:59 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3C91F5F9FB for ; Thu, 24 Apr 2025 03:20:00 +0000 (UTC) X-FDA: 83367483360.30.CD6D48F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id D8E1740007 for ; Thu, 24 Apr 2025 03:19:57 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="jJpTxu8/"; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745464798; a=rsa-sha256; cv=none; b=lyUCipqmfKUAF2Ixf5rMJ2yq2hV335tEySzBd8uoZgwvBVjqMPDJokxOJWz2mAiVGsbzvo JDLc6B76oDy9Hk3cWshhcQ5p95lZfqpqQlUAlixaSx4CgfJxGnDRIF/ppwLth0Cz/DSZQJ Tn5+W79GTX+Q31L1QPKlqTmeZW8PyH4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="jJpTxu8/"; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745464798; 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=u690wCMwhfUO4csc3E0cwZEDChOGhKpWac0W2zW2q+c=; b=ryr9p0hbFTjAUUl+1qF/6BBhEMz8L/92TaGYQPqP/bdqVp4LBqFeq45mA3ZxwJq3FjqQS0 pgFG/A8hT4AzYw8YRJvoILD3kcegPvvJo1naf1evARxbEWUF6tpIFuo0LHn+wWZLP6PbgM JQnM7xE1Zih1zYbV1TotPoHPfFQuFno= 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=u690wCMwhfUO4csc3E0cwZEDChOGhKpWac0W2zW2q+c=; b=jJpTxu8/MrrakHRU+9VIbxsRg2 8z/BSiRxH0TeO9l5Woe+kfKWjPs7Cs+LARNdx/i9Fpu/ue21iKHbdRFV6Cu/oIeMwkkNHY6BOXRZS VUhZx+pLs4S6SZ+iqH8XXE/S7AKi5ITNUckiz+xtx7fJnnK+/x8NCxb0GP4dgWQvdJCOJB3SoQBBE drXXwsyqTjbs+dXGewgHt5enxhqIRvI5LCVRXfJRRLlGA9fMU55qcTiuZdxaEKKaub/XibRiUj2yB plCLdkIyKckDyMrObj3yfK4Wp+6x2CoL1kKUiPxMFqQAbTzKmyY3OfgkV5RCyxaKUUMCbqbOj77kQ YoFTYWPQ==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1u7n7k-0000000ApCi-1vFI; Thu, 24 Apr 2025 03:19:40 +0000 Date: Thu, 24 Apr 2025 04:19:40 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Andrew Morton , Shivank Garg , shaggy@kernel.org, wangkefeng.wang@huawei.com, jane.chu@oracle.com, ziy@nvidia.com, donettom@linux.ibm.com, apopple@nvidia.com, jfs-discussion@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzbot+8bb6fd945af4e0ad9299@syzkaller.appspotmail.com Subject: Re: [PATCH V4 1/2] mm: add folio_migration_expected_refs() as inline function Message-ID: References: <20250422114000.15003-1-shivankg@amd.com> <20250422114000.15003-2-shivankg@amd.com> <20250422164111.f5d3f0756ad94d012180ece5@linux-foundation.org> <8f24de4d-5088-498a-968d-9e8bb85201ac@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f24de4d-5088-498a-968d-9e8bb85201ac@redhat.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: D8E1740007 X-Stat-Signature: xain5x6td1r4e3gdwbm5a1r936awi3jt X-Rspam-User: X-HE-Tag: 1745464797-743293 X-HE-Meta: U2FsdGVkX1+jhG67/dGJULMX6JmAldmy3JDGpFqKwG+9szszZjZ2g0S0FgnXbgGqsAKqOXqtatijeyXPjFt9QbD2bsPG1rJynm44KFR1yBUn8VG5wLq4nC3tXPC17Cyxx02kXLfViMQtCi+KC5pPqjRObQpSOrGkzYGK9ITt4ORdJm6sBF94IXz4gSdqnPCuQlI2QKsnHGvT+ALPkt9WS6pvnvZzX92vfhS7wlr3XGOutVM+x1yFBAOeKuemqGRuxA5qWAuAxdoYEkqMH+awg4AbiiMqFoa77R9VeUzAgXJ4xfHXOqwj4yy3jzuv4LKgTPpDo8e6rdGyJ+9Ybb7Iwd7cXjjeGZLyoDXBn93TE8mhBkc9GJkYgT51WN5jCDtspmP6+RHqvp85o+9vYNYM8GtG1eFJMjO76IBqSbHhaptaKPPnlzYLPiZWUeYh9cAIic6g/lvpjHSMCJiCRlOozSatCNmXOrGa7pcoM7eeeCTyb6ya6XOJkT6m+ELZtx0nLsU9zF94JJkOPkn+ysIrKfsL67QGpa47VPzFAEHwvKB8ob7JVmmM4ievAd+x4qzQJwEFKmfQno5q2ua9eqYlWODlxYiZ7TevrlIbo1UMNr8lcRgBJRuram0uJMfG2DofI36Sd/r0g3dIbOj6ZDXyph0UnU7GZb/n4Qyjx1Y1HiPTNxzoXWIT7wTdOIHL0MeFCFvPb3fdnkaZyD1DqLY3CkyQIJvdgYoooSLVVH4BOyrnhz6+uIzvOKtFaUcNc9r1Q7XJ39HX5Vy2BiJiaDY+9Fi4DUVYZJ14sz3M0P02zivZ8yYGcox4cpof++u8WcqRFjNhrxw2wbl7vnaiBefY8kUmcVLKgRLfNnoecqu9BwvYBiVtkIUTxIv83nCADMQQ1f1GoJCJIZXCiRS5zxeBF4fJATjwXqG/Qyf3cHzHTDVGzYshtv1TDAhBhpuesGjIS+lgrdFy2n9B/wHWJM0 Lo+sr8q2 UlYrPRiEJA//VMANMSj/q7Og2BOQOIADK9yYapYARNHyY0lusT6N8Clw7unSh4Qixo9yO/MslTqpAgS2PJYL/3/CCin8WUElLFc3+uoffQXl94lW9GAnqT9zrn8OucVXyofhiiQuNIcx3LNLscNBv43NgaQYcHB3tpuTk5RCzZLfoGtqtKjG63RBTKwCon6CPB8CIHpc+c6c55+82DisVRLvi/mmsq9yEzMyYNkvb8dWAoDE2c/BGeNYQGf1YhaX22a9auCXXtz7g/juSFuFhoc3FvkenTPhyMRXQ5Rx7O93M9oc3sih0XnAUYX/IuMqeVDfnYnDY3weL/BYGmsCPpE4fWGiuwcdvcQHso6CI+Iu5k67Umgx2Jg1jxg== 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 Wed, Apr 23, 2025 at 09:25:05AM +0200, David Hildenbrand wrote: > On 23.04.25 09:22, David Hildenbrand wrote: > > On 23.04.25 02:36, Matthew Wilcox wrote: > > > On Tue, Apr 22, 2025 at 04:41:11PM -0700, Andrew Morton wrote: > > > > > +/** > > > > > + * folio_migrate_expected_refs - Count expected references for an unmapped folio. > > > > > > > > "folio_migration_expected_refs" > > > > > > What I do wonder is whether we want to have such a specialised > > > function existing. We have can_split_folio() in huge_memory.c > > > which is somewhat more comprehensive and doesn't require the folio to be > > > unmapped first. > > > > I was debating with myself whether we should do the usual "refs from > > ->private, refs from page table mappings" .. dance, and look up the > > mapping from the folio instead of passing it in. > > > > I concluded that for this (migration) purpose the function is good > > enough as it is: if abused in wrong context (e.g., still ->private, > > still page table mappings), it would not fake that there are no > > unexpected references. > > Sorry, I forgot that we still care about the reference from ->private here. > We expect the folio to be unmapped. Right, so just adding in folio_mapcount() will be a no-op for migration, but enable its reuse by can_split_folio(). Maybe. Anyway, the way I explain page refocunts to people (and I need to put this in a document somewhere): There are three types of contribution to the refcount: - Expected. These are deducible from the folio itself, and they're all findable. You need to figure out what the expected number of references are to a folio if you're going to try to freeze it. These can be references from the mapcount, the page cache, the swap cache, the private data, your call chain. - Temporary. Someone else has found the folio somehow; perhaps through the page cache, or by calling GUP or something. They mean you can't freeze the folio because you don't know who has the reference or how long they might hold it for. - Spurious. This is like a temporary reference, but worse because if you read the code, there should be no way for there to be any temporary references to the folio. Someone's found a stale pointer to this folio and has bumped the reference count while they check that the folio they have is the one they expected to find. They're going to find out that the pointer they followed is stale and put their refcount soon, but in the meantime you still can't freeze the folio. So I don't love the idea of having a function with the word "expected" in the name that returns a value which doesn't take into account all the potential contributors to the expected value. And sure we can keep adding qualifiers to the function name to indicate how it is to be used, but at some point I think we should say "It's OK for this to be a little less efficient so we can understand what it means".