From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 60FD943CE49 for ; Tue, 28 Jul 2026 13:54:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785246871; cv=none; b=OQTtRhB+PMCRnto3yG5S+k32VeTSJrbcFDh7Wq8zaNaVsnVIj6rUjk2zeBMbNiEEcp0wAgK6ejBTU0eU7doG2hzNaRg4oJbBaRdzjfACx9JbqxO+BXhMQvW20UPj+bTEn5H+ye7ztpAURONy+6LPsL8e4tRF4VaqTTGoILO+qdU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785246871; c=relaxed/simple; bh=7z6X7XfdgopleGABPIHz5JW+WunwLd0DYSm6xoao+gc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bf7QAhcHxDhtfNiOUj/WsCFTQWbFIlMFn2wkhSqBCTPHLpAZaa5krXl9zGHVkAKEV/2edrrkHk5u619/U1GxY5YCbRjvZuLrEIYGaurUsXNJMKl0ZLTrUMqO5if3bQGDNZtGcsFBHEwq6XdbuzOFAqMU4gXQY64u9GgKigrPGUg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=ZN4TRRvN; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="ZN4TRRvN" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zYC0ultKQsGv6LBjC7M2/8oVicnJZI6YfD47Q5rdx2M=; b=ZN4TRRvNuRKyGL38QnCTD8PqgV zDQMYDVgJdrFKlqsWUqBkmVaTLEflh7qLXxn5TR1qLUygPHiBS7CPrhLM1hlcT6gjU1Nl0L11/Vzm 5B4r2+mFGpv0DSRKxrpZILb8bCFkhrsJcxV0tbBZbYByn5hlwhplJL5yg92ukPtfH1y3UjUCRuxgy /J7wRkkWSNDheAlewdBKlxKTSVyJcB+e7CfduApaLQqDfwLdsWxc6bh975lLqXfRcEM5tiiy1+kjh pt5Oozk13s+lMWW2y2+MJiY22p6jkjv5U/sU5aqIGmjo/QrZ0+7//VzmdTiFiS8aQiQcklTufInFD F5qRgSQA==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1woiFu-007iqo-2d; Tue, 28 Jul 2026 13:54:03 +0000 Date: Tue, 28 Jul 2026 06:53:56 -0700 From: Breno Leitao To: Mike Rapoport Cc: Dave Hansen , Andy Lutomirski , Borislav Petkov , "Denis V . Lunev" , Ingo Molnar , Juergen Gross , Kiryl Shutsemau , "H. Peter Anvin" , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org, x86@kernel.org, Dave Hansen Subject: Re: [PATCH] x86/mm/pat: don't gate cpa_lock on debug_pagealloc_enabled() Message-ID: References: <20260715144519.934289-1-rppt@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260715144519.934289-1-rppt@kernel.org> X-Debian-User: leitao On Wed, Jul 15, 2026 at 05:45:19PM +0300, Mike Rapoport wrote: > @@ -1235,11 +1234,9 @@ static int split_large_page(struct cpa_data *cpa, pte_t *kpte, > { > struct ptdesc *ptdesc; > > - if (!debug_pagealloc_enabled()) > - spin_unlock(&cpa_lock); > + spin_unlock(&cpa_lock); > ptdesc = pagetable_alloc(GFP_KERNEL, 0); > - if (!debug_pagealloc_enabled()) > - spin_lock(&cpa_lock); > + spin_lock(&cpa_lock); A DEBUG_PAGEALLOC + KASAN kernel from linux-next-20260727 fails to finish booting on a large VM (many CPUs + large memory). Boot stalls in early userspace with a non-responsive CSD lock; it never reaches a login. I bisected it to this patch, which is the following on linux-next: 5fce67641a3e ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()") Reverting it (restoring the !debug_pagealloc_enabled() gating around cpa_lock) makes the same kernel boot reliably. Symptom ------- Boot hangs during udev coldplug (concurrent module loading, i.e. concurrent set_memory()). With csdlock_debug=1 the console shows: smp: csd: Detected non-responsive CSD lock (#1) on CPU#55, waiting 5000000019 ns for CPU#57 do_flush_tlb_all+0x0/0x30(0x0). smp: csd: CSD lock (#1) unresponsive. Sending NMI from CPU 55 to CPUs 57: NMI backtrace for cpu 57 CPU: 57 UID: 0 PID: 860 Comm: (udev-worker) Tainted: G E \ 7.2.0-rc5-next-20260727 #1 PREEMPT(full) RIP: 0010:queued_spin_lock_slowpath+0xae/0xd30 Call Trace: do_raw_spin_lock+0x268/0x2f0 __change_page_attr_set_clr+0x32d/0x21f0 ... CPU#55 is stuck in flush_tlb_all() waiting for CPU#57 to answer the IPI; CPU#57 is spinning on cpa_lock (RBX resolves to cpa_lock) inside __change_page_attr_set_clr(). The clocksource watchdog also reports remote CPUs timing out on the same IPIs just before this. Is this a known issue? --breno