From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 DCABF30568E for ; Tue, 28 Jul 2026 15:19:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785251953; cv=none; b=gd2nK5dLHN55ygvd77xaKk2kFkW100uBp1rd+8LQmRSenUS6sa+CkjRowBU1xYOg+V2PHOTneIHsKyBwR+FBEG+GUc2plIsyleMp85lxLJl1kMrfByVK+ibBSfAlVdlOhlmNmUmOlgea3RZnHck4zTU5IwDX51Vs5BERgyQDpvg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785251953; c=relaxed/simple; bh=TJjc66zgMc/Y+13J50tQp3bXGky340mBw79Y8S8QIWQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=c4EsY9a4AMysvdtv2obBaMsnfe25uL3TbkQPmwb/5GPfL67jUnq1csNLWJNmNEhGupZNN8VX2Wz4cTS3D3Uav/bB04N9Y1RyWOAgN6NOJ8U8u6i/8okh3oau2pkZo/1na3fetdz5FUjKYeyzrLPdlhwkVw4xmfAAuPPghZFXn54= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QP9fnMO1; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QP9fnMO1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEF321F000E9; Tue, 28 Jul 2026 15:19:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785251951; bh=VO1m2yMooeIbEVczwEIj/4yNFQyFmqjVKulkFU7OH9Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=QP9fnMO1BvxWDvb/sKe/E3AMmED0Y8nc+HJKzmUQFtiPIhz3ulx78KLvjk6NEKn3W U6eBCOr0rvaDO5h1FvLbfO++yj9qEIhMFcw2aS6dlKIvw7L6OuTHrRevFn87xzSmTP I7AyG7v+zeqFaZGcFYo9etMWajHLPWrxItqPQ9zWs7Qhj2GlpKSQYWN9dLxdNDso+b Ri957DMrQ+MCdhm+5ozoYY5D41hGkbjr53brV1gzolNAA/OYHjOEfNHSLvw686EC5i mEwkPTHgBeTE3mN39PL2rqge7uiKe9B2YqJ+z1jvE8Wl/BRDxvMEr2J4VlsXL1ahf2 oA+HVZCr2tmQw== Date: Tue, 28 Jul 2026 18:19:03 +0300 From: Mike Rapoport To: Breno Leitao 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: On Tue, Jul 28, 2026 at 06:53:56AM -0700, Breno Leitao wrote: > 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? Yes: https://lore.kernel.org/all/20260728-cpa-fixes-v1-0-2ed2352300b3@kernel.org > --breno -- Sincerely yours, Mike.