From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CY7PR03CU001.outbound.protection.outlook.com (mail-westcentralusazon11010003.outbound.protection.outlook.com [40.93.198.3]) (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 9780825B0BC for ; Sun, 5 Jul 2026 03:00:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.93.198.3 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783220454; cv=fail; b=PGY/+5Uv6FpMrPIdl8USTbsta0N0UbKSQuTl8KH59MmfFwTVy8ZqpvKBOguebGwO4EkqKxAflg84LosTFeXvumjY+KREWhT5AnNH64JXTCirIEndO3lvonpU2gyuZxzIsIhT/svE/GM7VGX6VnbK0XDVHbunJUIldr9oS6OIUNw= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783220454; c=relaxed/simple; bh=ucVVM+AE26GLlZmb8PEAupIFpHCopRWaQyrlcfYvxwI=; h=Content-Type:Date:Message-Id:Subject:Cc:To:From:References: In-Reply-To:MIME-Version; b=bUsTIMoBBCC917peYOTQJbW9hpJruc5q0CjdW/Mw13nK5RwPU5jJPlaNICANdTux5jBj9KFD/FjTKD2Iwkrh9jEaHBLZ8wzH/JK5IfLkuLT927KQJEffUasJ6Lafdmg2dsDsYK92JjocoO98HtQrMf675ho0xyXf9JLM1Hwjd8Q= 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=aHeZpL1B; arc=fail smtp.client-ip=40.93.198.3 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="aHeZpL1B" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=m6A9gXkct3PEZwuTX5WEIfBUBu0ZqQ5Rzpt3vA+OQLWPcz+cUmZVa4CBK2NqVMGMhLxJf7sa+mylddKKbKlhP7QG2rxnyjzoOk2cp052PdA1zL8htWnamfl12w9oUaol/9L86tvokYsSbYky4pP/0E4FmTU5LWc4nEQtvfIGLWEfz5h5oXMrq+euzrMOYatP6N2dYYdETdKCVjKo3jgd3uhdyejyamQgpBysGCY4tgPaSX5mcT2ChLpnYmEjblxjMGdU8tbLE6rvX2S91nzaYKeF4nmN6cNeNCqVAUYIjiQBiwbaqgeEMgdrvIm8H6nDz1JWY9tuZ9r7O7437MXj9A== 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=mZI8xjwftEfCK/s0clvaoGNIcmMYBCvnGWNvDJOHlSE=; b=uEl8hlfonW4SQSjMpAz1S4BZ7DC7eoJ6MbAIQB0ua/u09UKufz17N8GVQy3ff9sNFy5A2K4182w3pWdQOp1hKx3mESDnpo0/a+KTYHgViik0BV10C/V37gYR+jKIR8A0p21QMyAum3nH9PBaRg2ae7VWCUIz8dz2ezdQF7Qj2YhqHjdMN5Ye282ueEc1lpWAj6het91MfuMPMKoFKkqlisxGdy50zTNzt/ig+lDyyAW4Lg42ybRMBW7lOc5xdy7LhsxM3rWJjIWswjK7zQIZMXdRMMUTCoIQ928bkNlcuTi4MX5Gq9DLRPsT+grH93Nii2hlMtDzkXv12WEnBQZ73Q== 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=mZI8xjwftEfCK/s0clvaoGNIcmMYBCvnGWNvDJOHlSE=; b=aHeZpL1BsMTROYm2AYHuam/b1VOjzFYV37gWFX9pTlLoxC3Y9ecqsoDHpwB2U/B3osXerPesciJHqaatqjCjBtSJCDXmbroWBM4PewYnFTba1wD14pX3/BuLIRe/4uyvZuy/3Y0c6NAYum7N3eFYl60k56ORrxZ7pJyfAhyzTGInmi43vWiflPrOQ25LwtQBIE2+nEBOd+YPLVpkUQfqgOTD64W321NqYzFTwB8Jvw3nl7o+0zBKF05/G9fqst4uAeUiIUPjgh44n5N8RTzaifFk591Ktxc6Cn4FGNy9SP7UWL/sjspkdl8A938Q37lshSJlV1rFxalFRALAaEjJKQ== 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 PH0PR12MB7984.namprd12.prod.outlook.com (2603:10b6:510:26f::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.181.10; Sun, 5 Jul 2026 03:00:48 +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.0181.009; Sun, 5 Jul 2026 03:00:48 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 04 Jul 2026 23:00:46 -0400 Message-Id: Subject: Re: [PATCH v2 0/5] Keep tail page private zero at free and folio split time Cc: , , "Zi Yan" To: "Andrew Morton" , "Vlastimil Babka" , "Suren Baghdasaryan" , "Michal Hocko" , "Brendan Jackman" , "Johannes Weiner" , "David Hildenbrand" , "Lorenzo Stoakes" , "Baolin Wang" , "Liam R. Howlett" , "Nico Pache" , "Ryan Roberts" , "Dev Jain" , "Barry Song" , "Lance Yang" , "Mike Rapoport" , "Dennis Zhou" , "Tejun Heo" , "Christoph Lameter" , "Alistair Popple" From: "Zi Yan" X-Mailer: aerc 0.21.0 References: <20260703-keep-subpage-private-zero-at-free-v2-0-2970fe777dd6@nvidia.com> In-Reply-To: <20260703-keep-subpage-private-zero-at-free-v2-0-2970fe777dd6@nvidia.com> X-ClientProxiedBy: YQZPR01CA0031.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:86::29) 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_|PH0PR12MB7984:EE_ X-MS-Office365-Filtering-Correlation-Id: cba50119-a32e-4369-7433-08deda419d91 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|23010399003|366016|1800799024|376014|7416014|921020|11063799006|56012099006|6133799003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: YInbpDXdYSVF/I9cAe3xNChrpW+EajUIM/RD04H3ebg24f1WB0Jo70be4e30ONkUpjgGu1XchFWVEbhnoA6TsVdZeOo6GgLtD0zzjqGKkAeiqEIq2euDj5hsecPCJt0+fiLJFZchT93CzvkZuLp5TdMtEcgJm1OJFPIuTAQxRxrsV1jklrCojaGf9/m7ukt3usrVvIxOe6QTBKQiQg6LHcXIfu4Xx/3I8Bdmq2y83MMC9JXmeQ35YvHfIZeGJY863ROJr+OtMp3G6H28Z4buOzao4Cm4LurUAW1hLfswg75GwVq/ZzxtyHyi8JfSKJTbQhzdFOnTHXq35iJFNnH4B5m/ye+aN5I3SoCTFqLC1gygBcmXvOq4fJo3tDUE+6UIH0rKzwqNMeI7hpZKgKlNjKfh/MOzltqzg5KxMlikN68vVOwAzwoqLGpdjT8mBeksRmQc2V/hX46egLlE2LhSLKJNgUeMWizPbspOYC37a4yMzn4QBEMQ/Gc7LRnslJyURsETZO+MQ5gM3G+as5cp/ydSsM1qqtcPebUhmu6LNrS3vqibCXOzkzE0JPiB6bQ2BvAkzJX39XHjw78cdVE0Il/AuA5ITJFa1wnal39ok1orKK3RoKcRBKufn6ZImuGIJHSWJB8Y/v2PGgJMLZSC2ysTEuDnZPoVM24C468A0lVTTxgHG4Fe9WokhO2HAGMU91+vWXxpFbR+AeDEqMZYBQ== 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)(23010399003)(366016)(1800799024)(376014)(7416014)(921020)(11063799006)(56012099006)(6133799003)(22082099003)(18002099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?S2tMaUhGNWVNTk5wWkVtTFNBTlZDdFNJOUNreU9FTmdXRElqWit5eFN1azVr?= =?utf-8?B?ZDdLYXJGRUVudy9YaXZLZzg5N1pyYUtldW8rNWsxMkVtL3hBcHhyd3cxVVlU?= =?utf-8?B?cXBJVkFnazdMb1Ywc2hHQXlabFFGUzAvNCtEUHlkZm8rTGZUeVI4NDI3eUxp?= =?utf-8?B?d2NJYmFZT2prZW5KN2Q1SXB1NE5MYloxNFdBSi9WRGR2TEN4MVBXVkY2YjAx?= =?utf-8?B?bVhKUE1aUmZ0STlVNDEyYnJOdnFORjFGSk1lWk8vRkhBOStla2VjNHBKOElW?= =?utf-8?B?VGYweEZGWDZBR2xGZ2JlRm9pdm5jdlY1SFFlUVdua05oMmFtcW93emUzMHVQ?= =?utf-8?B?ajc0M2FNaWlHM1ZLK2NXNG9mZHVsR3huRHAxTVBYb2lObWZQdXpaZEtaT1VB?= =?utf-8?B?V0MyREhFb0xLd0xCK3AxYmc2OG44L2pZUjduNG9jbmlPTTVVSGlOMzJxMGQ1?= =?utf-8?B?dCtWZm1hOUdMeHQzS0ZDR0V6N0NMdkZWeStCOTBjL1ZVM2U4QXp1emFvVmJT?= =?utf-8?B?b20xTWhGaFdaQUtwS1Z0YjRBOWdsQjU2YStHbzl6Qjd4SmdnMmNsbTBha2hr?= =?utf-8?B?VWVGemkrZENpOFE4d2ZYWHpMaytCYlZrdGtQdE0vR21LOWZpdHBxek9kanMz?= =?utf-8?B?c243RWpFaFNwMVVFV3hFejAxY2ZiZDVmU0doUldwVWJ1ZWxPLzVvNmNobGUz?= =?utf-8?B?d3k5ZWUrSXk4cU1LeDJ0OUg0NFJ4K2kwQ1pPUG0rd3d4ZzQ0YnZiMEFBN3FW?= =?utf-8?B?NE14SWlRcG0va3VYL1ZmVm5JenRteDlLVmdTQlFiLzNTZFVSaVdhQTZPRElT?= =?utf-8?B?NlgvL0owYnNBQ1RMcE81ZFc4TWpuSFhLbUpYVWpwRVNYQXNzVEhyNzllWm82?= =?utf-8?B?YnpzN0NrT09tYmd2ZTJuNUloMm42VHZTQTMvOUs5UDJRMENPWFZNNjNGV21M?= =?utf-8?B?ZWNMcUJ1Ry9BdW5qV29FeUFTcEZIZEFyQ1l2c3AyN3g1VWdoUzI5LzVXMENh?= =?utf-8?B?dENMS0tKbFdFclhCQjhnMjRiRXhmcjVYazNZK0hQL3NyOGd3aUpJK255Vllj?= =?utf-8?B?S1BsNzVwQ0tBSVI0TC93anRNMExGR1FxWHloTjhOckJudjErTlMyTnNNSFlP?= =?utf-8?B?aXFxNUg1d1RXTHhrVmtOaWlodVEydDJMd01RT09vSnRrcVo2L0lRVUtIUHpp?= =?utf-8?B?YzV2ZGQrU2ZHdHh4cE1pcURyTHRjemxodWFFQTZEc3RnTUNzTkxCTjQ2OTJa?= =?utf-8?B?ZlVNZ0NlTmFJK2xONFROa0Z5ekplVGlwZnZzNGZHV1lBZ2pJSy82emtRZUxT?= =?utf-8?B?SkR5c1V5ODU5amdzSU5aamlnTHk3TFBKQU1kU0tqYnJMYTJNaDBVUjdQclAx?= =?utf-8?B?RjZWYjVWVWZUNGh0dStleURlTExtaGdLQkFwYUVtY2VRMGJWdlpRbWRJeXdS?= =?utf-8?B?RGN6aHdyRGhMS2NTc2ovb2VuS3VwS0ZjQ0tzTnVyQjM3dGNNLzQyWGhLaHlV?= =?utf-8?B?VjQ0RU1NUk9DZExxakR1MHZ2UXFtZlQ5ODM3bUkwMVVOaFA1ekZaWjQrUTg4?= =?utf-8?B?ZGZ2NVpXVzVUNCt0VXlBVU9RVGl5N0MyTTl0b1JUeXEvSHlVMVZTM0NKeTd1?= =?utf-8?B?dWNJRHZKTUhGT0lhcFE4UCtaR3BDSDhxTUJ0bVFoN3NrYmtZT0dxOG1DNSs0?= =?utf-8?B?VS93akdFVnlTRjZpOHpCUWptZWM0QkRmbXM0bHoyVndMV3R6cUVINy9HeEpk?= =?utf-8?B?dmFJa2tpd0swZjR4ZDBsUkc4MU1Pd2FydXJCVHBTa3AzallSc1RmM2R1N1cx?= =?utf-8?B?aVJPMTVsc1lWLzJpUXR3enhRbHZmbVZTZVM5ZjlTWXEzc1pLb3JYb1ZiZGpx?= =?utf-8?B?cEdHdXRwc0NES1F4ZENubzZYeVF6M0t0YzJKSW5ValNMczlORmtiMUNvUWkv?= =?utf-8?B?VjlERnhCUmhvL2l4SUFQTTVjTlc2QlJCTFJhRUZjVVZqNkoyMlFoMlNxUkdE?= =?utf-8?B?ZHFwMEx3RXhoUG5qMm5vV0lnMDJIVUdGVVkzc1JNSUVGUm54WFVFbkpkRTNa?= =?utf-8?B?MVFjQUJrWHlZQnRBNDFkZm01T3BVbjlISEVPbThRclZud1RFdW94aWZNWDU3?= =?utf-8?B?UlRhUVRaNHpnMUJjQy9yTlk0VkRNNkZZUUswV2xjQ0ErY1ZUcjBEcW5Gam9H?= =?utf-8?B?QWpISUVOVm9DcmxkcW92amEyRGxRL2dlbGJMUThMQXVyazdrbnBqYjZoZ3pI?= =?utf-8?B?N012YWpPeXQwUHAyWFVXUEFCbFA5MjcyM0R0REJ3bDhtMTBpREJiRWdvOHZq?= =?utf-8?Q?Bx4/NTGYIf9Rbsrp/I?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: cba50119-a32e-4369-7433-08deda419d91 X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jul 2026 03:00:48.6143 (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: 9c55J3GNi18/8yHd653T8AImOzHma6MlvKJAj9un2gdrQS4s48iER/q3gkZLhyhi X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7984 On Fri Jul 3, 2026 at 9:47 AM EDT, Zi Yan wrote: > Hi all, > > This patchset makes sure tail_page->private is zero before compound or > high-order pages are returned to the allocator. It also checks tail pages > that become new folio heads during large folio split, before their privat= e > fields are used by new folios. > > It is based on mm-new. > > Note on ZONE_DEVICE and DAX page/folio > =3D=3D=3D > ZONE_DEVICE and DAX use prep_compound_tail() to reinitialize folios, so > tail_page->private was reset before this patchset. There was a concern th= at > after this patchset stale ->private can appear after ZONE_DEVICE/DAX foli= o > initialization. My reasoning is that no code sets ZONE_DEVICE/DAX > page->private, so their page->private stays zero all the time. > ZONE_DEVICE_PRIVATE page migration only supports anonymous memory without > swapcache, so after the migration ->private remains zero. > > But let me know if my reasoning is wrong. It can be fixed by adding > ->private zeroing code in ZONE_DEVICE/DAX folio initialization code. > > Motivation > =3D=3D=3D > > page->private is zeroed at page free time since commit ac1ea219590c0 > ("mm/page_alloc: clear page->private in free_pages_prepare()"), since we > concluded that it might be too much to ask every page user to free a page > with ->private zeroed. The holder of the last page reference might not kn= ow > whether ->private needs to be cleared. > > For compound and high-order pages, tail_page->private can also leak to > later users if it is left uncleared. The page allocation path does not ze= ro > every tail_page->private field, so they can be seen by new users and caus= e > unexpected issues[1]. > > Check tail_page->private at page free time, and check tail pages that > become new folio heads during large folio split. With those checks in > place, prep_compound_tail() no longer needs to clear tail_page->private > when preparing compound page metadata. > > Overview > =3D=3D=3D > > 1. Patch 1 clears all pages ->private before percpu-km frees them. > 2. Patch 2 removes setting page->private in compaction code when a free > page is taken out of the buddy allocator. cc->freepages is indexed by > page order, so storing the free page order in page->private is > redundant. In alloc_contig_frozen_range_noprof(), > isolate_freepages_range() is used to grab free pages from buddy > allocator and it leaves the aforementioned page->private set until > either split_free_frozen_pages() or prep_new_page() is called. That > stale value without resetting triggers the tail_page->private nonzero > check once set_page_private(0) is removed from prep_compound_tail(). > > 3. Patch 3 adds back the page->private check for tail pages promoted to n= ew > folio heads in __split_folio_to_order(). > 4. Patch 4 adds a tail_page->private check in the page free path. > 5. Patch 5 removes tail_page->private zeroing from prep_compound_tail(). > > Link: https://lore.kernel.org/all/20260206174017.128673-1-mikhail.v.gavri= lov@gmail.com/ [1] > > Signed-off-by: Zi Yan > --- > Changes in v2: > 1. added reset page->private when percpu-km frees pages > 2. replaced subpage with tail page/tail_page in all patches > 3. moved implementation details from cc->freepages patch message to cover > letter, since it is too much for a patch description. > 4. used VM_WARN_ON_ONCE_PAGE() in __split_folio_to_order() patch without > fixup. The expectation is to catch any violation during development > phase. > 5. guarded tail_page->private check behind is_check_pages_enabled(). > 6. replaced tail_page->private reset code with VM_WARN_ON_ONCE() instead = of > deletion in prep_compound_tail > 7. the pre-existing issue in alloc_contig_frozen_range_noprof() is under > discussion and might not be worth fixing. > - Link: https://lore.kernel.org/all/d44ae8a5-ec70-456b-92a0-ce7ccabf69= 17@kernel.org/ > - Link to v1: https://lore.kernel.org/r/20260628-keep-subpage-private-zer= o-at-free-v1-0-f4ce3930d10f@nvidia.com > > --- > Zi Yan (5): > mm/percpu-km: clear page->private before free them > mm/compaction: stop recording free page order in page->private > mm/huge_memory: add page->private check back in __split_folio_to_or= der() > mm/page_alloc: make sure tail_page->private is zero at page free ti= me > mm/page_alloc: remove set_page_private() in prep_compound_tail() > > mm/compaction.c | 3 --- > mm/huge_memory.c | 7 +++++++ > mm/internal.h | 2 +- > mm/page_alloc.c | 13 ++++++++++--- > mm/percpu-km.c | 9 ++++++++- > 5 files changed, 26 insertions(+), 8 deletions(-) > --- > base-commit: e031e55776cf9193b4720a253e92539ca536d224 > change-id: 20260603-keep-subpage-private-zero-at-free-a1e1435025dc > > Best regards, Answers to Sashiko's reviews: https://sashiko.dev/#/patchset/20260703-keep-subpage-private-zero-at-free-v= 2-0-2970fe777dd6%40nvidia.com Q1: To Patch 1, this isn't a bug introduced by this patch, but does pcpu_create_chunk() overflow chunk->populated on SMP configs? Answer: I am not familiar with the code, but based on my understanding and the chat with codex, a patch like below could fix the issue. I will wait for the feedback from percpu-km people about it. diff --git a/mm/percpu-km.c b/mm/percpu-km.c --- a/mm/percpu-km.c +++ b/mm/percpu-km.c @@ -74,8 +74,13 @@ static struct pcpu_chunk *pcpu_create_chunk(gfp_t gfp) chunk->data =3D pages; chunk->base_addr =3D page_address(pages); =20 + /* + * nr_pages covers the physical backing for all units. The populated + * bitmap and pcpu_nr_populated accounting are per-unit, so only mark + * the logical chunk page range populated. + */ spin_lock_irqsave(&pcpu_lock, flags); - pcpu_chunk_populated(chunk, 0, nr_pages); + pcpu_chunk_populated(chunk, 0, chunk->nr_pages); spin_unlock_irqrestore(&pcpu_lock, flags); =20 pcpu_stats_chunk_alloc(); Q2: To Patch 5, does replacing the explicit zeroing with a warning leave the private field uninitialized on production kernels? Answer: there are a lot of ifs in the question. It starts from one could allocate a non-compound high-order page and free it without clearing tail_page->private. This assumption is wrong, since Patch 4 will catch such code. So there is no issue. --=20 Best Regards, Yan, Zi