From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from DM5PR21CU001.outbound.protection.outlook.com (mail-centralusazon11011053.outbound.protection.outlook.com [52.101.62.53]) (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 0A8663C584A; Wed, 15 Jul 2026 13:27:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.62.53 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784122073; cv=fail; b=TL5yZceKc63gES/SxQ3ZdkO7OhqwJffF1/R491XD/foi2HK3A9nunvzmpO2Bas/N7WixtFjs13S9onz6nbHXNa7jtX/BKLaRSqKsynrUwB5aAInvrs6qkjSrChAV+ptvVEFr9l53X4UdK8/sfmgGtpERVXz6YdqpLgigHIIUFEo= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784122073; c=relaxed/simple; bh=4W+i+btvE0pJfrN0juRbED3c5/FEGrIN4vpQG1JHM84=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=rwUsgiZQD3s/CTn8djGeV73cs2DfW4nH7hpJV3XMJDK8epLBgPat3uH8IyyCelIbKZUI3O4jhhmPHFQhTsiCiAuEvVp3meG+opbJt0/mv8g0s1Sl06EcaZp4TvobVYX5V6ImXe7vDyjpH6tNxvXpj2M74hwkYifLWRYtPx+KCD8= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com; spf=fail smtp.mailfrom=nvidia.com; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b=FGCemq4U; arc=fail smtp.client-ip=52.101.62.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=nvidia.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nvidia.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=Nvidia.com header.i=@Nvidia.com header.b="FGCemq4U" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mSa+NOF9F1qOpGFj1Os3XHWpta15YRj1lE8e3Ixafy9Tk7XG1ZRNyveUchUcfh75guGiihoa4LURwfu83iXCBNHt70dc78ukqVvEU3vkm8dZy/Z8tMfOyvGgRiYKUI0pZZPs4puZWWMVW/V9zbFo4eY9mL1bREEXMq28CU4shga1kp/JYfU59X+SXRNoawMb4OctqaRisgg9VX+dFspgI3PguVHfBWsPAVhXJSwjo6uTp90omxXK+BKxLdTq75xPEVbZYMqmIfrfKcmLHhnnE3Ytd7v35Y001hNU+89xOPSNKlENfUsb8R5EfJEHjBvsfVZkoy0CfBhld46KfkETGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jkiMUtKwFXGDNlptbmVnof3SSKptaokN1EHRkRnaDWE=; b=pGfLM1vMreBkIK+DxgizsxifhibD6Z4IHiNlz85TEeB718OjZO4QfxhD45xkwcHk7/qDIdrKyzfOMOctUNmjFoYlqx6pVbPjHjxCKxD4EAgkPuxA0RnZ23aOZ5p5NAjnMGoifOiIdbjHhb3JDRtVDcW8ztxRWbsnHvFxQ8AudVyjig5dU4HiPoanX08pf8J8S3Uo5/XdEWdQF8exO6lfOp3N2xBSJArHXE2OFTMrHIFaenoakLYg/7PFqnBszvO7hOJACtxYJZ0j46PmefnX8yWt3sWLvMujpbiBX2mA+BYR4wkf7jn/rj69xcoRrQ0rqOeGXJjVayw5phCHBubH5A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jkiMUtKwFXGDNlptbmVnof3SSKptaokN1EHRkRnaDWE=; b=FGCemq4UcieCCL4N2I9pKw+R3WINzXmGl/EU9VMSx5YF3oY0J6w0dV1sft8wlIu80LelkjIQLPji9i5QWTRiFc+1NBxuamAy78qe3yZJCW365Syst+zvU0CmwfjxrdLdGIjRoJPwK8OdNcOu+0h7NOwiUomi7wTqbJjoUaSGjDeDw3NqXVdZdC6kHKzwofJY1c7oq0TDFaUip5B6EeupOJFyeK1AruleHinaBH42zZp8z3iOK6IrGZcmI4uJabO58pIz9nJE1d1cUiBqFv5j3WpVqOCfphXyij5EgVJovJtaIp6OvR86F0UF2VaUi0dIWCpeDwFrxTRKIX84LGQ8PQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by DS0PR12MB8562.namprd12.prod.outlook.com (2603:10b6:8:164::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.223.10; Wed, 15 Jul 2026 13:27:32 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0223.008; Wed, 15 Jul 2026 13:27:32 +0000 From: Zi Yan To: Kiryl Shutsemau Cc: "David Hildenbrand (Arm)" , Andrew Morton , Lorenzo Stoakes , Miaohe Lin , Naoya Horiguchi , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Hao Zhang , Hao Zhang , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/5] mm/memory-failure: keep the folio, not the poisoned subpage, locked across split Date: Wed, 15 Jul 2026 09:27:29 -0400 X-Mailer: MailMate (3.0r7017) Message-ID: In-Reply-To: References: <20260714122344.351895-1-kirill@shutemov.name> <20260714122344.351895-2-kirill@shutemov.name> <18fe5529-2ad5-4330-a362-708a152bacee@kernel.org> <66A57599-EDA0-4E99-B073-F2AE0B2ED708@nvidia.com> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-MS-Reactions: disallow X-ClientProxiedBy: BN0PR08CA0024.namprd08.prod.outlook.com (2603:10b6:408:142::14) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|DS0PR12MB8562:EE_ X-MS-Office365-Filtering-Correlation-Id: 4dad1203-35f8-4ac4-ba56-08dee274d30e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|23010399003|376014|7416014|366016|22082099003|18002099003|11063799006|5023799004|4143699003|56012099006|10067099003; X-Microsoft-Antispam-Message-Info: fh+KNWIwZ2y9v379DYIW6rv90QTEZ9J/cMvtAY2YDTRJhX+SnJdDpGznXSmudacBhd6GfZXovvMd2rnS+PH5CuOasg9m8MkY7b9V4X0USHy6+78RqjcntzyZfsZ9+QyYE9qUfEWwsv8RVeeccB6XtEw1PeKz2xOPlLiM8xEw/PPNcECBlP89MyjKK7s2cKMQuDDtWI5D4LMcuuI7CRp59uHB+wHVV9PjSv1t1TEiD4Bbf15LlylhdTWK54uvbQ9ilw4a8R1aUMEyhEuOSGHsUbiyrOGG3CtlCohojpYmEEB5qEggiX32vrAj+3+4FRGgT5wDadAcED2MlpJyx+spjysr+jZ66vyL8glKz7UT4b7WdHbeAmM5HsnmkUu73iChgB0wWMzMCQDB9S91HoyC7I+Fma5FHluafCd/XpzopwhByPqYk+X9YLtFRhvlbu1mSNnlOjHUZAjscNbqn1+NNQl7Ebm7k+8CmMWVAVQRb+HzyWVwsZXBWU9ac1LzNQq7wOrf4iO8cSoc7UHi7Dy2aC3KlPIcXPUX9TvrkRLWnzXmM94wRk9/FE2K2gcFbHCDdkRM8chBiiNGdLkCcOsE4mwrW9dO+YzJf9hrifeR3KIZ831yTEqhRHzm9Gq5TLTpUkMHI/BwTR4fb2XEh2zHmRj61H7MXahhF15ZdHEOiFI= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(23010399003)(376014)(7416014)(366016)(22082099003)(18002099003)(11063799006)(5023799004)(4143699003)(56012099006)(10067099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?LVT8TS9rkPe/vgGf1Wc31flu6clhWUdz13yHRjeEDqiSUcL2c3BQV7+ggJaH?= =?us-ascii?Q?RhF/60J9xVS68SxpY8PsTBMyTZUcBymgJunEhLnTT/7Lb8Eb7njCycSh/mAa?= =?us-ascii?Q?liEC0B2ya9ckfKzVxIavfYAqXRLd/liUBJ6gAfua0YlOELlixCQc7+wse50N?= =?us-ascii?Q?sVtXgYJpqS2eZTuJE03jIZPFNTf733d4DFIXnZboMIfHmZRZqg4s/Rw0K6Ou?= =?us-ascii?Q?7/06mZEreKcP/Bqvo4fG7Q2IhgxTkDCdtaRNN7tUGc0/dO/QdhI90Pvagn/v?= =?us-ascii?Q?80ycEaNkhLd3X/+422vvwqX/MxaNUuypdZqzY461TEPEAMGb4Rm0HGRNePz4?= =?us-ascii?Q?sqYTLLxg/waURShMXLyjRyW66tPtOVyXbth6WelF524jn45+6Yya+fuL9Ch6?= =?us-ascii?Q?ouiPhk71JNQLYSZsrBveMzZOWR5soW+dOlDvKtqJj8Wmht2T7+M4FboC7i2e?= =?us-ascii?Q?nFbSdSq/26aXsYPI2dDdp4stVil22kjCaNGXDMYIr/SwBj3V8OEKv5ToPFs8?= =?us-ascii?Q?ItBv57XPqlIVWJOEZHd7rJjg868A5kTex1gADfp1skzsQuazdNIjevtb7VNZ?= =?us-ascii?Q?Ao8u8pZh+SSPAGxKjMBwLG27ztu3MRN1rSP6hgdFlJtNEDIQkgGR0J+0kpZo?= =?us-ascii?Q?reVvmrtKNRy1v5m3O0UIdYt4ig4AaMfyLVCCted1MOZdVtsr9Q434Y5/ubLw?= =?us-ascii?Q?w/o6oEm/ohk+y8hUbe02Q0ltTAr0MBw/Y6jxWHbAFUjK8xVTCE/5TNs8aQ/s?= =?us-ascii?Q?k7zpFgjxSfKv0BEtlN3AN193kdN78lnVHYy2wVgE3tSbHZWGedRuQ+Lgs+8j?= =?us-ascii?Q?QmG3vFcLKk2s0wDyHpmtfO6T7krVWjqswD00QqV9MSskXNDjM4IqmU/JlgGj?= =?us-ascii?Q?UfkLoYMrpmE5U+3O5XrTeiUmg6Z7QyGKNEa+N/n+LlJNWZDYd8N+IJy2v42a?= =?us-ascii?Q?bPU/tcMlNK8/mrk3mdY9ZaLqoPvZGOKu5JhL81iKoR0OlE/zpdoJkypnhWn6?= =?us-ascii?Q?EaPbu+vBe8aHK+FKxNaYqtorWWZaQAQQrR8sb8MMgyKz4xmtDGODVYU/GVga?= =?us-ascii?Q?CcATehcg9ZrOi38UWR1QznM1Wy29SUYpV+EGcV67pDiy5emRHRD6I/X0u15l?= =?us-ascii?Q?OJuPPlLHQgYxSIlTkR9hkgj2LyCuLRo5bHBdgkj0+W/J9m0FDZBrrXl5UGRe?= =?us-ascii?Q?NufAm6hmKbWLO33tMJeHC/C3GMfRa2qL3IZ7FsLfHQiN3CueKyvZYBlJEUse?= =?us-ascii?Q?mxAntJrBkT0XCJGuF9DtjNHmTiimFg08bMxYlxXMcq9XO6FXUYywSrTBR3+x?= =?us-ascii?Q?tbm4z2Can3EF27463iZ85I4ewTNEpLHnayFDP10rdGPpHr8Tu8gFQErNhvBJ?= =?us-ascii?Q?VY1ik1D7zR46dSy5bCrCNnm+kvLXMCd00hpPO9yRpbhEFY/H4rsUS5DGd6PQ?= =?us-ascii?Q?BpGm1aBygnTX3Ew6fZPHl4XR9xC5T/Yh0G9yuxI3mbHCCy/sg7yPT7Pp5+BS?= =?us-ascii?Q?yTQeUK5eJmdFhunnvAyr0XxZjw+GgqOFeEmkLoWcXKnJp8fGRsJ0P4ilap9H?= =?us-ascii?Q?9ySHGxbnh7KiY4FscopIFZ39Z3pdzkhpZAl5XCQuV1QDsnRm/LiftR732ffI?= =?us-ascii?Q?THoaaY7/cPpJWZLtcQTrmCCDHJAyvqLDIlaeoBS1U47GYxc+PFJszRLHJ8C0?= =?us-ascii?Q?DRi6Z3K2lX7xJa8gtf1/wHEctLgodpLoOIlrNiHXtX8LAEaM4BtNvn7PmFYI?= =?us-ascii?Q?MCdM5U9gRA=3D=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4dad1203-35f8-4ac4-ba56-08dee274d30e X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jul 2026 13:27:31.9564 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ZEou+Q0fjOqIf1mUKW1iswcpEZNQpahZhi7DwdssY/95jXZAl7NEGbGfGzziP7SU X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR12MB8562 On 15 Jul 2026, at 6:42, Kiryl Shutsemau wrote: > On Tue, Jul 14, 2026 at 01:31:54PM -0400, Zi Yan wrote: >> On Tue Jul 14, 2026 at 12:40 PM EDT, Kiryl Shutsemau wrote: >>> On Tue, Jul 14, 2026 at 11:44:39AM -0400, Zi Yan wrote: >>>> There is an alternative, only igrab() when @lock_at is at or beyond = the EOF, >>>> as I was bouncing ideas with Codex. >>> >>> I saw this option too, but I wound rather not go this path. >>> >>> iput() still can lead to inode eviction an bunch of random filesystem= >>> complexity under us. I don't think we want to think about other >>> fs-related locking issues in split context. >> >> Your reasoning makes sense to me. Let's ignore this option. >> >> For your patch 2, we might want something like below to avoid over >> rejecting splits. WDYT? >> >> offset =3D folio_page_idx(folio, lock_at); >> >> if (split_type =3D=3D SPLIT_TYPE_UNIFORM) >> lock_at_index =3D folio->index + round_down(offset, 1UL << new_order)= ; >> else >> /* @lock_at in non uniform split is always @folio */ >> lock_at_index =3D folio->index; >> >> if (lock_at_index >=3D end) { >> ret =3D -EBUSY; >> goto out_unlock; >> } >> > > Right. With the -EBUSY condition growing this hairy -- and having to st= ay > correct for non-uniform splits too -- just moving i_mmap_unlock_read() = out > of the window looks more attractive. > > This is really Hao's original patch with the reasoning corrected, so I = kept > him as author. v3 below. > > ---------------------------------------------------------------------- > > From: "Kiryl Shutsemau (Meta)" > Subject: [PATCH v3] mm/huge_memory: unlock i_mmap_rwsem before releasin= g > after-split folios > > __folio_split() keeps dereferencing the mapping after the split: > shmem_uncharge(mapping->host) and remap_page() while the folios are sti= ll > frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after t= he > after-split folios have been unlocked and freed. > > Nothing holds an inode reference across that. The split relies on @foli= o > -- which the beyond-EOF drop loop never removes, as it starts at > folio_next(folio) -- staying locked and in the page cache to hold off > eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read(= ) > runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure(= ) > passes when splitting a poisoned tail of a shmem THP that reaches past > i_size during truncation, it too is gone from the page cache; so once > @folio is unlocked no locked, in-cache folio pins the inode, and a > concurrent final iput() can evict and RCU-free it before > i_mmap_unlock_read() touches i_mmap_rwsem: > > BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 > i_mmap_unlock_read include/linux/fs.h:537 [inline] > __folio_split+0x732/0x1640 mm/huge_memory.c:4100 > try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 > memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 > > Freed by task 4601: > shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 > evict+0x57f/0xac0 fs/inode.c:870 > > Do every mapping dereference while @folio still pins the inode: drop > i_mmap_rwsem right after remap_page(), before the loop that unlocks and= > frees the after-split folios, and clear @mapping so the exit path does = not > unlock it again. shmem_uncharge() and remap_page() already run before t= hat > point, so after this nothing past the unlock loop touches the inode or = the > mapping. > > This is now a rule the split depends on, alongside keeping @folio froze= n > until the page cache is updated: no inode or mapping dereference once t= he > after-split folios start being unlocked. > > Reported-by: Hao Zhang > Closes: https://lore.kernel.org/linux-mm/20260710071344.GA106129@zh-pc > Fixes: baa355fd3314 ("thp: file pages support for split_huge_page()") > Cc: > Co-developed-by: Hao Zhang > Signed-off-by: Hao Zhang > Signed-off-by: Kiryl Shutsemau (Meta) > --- > mm/huge_memory.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 2bccb0a53a0a..abaea34ef558 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -4109,6 +4109,18 @@ static int __folio_split(struct folio *folio, un= signed int new_order, > > remap_page(folio, 1 << old_order, ttu_flags); > > + /* > + * Drop the mapping while the inode is still pinned. @folio stays > + * locked and present in the page cache until the loop below, so > + * eviction cannot free the inode yet; @lock_at is not enough, it may= > + * be a tail beyond EOF that the split already dropped from the page > + * cache. Nothing past this point may touch the inode or the mapping.= > + */ > + if (mapping) { > + i_mmap_unlock_read(mapping); > + mapping =3D NULL; > + } > + > /* > * Unlock all after-split folios except the one containing > * @lock_at page. If @folio is not split, it will be kept locked. > -- = > Kiryl Shutsemau / Kirill A. Shutemov LGTM. Thanks. Reviewed-by: Zi Yan Best Regards, Yan, Zi