From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from CH1PR05CU001.outbound.protection.outlook.com (mail-northcentralusazon11010004.outbound.protection.outlook.com [52.101.193.4]) (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 5D262391841 for ; Thu, 9 Apr 2026 08:55:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.193.4 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775724962; cv=fail; b=bdD+q8Fe2/u48r4wRT9b0UGxNjawWTrsWpPif5+BhoLMFSeS5lPHn2w61fKTW99rt8tjd+bzg9aBF0flBtyqvc7Tmql2ran+jwgsqxwpJa4L0cbdDmM8OsXl7SFOIFDw7o8LSPTlSl8P+861IuQJJLKV4V9bm3z8UCJMuDpqopI= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775724962; c=relaxed/simple; bh=K/AuvPCSPejWB11EfgD13ybuldQHkNLiTjalEgnGiTo=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=W6m/xDf1aKeMUTd//r9vuuE7QXNZ8Xrwsu9BWpyYV1SQyMpt1wr2smj5zDZ4wGD7nwhKpnSxSrAkDaD5XUr9/s91s25N6cuqHw/GKHoK2y75eXdbHNwcW/hnlc072JbCerxAmGbvSWwZspkEYVledjmm0SsCAPT+mI3i8TobzL8= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=giIs9Vgy; arc=fail smtp.client-ip=52.101.193.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="giIs9Vgy" ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=zKWcqnhTJq7ZNIoarOPN3mY4COwxzDD+OWpLjY082ytsCSYGY8R5reJRoRkLj9PEnsQve5UlZ9mqKbeMJiKQDKIV/Qg64titB3hdZnf24A+HYU8T8H7Im11aT9si3kDay5hwcAdpHE1gWj20Z/JjziaN7DW0hNAwVS3wOoHztYAQwFz4xkTJD9i1lDKbc0tCxO0hNvj+hb4rsXNnTztwaNyhwPrQwfX+LkpbmxaErsnOK2VUv1bh6Tn2Rtv1G8xZYA/LbpJwuvr9qNmu7jmDpNl61kM8zb+BIjLmYCiJVzXSwaZKIsHyN7ZJZcUnRrim/WEfQaGrffnRDPOosUFHJg== 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=ZOtSyHAZ+2ZjsCUsMTobsb1nqyYu5gywelrfSZgKuQE=; b=OpAP++M+GLF09itnpdY0vhRw0ZXhixVtpsjbTY1H72K+VdN96r75u8TNV8SpJh2AYVzgTfU9ULyuvSFbTta0sPFoCpD3DLMAIVke0ge4Vr8cLuLM44MZkGKKTy1SJFY9azULop/jbwc/JWQ3Ekze4P4ygHFWFZYgYCt7f7oFPg/RLQ7QcNfsTXsMA7i8+qCpuOOxEmT/7zv02RWbkRWa+qocvMBYsjwaZL1/1mM0f3rmOfroUEADIgu721k3U1nn2lbYsdZX2pCPp584XqTar7OPClXYl37BLJGvRrFEThkj8Vr5QoCBLaz4wdQpTvhi42OezZzLBtLyJKpLCfVdWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=linux-foundation.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZOtSyHAZ+2ZjsCUsMTobsb1nqyYu5gywelrfSZgKuQE=; b=giIs9VgyMq8u1TWF8KIHJO+YzG9M+gwAheLXbo3/XMCGvijjU+lewD/Q4VRyHLP8jGPNJRE6Z6UzbM3UsjFGg6wJShehHqLhTPh3P9NCnBLegoENDGqUEsbql6bE4NouQtNVdpzsRbfhe1KAq8Nf6ZsK08Lwpaozge8Vk8qXIQ8= Received: from PH7P220CA0177.NAMP220.PROD.OUTLOOK.COM (2603:10b6:510:33b::25) by CH3PR12MB8308.namprd12.prod.outlook.com (2603:10b6:610:131::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.19; Thu, 9 Apr 2026 08:55:51 +0000 Received: from SN1PEPF0002529F.namprd05.prod.outlook.com (2603:10b6:510:33b:cafe::f9) by PH7P220CA0177.outlook.office365.com (2603:10b6:510:33b::25) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.9769.37 via Frontend Transport; Thu, 9 Apr 2026 08:55:50 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=satlexmb08.amd.com; pr=C Received: from satlexmb08.amd.com (165.204.84.17) by SN1PEPF0002529F.mail.protection.outlook.com (10.167.242.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.17 via Frontend Transport; Thu, 9 Apr 2026 08:55:50 +0000 Received: from satlexmb10.amd.com (10.181.42.219) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 9 Apr 2026 03:55:49 -0500 Received: from satlexmb08.amd.com (10.181.42.217) by satlexmb10.amd.com (10.181.42.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.17; Thu, 9 Apr 2026 03:55:49 -0500 Received: from [10.136.43.140] (10.180.168.240) by satlexmb08.amd.com (10.181.42.217) with Microsoft SMTP Server id 15.2.2562.17 via Frontend Transport; Thu, 9 Apr 2026 03:55:45 -0500 Message-ID: Date: Thu, 9 Apr 2026 14:25:39 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/page_alloc: use batch page clearing in kernel_init_pages() To: Andrew Morton CC: "Vlastimil Babka (SUSE)" , , , , , , , , , , , , David Hildenbrand , References: <20260408092441.435133-1-hsalunke@amd.com> <22b6ff3c-9d41-4eb0-9beb-cb92f3ada89f@kernel.org> <4e8c218b-ac5e-4674-9e1e-acf750f0a5c8@amd.com> <20260408083229.45d1a083f17484d3b2678855@linux-foundation.org> Content-Language: en-US From: "Salunke, Hrushikesh" In-Reply-To: <20260408083229.45d1a083f17484d3b2678855@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002529F:EE_|CH3PR12MB8308:EE_ X-MS-Office365-Filtering-Correlation-Id: a70bce2d-6fff-46b5-4a3b-08de9615cc8c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|82310400026|7416014|376014|36860700016|22082099003|18002099003|56012099003; X-Microsoft-Antispam-Message-Info: IW7IY3hM6df0zFALwDgEszJyfYEED1KIMkzOcSODni/dDOBH2v8Y3FjhpZetH5/4ePI8L/yUT9XGYTmJPnQIUrsx0wbNowHYOfqdjGDanan7wlgSpO3MAwjajpn2Ppd12sMOlAy3m4J6YQ7fLPTI6d0oZx/vV1t3V0seZ5xQ4k3R3x/zPmrk4A6kvuflkzuZaadkQdibzsmHhF86ZAhFn+Yqlha9jUbz7Fi+v/erMuHIqVtLNmcjOUe3HDaXVoGDGSmrHY48AdBMOsKTB5W1W8qs0IpL1WslFcxF/R4tav3kyVSpK4fdhCvOSmLPdJQKUAnxd2wS0kVVCW0AjCoOu0TCuBZdfHVN56+yglKOJkqdVN4vjjyP/wQBzrxXHBWrv3yZ015GhV5ZccB+Eiwwk4SbLyvwhwdK81KZvICoyC2IonTGOjSbgL6bdjktFbQ1p0K23MS/Tb9IfbbeT5cdz31jvlkX++ymdUBU9C3jE2Q7uHS77A795Ng/0X/RX2puIcS5DCgN2v1FBwvXC8kUwkSCG3Ib7vb1OjPWgvb5fIQyieNRjM7y2fwr+IbLn+fk2n4JRf6/PkkJU2H7c82WIb/F0zNM2IJ1bGhL2rfKAkE2AmyQKH+6Fx/NKWP27wNc/90y+baMOP0REBTLhvf1pfUiWryn/eFLPrXu8GzgkE/vMA2DQVOV/Xi0743DktogA0UrWT5IH08xBx0Kw3HJg0lpFeLOYJY2qyYUHptZlYKjYop1SdhDpCfyFhbtaQ2Ro40IGbniaFAYAeY9ePugmA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:satlexmb08.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(82310400026)(7416014)(376014)(36860700016)(22082099003)(18002099003)(56012099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: o3ss6ohbdxBb8g27JW3rk6IEnj+jTn74vqJN8GSSFbEkKKbI8MV9egUZ9xIsREQRXgxi6Wb8+C9K7YDf4MOSo5w5JJMEc1iMori5cVKUgAl+SpAZ/ktDBXEBrFdJWcusx4AlsBRmKbIpX4xeTU6z81YlFvUyVbLexNq3kAmNEJCpKX/1jJKijFkEfNDEkGL5uI0Gb07YQPUXI7qGG7Ujvq3jpxlG1qj04aKYRAzaz2hNEASWqhki9cfzPtlT1Yqy2cqfICmaSZwnlfATpJ7jRPrscGBtAAyPjsDbKVCXelirS9Zle0txbCBz0ZzQBgYA3++CzQttHuGuJ7HcRp2YQ7Uw1a+DYFqIfVlJBddIRqJDaKuN41vOH1kvQGsq5kl21GuPiVzRUF7OWcR0UdOyETzjoiZ5uew08Vo8ZQVu9azPts61iGGg5uL+62It2Wsy X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2026 08:55:50.2804 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a70bce2d-6fff-46b5-4a3b-08de9615cc8c X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[satlexmb08.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SN1PEPF0002529F.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR12MB8308 On 08-04-2026 21:02, Andrew Morton wrote: > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > On Wed, 8 Apr 2026 16:14:03 +0530 "Salunke, Hrushikesh" wrote: > >> kernel_init_pages() runs inside the allocator (post_alloc_hook and >> __free_pages_prepare), so it inherits whatever context the caller is in. >> Testing with CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_PROVE_LOCKING=y, I >> hit this during exit_group() -> exit_mmap() -> __zap_vma_range, where a >> page allocation happens while the PTE lock and RCU read lock are held, >> making the cond_resched() in the clearing loop illegal: >> >> [ 1997.353228] BUG: sleeping function called from invalid context at mm/page_alloc.c:1235 >> [ 1997.353433] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 19725, name: bash >> [ 1997.353572] preempt_count: 1, expected: 0 >> [ 1997.353706] RCU nest depth: 1, expected: 0 >> [ 1997.353837] 3 locks held by bash/19725: >> [ 1997.353839] #0: ff38cd415971e540 (&mm->mmap_lock){++++}-{4:4}, at: exit_mmap+0x6e/0x430 >> [ 1997.353850] #1: ffffffffb03d6f60 (rcu_read_lock){....}-{1:3}, at: __pte_offset_map+0x2c/0x220 >> [ 1997.353855] #2: ff38cd410deb4618 (ptlock_ptr(ptdesc)#2){+.+.}-{3:3}, at: pte_offset_map_lock+0x92/0x170 >> [ 1997.353868] Call Trace: >> [ 1997.353870] >> [ 1997.353873] dump_stack_lvl+0x91/0xb0 >> [ 1997.353877] __might_resched+0x15f/0x290 >> [ 1997.353882] kernel_init_pages+0x4b/0xa0 >> [ 1997.353886] get_page_from_freelist+0x406/0x1e60 >> [ 1997.353895] __alloc_frozen_pages_noprof+0x1d8/0x1730 >> [ 1997.353912] alloc_pages_mpol+0xa4/0x190 >> [ 1997.353917] alloc_pages_noprof+0x59/0xd0 >> [ 1997.353919] get_free_pages_noprof+0x11/0x40 >> [ 1997.353921] __tlb_remove_folio_pages_size.isra.0+0x7f/0xe0 >> [ 1997.353923] __zap_vma_range+0x1bbd/0x1f40 >> [ 1997.353931] unmap_vmas+0xd9/0x1d0 >> [ 1997.353934] exit_mmap+0x10a/0x430 >> [ 1997.353943] __mmput+0x3d/0x130 >> [ 1997.353947] do_exit+0x2a7/0xae0 > tlb_next_batch() is (fortunately) using GFP_NOWAIT. Perhaps you can > alter your patch to not call the cond_resched() if caller is attempting > an atomic allocation. Thanks Vlastimil, David, Andrew, and Raghu for the reviews. After looking into this more, I think adding cond_resched() here was overkill. I agree that dropping cond_resched() and PROCESS_PAGES_NON_PREEMPT_BATCH entirely and just calling clear_pages() is the right approach. There's no case where cond_resched() in kernel_init_pages() is both necessary and safe: - It's unsafe in atomic context, as the BUG shows (tlb_next_batch() allocates under PTE lock + RCU read lock via GFP_NOWAIT). - It's unnecessary for common allocations (order-0, mTHP, 2MB) which clear in well under 1ms. - For 1 GiB hugepages, kernel_init_pages() only runs during the initial admin-triggered allocation. When processes later fault on those pages, clearing goes through folio_zero_user() -> clear_contig_highpages(), not kernel_init_pages(). So rather than guarding cond_resched() with GFP flags (as Andrew suggested), I'll remove it entirely in v2 to keep things simple and same scheduling characteristics as the original code, just with the batch clearing performance benefit. Regarding the 512 MiB arm64 case that David mentioned the stall from clearing that without cond_resched() under PREEMPT_NONE is acceptable, or should it be handled differently? I can introduce clear_highpages_kasan_tagged() / clear_highpages() helpers, or keep v2 minimal with the logic inline in kernel_init_pages(). Any preference? I'll test v2 across preempt=none,voluntary,full,auto with init_on_alloc=1 and CONFIG_DEBUG_ATOMIC_SLEEP=y before sending. Regards, Hrushikesh