From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from PH0PR06CU001.outbound.protection.outlook.com (mail-westus3azon11011026.outbound.protection.outlook.com [40.107.208.26]) (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 06B5E3FA5F2 for ; Mon, 15 Jun 2026 16:00:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.208.26 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781539255; cv=fail; b=YLUug/kx+GaKI7uKwPZD2acy6gNQRefDTYZiSArumuhehxkI9oWqDfBpOv8QAl9h1q3rsMuyiL/Vdk/+ftMhXAUCQUjq8dj9IBcVuNpMeEZddLGMk3cj08fcD3L/O0nIMlZym0TyFNdYmpJsOLPmvVXnOlrD9+kwT6TSt4K1J5I= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781539255; c=relaxed/simple; bh=4Zy0gRJLI/xfHD365E08a6r9OYHJ20zvZiZ7yX7+Gns=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=ZCmLXJbaPFKHaVUSMB6SfO1o0Qwr0mUsOXh1RAHPBZ8al5YlxSOfMb1X8S6ydaZrBhfioNKY1qItnuK7g3+a4skzr3V2cb4MlDOilRv0J65l70Dy1ZTxMzcsSyePLg/dsA2VLIx8zI3btNN9LtJJh95tvnvSV64WMQNmuwXStno= 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=uBLeeQa4; arc=fail smtp.client-ip=40.107.208.26 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="uBLeeQa4" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=PJsKh9nlFN4oV7D2n9ZfsfjnqQ5k95Cb3tRMU1PsDIXhiuMCFKuzHJwde9VgUnIyP7hRtSW9Za4aLGWR3WmjYm/Z5MC+agG5+kvNoOlg4GenifRPaDK06CECmyfK24tKZL8q3u4lzn3mlgHzHVZuabxrcEQi2VXAWF754X3WgRTmtbNvaRf8aFkHq5pNhfZSn0SSW+d+UXvs9wMRmk2HGwMZJTpEFqIUWnmHRwIldVPUBGoCX/X+qFIMGmEhtHKeOLCP5h2uQu3g2ZLfOxOUrNg6nWzdlim0EX944mgNWkVDYzlPc6kNrTRKf3h7frlAY+cndC2RqMR3I92dAGjFfA== 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=EkOGiaq9bP7f5pdFW9tJamLzUlD2Da4VFRThuItBDHg=; b=JsTi+RM9KIPZlLFQdZUdgzBz5XkIELW7M8ZuY9yjVB6Euf2TRK+fpcY4iNjBZh/emE/eQab4fdCWACYygJeJWwa8nIoaBg/AN4u6zMDkdXBgpj2TgPwK8j0AqUa2bjd2xDwx4YdFJgnhJxPTI1TAj3jGPT9vDU+fCewF+6Vw2JbFxft965tNi4kGMBcgANEmyRjDeC2htCyFtJnQFvOgp+UZiCReA8ZHrDEdZPKe4AmiE6e5sdJA4FFAMPULaowa7iPhEgMXZuQMXybB7ziPV6FfpSI5aKkoiRJIA7/SdCB5hEeE2NjbY5wC7yQVkYz5VtfGJ7NSLzfuL+WqvWYLPg== 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=EkOGiaq9bP7f5pdFW9tJamLzUlD2Da4VFRThuItBDHg=; b=uBLeeQa4XU7khd2dYu+LqRTQoJ/l1w6VQeUJpHX0AZ8pmKSKJwYt0dfxnHw9J1EDf+5+K6YyJC62w6xDVU5+cjeKCXT/8HqDizIC6kuZmeJRj2oIz+3Za8A2hXm1PXm8DOgzlTSyghsuw/oTBBHlDz1Tcq8Avqpu+sWlgvT/EeTDJkqltlDKrTNOH9+E9zZDWmuuGyVfDQRbYG5CC5xGnLDJwdlD7pU1A3OCzBoAfWLsVCgkjzXzR92+KNM9vh/od9qnA8gHVqodSyx7NgvhJ7Npzaw8qXqx7ZQwNDABTtriqaPFUCPUBB+6m1bvAEs/CddSaJ12lR8IJLs583VZaA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; Received: from DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) by MN0PR12MB6269.namprd12.prod.outlook.com (2603:10b6:208:3c3::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.113.18; Mon, 15 Jun 2026 16:00:46 +0000 Received: from DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::f01d:73d2:2dda:c7b2]) by DS7PR12MB9473.namprd12.prod.outlook.com ([fe80::f01d:73d2:2dda:c7b2%5]) with mapi id 15.21.0113.015; Mon, 15 Jun 2026 16:00:46 +0000 From: Zi Yan To: Zhaoyang Huang Cc: "zhaoyang.huang" , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Barry Song , Baolin Wang , Lance Yang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Jaegeuk Kim , Chao Yu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, steve.kang@unisoc.com, xiuhong.wang@unisoc.com Subject: Re: [PATCHv2] mm/huge_memory: do not add dropped split tail folios to LRU Date: Mon, 15 Jun 2026 12:00:43 -0400 X-Mailer: MailMate (2.0r6290) Message-ID: In-Reply-To: References: <20260612023456.2424044-1-zhaoyang.huang@unisoc.com> <5718685A-8469-48F2-8FFC-10C4BE054F10@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: BLAPR05CA0041.namprd05.prod.outlook.com (2603:10b6:208:335::24) To DS7PR12MB9473.namprd12.prod.outlook.com (2603:10b6:8:252::5) 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: DS7PR12MB9473:EE_|MN0PR12MB6269:EE_ X-MS-Office365-Filtering-Correlation-Id: c74ab744-ab58-4960-93de-08decaf742e6 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|376014|7416014|1800799024|56012099006|11063799006|4143699003|5023799004|6133799003|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: qy52ACddHalnZ6kL7oUQ/1BFL8cQTr2PAZYys+x9s0rPPxISAemLshpCEfaxTpB2if4NVxOWzLKUkG4nyxkkebO8ohlwClnUCkAil22ub9G0k8wFNQyXPv2pIVUCcHA6GOockH6G68A2gc+CVdASbkQxH3XpsflGMknGG4SBj+EpgHMiVWRwAAK6FYdkRrGfXVaL0CZSUwOGNl+QTtQFWIA4R5oNeh51uSEiWT8bwKGS3HwdxmozteQ7OtP2mMGQ8ZMG6Khq6QVTCWGsvYiaBkknWMGabQyr77uRSvebrVpLH+EkncLfon9zoAYHkRpInoshiFZW45St2QP+tWYspPMpIkAG5uXOQq9WdrbV0vGqlr6oOMKP4w7Mj2mecMHGAZYHvlsX+Si5mLMWqw8q+EbXszbfXHCjkNddm+ty7KxX0PH4NxGrospO+3HDGIhKSS9h6opa5ea65GIAvqtgc8yZnT6qyWI7kcNIlid5APpCwKmfajRv0GAMuIqxUbMLS/TbMOQ9B4ayubK73GCO1a+noQhdZ7XL1gAbnEbFIaS0hu/6Lo+V9nNSU5SIFOWRknJuEgpX81I3qlMeYqsipj6Pk3h2YxkDFGUF1thHVsnzyqcqcGkE+t9ae+ODxV0oQGv8vQSBQAa+Sa5BE/J8ov82zqbaLqRYrUToTz5MNl3G4MpTsaokvFE/KqJ1BQ6fmtJafn6K+5RH/uO9IeAfDQ== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS7PR12MB9473.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(23010399003)(366016)(376014)(7416014)(1800799024)(56012099006)(11063799006)(4143699003)(5023799004)(6133799003)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZHlGbFJweUJGVUpIdEFQcU9qcjRoSEkzMHhXV09TeHdwTHVKd0ZwWEFXK2xK?= =?utf-8?B?Qlh2a0lYbkcxY3F3eUJBTXRaQlloZG5CbERzbFBJR0xwMnV2SVFBSWxENWhC?= =?utf-8?B?VFVFZGxyN1NOaWNOYU5zcWV4c00rMDZBSjE5WlExeTNQa1JoOGRjTHBwU2c0?= =?utf-8?B?SFcxa3JDMkpRWjR3cEwxY0I1OVBKcmtwajdVUWpaZ2F2MjMvVzdEZzBDRk85?= =?utf-8?B?VVc3WFRYR2hORzVKM2w3RVoxR1BEN2NNNENYWmRlNFU3L05VTjBFc3ZTVG5C?= =?utf-8?B?YzVLdmg2aFh0NHI1NlhjYWZHdGVXb25DZk9oWDZNelZQcm5kSW9PQk02YUV2?= =?utf-8?B?Q2xVRUt2aGNEanZmWFphZXJGeFVyOFZ1SUs0eXdPWWQvNC84bld1NzFqVTF5?= =?utf-8?B?Nm5EN3h6eDFVRGpqcVdTS3VzRzJLMjJtWnJmR3hQQStVK0FFVy9PczNNbkRY?= =?utf-8?B?dnFDbkFCSjZZNXhKY25FTVA5bWd2Vy9XbkxBK1I2bU5OQUtvdk9hbjB3cVcr?= =?utf-8?B?Ry9HUW11UFpicVMxQ1BKVGF5SGIrOENKV3ZyMityNGM0ZEtGcllhM1dPcmhL?= =?utf-8?B?UXB0VVBZaVRMQ1NlN1pxSHNJY1M1ckRBVFFnSW5tQ2FaTmpBVm9qa1diTTR2?= =?utf-8?B?THlva3E5RGJpRlIweXF3SmhmQ1BLOThsV2JtVGo2RFJScnBSSW1XNzRVLzFH?= =?utf-8?B?Tzh1SUtmdVhKdFNWV0VzZTZHNHlIb2R3RXdBaFdpcko5TzBFQTNrNkpwTHYy?= =?utf-8?B?UWRlelUzTFdFcTZJSGcxQUcwbnppaC9CZHE1WU0xZ2RTMnE0RFk3bDVJNm5i?= =?utf-8?B?VXVQWnA2OXQzelJ1TDFqWHdxajBpaHc1bzlBTURETURjNkRrakxlQjd2OFlt?= =?utf-8?B?Z2crb2tRaUpzQURkWFpIVURONWVodmU4bWJKQzAwcm1oanY3TTViMUY5aHhk?= =?utf-8?B?bjJJaWZpZHB6TGc2QzNpK2d3dTNHU0ZwcTZrdG0rS1VwVVdUWEVTeU13dlpN?= =?utf-8?B?NGE5TTVqZ3kxVldJcklLWXpFaDJHL2NJTWpnT3R6ZzdDUE03SjlYTEY4M2hv?= =?utf-8?B?K1VDOEdlVDhzTUNhd1lvRjBIR2p4YkI0UzhWSU1jbXZxWm5IZmFzS3V0Z0h3?= =?utf-8?B?SjFaTS9lRzRsdkdTYUg0V3JlSmxsK0tpT3IxNkwxMWM2VTZpSjRXQUJFTmwr?= =?utf-8?B?NDFkWUNQUWtrWFJsb1NtZ1d1WFBVU3M5VlRHVkxyN25YZXB2aDZFVm15akY1?= =?utf-8?B?NGxBdVFHQThIbklTSWVhRTIzbUFieFRVUnFqU2dlWWpmZmI4U2dEY2w5Qk5E?= =?utf-8?B?aStmYmd1U1phZzFkZEhlZ1Q1YnBnQzVaYXN5NlBNVnkwd2h6RXJxamoyZExj?= =?utf-8?B?allkN3UwbHpzM0s5eCtkcnFwK2MzZndOR1RQaUVYbEIwT3dWR1pSMzdSSTBN?= =?utf-8?B?bk94b3VJcXh3WHVIK1lXSTd0N08vTVNWZWVQZTNqRW5QQ25YMHVkbmVoUkJO?= =?utf-8?B?Rm1QZ2k2UzljSVVITHZhZU43SEFxcGg2M09ueGF5TVI5YmNMS2J0cFdIOHFE?= =?utf-8?B?QjJSVVVqbStjLzBvNWgyeUdPbU8ra3ljY3ZvR2N0UlorU2VoZzZtYkhkYWNy?= =?utf-8?B?L0RpVU0zWnlqSW1HRFRjU2llcm1ZTEE0UW9GNThSaTFqSXVtd3VDN21XZXVD?= =?utf-8?B?cW1GRmlBTllvM0VmT0o2a3pjUkxPSzVXSUlwaXRGK1BOSlNaVENEU2JUSzlz?= =?utf-8?B?VmQvWHNZa2NlVW1zWERMQ3UwaFFWVC9rMXkxQU44VjlpNlFSRlJmdTVnT1F6?= =?utf-8?B?V3N5NE52OWl2ZVEzNG95NzBvOEoxMWg2Wkh0cGZGRjFQbU5SL096TkFNckN5?= =?utf-8?B?SDUvYzMyeFEzWUo1eGZZUjBMQ2hLeDcxMlJRS0VEeWhNM0dRTURlMkRBQ2tx?= =?utf-8?B?RlhjWnRDeUpld29saUZkUmVQbGRIR0pER1NDRTJvTDFlRDYwVFAwdEZ3NFBj?= =?utf-8?B?emE1L1hBajBTSTRjalYvTVUvOEtmSy8vcEpFRGE4QWNDWU5PZUVSZFpvd0RH?= =?utf-8?B?MWFjQkVKOU41Ynl0WEtWcHlXS0x3ZWFkZ2Y2VzNsbFZvWkxtTEJQdWdJQ1px?= =?utf-8?B?TlpXTGtJWENZaFpnajZ2NkNjTWdWblp4Q3hZaHYyRXU2Sm1oMDJXOG9tMlpk?= =?utf-8?B?WnZBQkRlb0xBSktwcUVzaklWWWkwWXFVNjNJaVJEMFd5d0w3OHFDUndrVUJX?= =?utf-8?B?VlVGeG5ydE9kKzNKcFVGNktpUXQ1UFdVZ2praWNiajIvYTl0d1B6aUFMWVNt?= =?utf-8?Q?zbAxE0E5PacNFxyWZ8?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c74ab744-ab58-4960-93de-08decaf742e6 X-MS-Exchange-CrossTenant-AuthSource: DS7PR12MB9473.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jun 2026 16:00:46.3260 (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: TH6L9XqqDMRR5DowDtu1861xvv3N36D5mpnGyDTKIo2yuXIk5vmBmO0VlAuC/mH1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR12MB6269 On 12 Jun 2026, at 19:55, Zhaoyang Huang wrote: > On Sat, Jun 13, 2026 at 7:46=E2=80=AFAM Zi Yan wrote: >> >> On 12 Jun 2026, at 19:38, Zhaoyang Huang wrote: >> >>> On Fri, Jun 12, 2026 at 10:12=E2=80=AFPM Zi Yan wrote: >>>> >>>> On 11 Jun 2026, at 22:34, zhaoyang.huang wrote: >>>> >>>>> From: Zhaoyang Huang >>>>> >>>>> The kernel panics are keeping to be reported especially when the f2fs >>>>> partition get almost full. By investigation, we find that the reason = is >>>>> one f2fs page got freed to buddy without being deleted from LRU and t= he >>>>> root cause is the race happened in [2] which is enrolled by this comm= it. >>>>> We solve this issue by reverting a f2fs commit 9609dd704725 ("f2fs: r= emove >>>>> non-uptodate folio from the page cache in move_data_block"). >>>>> >>>>> There are 3 race processes in this scenario, please find below for th= eir >>>>> main activities. However, by further investigation over the code, I >>>>> think there is a common race window for the truncated folios between >>>>> split_folio_to_order and folio_isolate_lru, where the folios lost the >>>>> refcount on page cache and remains the transient one of the split >>>>> caller, under which the folio could enter free path and compete with = the >>>>> isolation process. This commit would like to suggest to have the foli= os >>>>> beyond EOF stay out of LRU. >>>>> >>>>> Split: >>>>> split_folio_to_order() can split the big folio into individual pages = and >>>>> put the resulting subpages back on the LRU. For tail pages beyond EO= F, >>>>> split removes them from the page cache and drops their page-cache >>>>> references. A tail page can then remain on the LRU with PG_lru set w= hile >>>>> holding only the split caller's temporary reference. When >>>>> free_folio_and_swap_cache() drops that final reference, the page ente= rs >>>>> the final folio_put() release path. >>>>> >>>>> Truncate: >>>>> The changed code in move_data_block() lets the GC path evict the tail= -end >>>>> folio from the page cache through folio_end_dropbehind(). Once >>>>> folio_unmap_invalidate() removes the folio from mapping->i_pages, the >>>>> page-cache references for all pages in the folio are dropped. The fo= lio >>>>> is then kept alive only by temporary external references, which allow= s a >>>>> later split to operate on a folio whose subpages are no longer protec= ted >>>>> by page-cache references. >>>>> >>>>> Isolate: >>>>> In parallel, folio_isolate_lru() can observe the same tail page with = a >>>>> non-zero refcount and PG_lru set. It clears PG_lru before taking its= own >>>>> reference. If this races with the final folio_put() from the split p= ath, >>>>> __folio_put() sees PG_lru already cleared and skips lruvec_del_folio(= ). >>>>> The page is then freed back to the allocator while its lru links are >>>>> still present in the LRU list. A later LRU operation on a neighborin= g >>>>> page detects the stale link and reports list corruption. >>>>> >>>>> [1] >>>>> [ 22.486082] list_del corruption. next->prev should be fffffffec10e= 0ac8, but was dead000000000122. (next=3Dfffffffec10e0a88) >>>>> [ 22.486130] ------------[ cut here ]------------ >>>>> [ 22.486134] kernel BUG at lib/list_debug.c:67! >>>>> [ 22.486141] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP >>>>> [ 22.488502] Tainted: [W]=3DWARN, [O]=3DOOT_MODULE >>>>> [ 22.488506] Hardware name: Spreadtrum UMS9230 1H10 SoC (DT) >>>>> [ 22.488511] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS = BTYPE=3D--) >>>>> [ 22.488517] pc : __list_del_entry_valid_or_report+0x14c/0x154 >>>>> [ 22.488531] lr : __list_del_entry_valid_or_report+0x14c/0x154 >>>>> [ 22.488539] sp : ffffffc08006b830 >>>>> [ 22.488542] x29: ffffffc08006b868 x28: 0000000000003020 x27: 00000= 00000000000 >>>>> [ 22.488553] x26: 0000000000000000 x25: 0000000000000004 x24: fffff= ffec10e0ac0 >>>>> [ 22.488564] x23: 00000000000000e8 x22: 0000000000000024 x21: dead0= 00000000122 >>>>> [ 22.488574] x20: fffffffec10e0a88 x19: fffffffec10e0ac8 x18: fffff= fc080061060 >>>>> [ 22.488585] x17: 20747562202c3863 x16: 6130653031636566 x15: 00000= 00000000058 >>>>> [ 22.488595] x14: 0000000000000004 x13: ffffff80f91e0000 x12: 00000= 00000000003 >>>>> [ 22.488605] x11: 0000000000000003 x10: 0000000000000001 x9 : ffe85= 721f0e25f00 >>>>> [ 22.488615] x8 : ffe85721f0e25f00 x7 : 0000000000000000 x6 : 6c656= 45f7473696c >>>>> [ 22.488625] x5 : ffffffed39b23026 x4 : 0000000000000000 x3 : 00000= 00000000010 >>>>> [ 22.488636] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000= 0000000006d >>>>> [ 22.488647] Call trace: >>>>> [ 22.488651] __list_del_entry_valid_or_report+0x14c/0x154 (P) >>>>> [ 22.488661] __folio_put+0x2bc/0x434 >>>>> [ 22.488670] folio_put+0x28/0x58 >>>>> [ 22.488678] do_garbage_collect+0x1a34/0x2584 >>>>> [ 22.488689] f2fs_gc+0x230/0x9b4 >>>>> [ 22.488697] f2fs_fallocate+0xb90/0xdf4 >>>>> [ 22.488706] vfs_fallocate+0x1b4/0x2bc >>>>> [ 22.488716] __arm64_sys_fallocate+0x44/0x78 >>>>> [ 22.488725] invoke_syscall+0x58/0xe4 >>>>> [ 22.488732] do_el0_svc+0x48/0xdc >>>>> [ 22.488739] el0_svc+0x3c/0x98 >>>>> [ 22.488747] el0t_64_sync_handler+0x20/0x130 >>>>> [ 22.488754] el0t_64_sync+0x1c4/0x1c8 >>>>> >>>>> [2] >>>>> *F: big folio before split >>>>> *T: tail folio after split >>>>> CPU0 (f2fs GC) CPU1 (split_folio_to_order) CPU2= (folio_isolate_lru) >>>>> *F: pagecache refs =3D n >>>>> *F: extra refs =3D split >>>>> *F: PG_lru set, mapping !=3D NULL >>>>> split_folio_to_order(F) >>>>> folio_ref_freeze(F, 1) >>>>> ... >>>>> lru_add_split_folio(T) >>>>> list_add_tail(&T->lru, &F->lru) >>>>> folio_set_lru(T) >>>>> folio_unlock(T) >>>>> /* T PageLRU set */ >>>>> >>>>> *T: pagecache refs =3D 1 >>>>> *T: extra refs =3D GC + split >>>>> *T: PG_lru set, mapping !=3D NULL >>>>> >>>>> move_data_block() >>>>> folio =3D f2fs_grab_cache_folio(T) >>>> >>>> Getting T from f2fs_grab_cache_folio() via __filemap_get_folio() shoul= d >>>> be impossible, since the xarray should either have the original folio = F >>>> or folios are not EOF. But it reminds me a bug I fixed recently. >>> The folio be out of EOF is caused by the coming folio_end_dropbehind, r= ight? >> >> To be specific, __filemap_get_folio() can only see: >> 1. the original folio before the split, because only the original folio >> is present in the xarray as a multi-index entry; >> >> 2. after-split folios that are not EOF, because EOF folios are not added >> to the xarray[1] for __filemap_get_folio() to get. >> >> That is why I said getting EOF tail folios from __filemap_get_folio() >> is impossible. >> >> [1] https://elixir.bootlin.com/linux/v7.0.12/source/mm/huge_memory.c#L38= 84 > understood. Could the truncate of the file happen after the split > since the callstack is launched by vfs_fallocate. Can you elaborate on the code behavior in terms of =E2=80=9Ctruncate=E2=80= =9D? After split, after-split folios are updated in xarray, then the issue has nothing to do with folio_split() anymore. I am not sure what issue you are trying to discuss here. > >>>> >>>> Does your v6.18 kernel have this commit[1], which fixes an xarray issu= e >>>> in folio_split()? If not, can you give it a try and see if the issue >>>> goes away? >>> Yes, this patch is on the tree. >>>> >>>> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/c= ommit/?h=3Dv6.18.35&id=3D08b2b65c63bb26dbb2a4e2adc2ce96e2929b8b60 >>>> >>>>> ... >>>>> __folio_set_dropbehind(T) >>>>> folio_unlock(T) >>>>> folio_end_dropbehind(T) >>>>> folio_unmap_invalidate(T) >>>>> __filemap_remove_folio(T) >>>>> folio_put_refs(T, 1) >>>>> folio_put(T) >>>>> >>>>> *T: pagecache refs =3D 0 >>>>> *T: extra refs =3D split >>>>> *T: PG_lru set, mapping =3D=3D NULL >>>>> free_folio_and_swap_cache(T) >>>>> folio_put_testzero(T) >>>>> /* refcount: 1 -> 0 */ >>>>> >>>>> *T: pagecache refs =3D 0 >>>>> *T: extra refs =3D isolate >>>>> *T: PG_lru set, mapping =3D=3D NULL >>>>> fol= io_isolate_lru(T) >>>>> f= olio_test_clear_lru(T) >>>>> __folio_put(T) >>>>> __page_cache_release(T) >>>>> folio_test_lru(T) =3D=3D false >>>>> /* skip lruvec_del_folio(T) */ >>>>> free_frozen_pages(T) >>>>> fol= io_get(T) >>>>> lru= vec_del_folio(T) >>>>> later: >>>>> list_del(adjacent->lru) >>>>> next =3D=3D &T->lru >>>>> next->prev =3D=3D LIST_POISON / PCP freelist >>>>> BUG >>>>> >>>>> Assisted-by: Cursor:claude-opus-4-8 >>>>> Signed-off-by: Zhaoyang Huang >>>>> --- >>>>> patchv2: update codes to eliminate bad page status >>>>> --- >>>>> --- >>>>> mm/huge_memory.c | 22 +++++++++++++++++++++- >>>>> 1 file changed, 21 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>>>> index 970e077019b7..c24c12f71157 100644 >>>>> --- a/mm/huge_memory.c >>>>> +++ b/mm/huge_memory.c >>>>> @@ -3878,6 +3878,23 @@ static unsigned int folio_cache_ref_count(cons= t struct folio *folio) >>>>> return folio_nr_pages(folio); >>>>> } >>>>> >>>>> +static void clear_dropped_split_folio_lru_flags(struct folio *folio) >>>>> +{ >>>>> + /* >>>>> + * __split_folio_to_order() clones these LRU state bits from th= e >>>>> + * original folio. A folio that is dropped instead of being ad= ded to >>>>> + * the LRU will not pass through lruvec_del_folio() and >>>>> + * __folio_clear_lru_flags(), so clear the cloned state before = it is >>>>> + * freed back to the page allocator. >>>>> + */ >>>>> + set_mask_bits(&folio->flags.f, >>>>> + (1UL << PG_referenced) | (1UL << PG_active) | >>>>> + (1UL << PG_workingset) | >>>>> + (1UL << PG_unevictable) | __PG_MLOCKED | >>>>> + LRU_GEN_MASK | LRU_REFS_MASK, >>>>> + 0); >>>>> +} >>>>> + >>>>> static int __folio_freeze_and_split_unmapped(struct folio *folio, un= signed int new_order, >>>>> struct page *split_at, str= uct xa_state *xas, >>>>> struct address_space *mapp= ing, bool do_lru, >>>>> @@ -3958,6 +3975,7 @@ static int __folio_freeze_and_split_unmapped(st= ruct folio *folio, unsigned int n >>>>> for (new_folio =3D folio_next(folio); new_folio !=3D en= d_folio; >>>>> new_folio =3D next) { >>>>> unsigned long nr_pages =3D folio_nr_pages(new_f= olio); >>>>> + bool drop =3D mapping && new_folio->index >=3D = end; >>>>> >>>>> next =3D folio_next(new_folio); >>>>> >>>>> @@ -3966,7 +3984,9 @@ static int __folio_freeze_and_split_unmapped(st= ruct folio *folio, unsigned int n >>>>> folio_ref_unfreeze(new_folio, >>>>> folio_cache_ref_count(new_fo= lio) + 1); >>>>> >>>>> - if (do_lru) >>>>> + if (drop) >>>>> + clear_dropped_split_folio_lru_flags(new= _folio); >>>>> + else if (do_lru) >>>>> lru_add_split_folio(folio, new_folio, l= ruvec, list); >>>>> >>>>> /* >>>>> -- >>>>> 2.25.1 >>>> >>>> >>>> Best Regards, >>>> Yan, Zi >> >> >> -- >> Best Regards, >> Yan, Zi Best Regards, Yan, Zi