From nobody Thu Apr 2 15:41:23 2026 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 F1F261B808 for ; Fri, 27 Mar 2026 15:46:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774626387; cv=none; b=Iuzz092P4rQvQTsT+aSc3vjyT8SkQZBnkCS9V/oW61CGgQUg7EOjNVm81LCbQyTL8euqfIMyJ7AAy+CEq9KPw4FtWA443Vsy10xfT3NM1w8wC2XMZ/9CMicQKLTnfjv0KXDuCv/0EDSCdg62RX4bgeY47BHCWphQF+bTQ2dAMY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774626387; c=relaxed/simple; bh=YBIhlKReXrIreTfD5YLePkJtLDJR8BUFlXqi+clCSAA=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=EacHcLpIicJuMZuu5G7g6XkDOv9hRVfYaSoZJhayF9rvCqV5IzoXbSiwkeITf+kss53O9t1XAqyC5bwMWT5zag4VsqD8ndZfwjmDL81kAKUCQcjDblSLBWQCf9i35N9GCccFvH/0R5KpDL/DdbLroV8xxlTurg+bH226Z55A13E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=bhdQoVtV; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="bhdQoVtV" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wWw+xPYgP3y/IHUcVkxDhksiYdYrZTcNx2JblqevQtQ=; b=bhdQoVtVA9H4hx+y6S9PTiZC/S LmQslYFewIukGxUNKeXUgRy7rn7BB0fBp+o7pT/sdzpAGx73iCs9LijCT7vz8CJrtpHMJYERApLLA kzE8sOp/X7gHKnpr2lRKmIkHY/J4Or5lLebuRk5vM9SRDQgopHzZUa0I9vtbf7gUsKv6DY+BIUBxY jADdGDRhXAmH1SSmtVbPCgOrCdvGUoA6berZlaG2yczD2xFRCgr4U+U2166BKuOVuWqhdrtzRM+6a R9pcUKSWh/gqH+kT+b9kRnh7jPL4dlBEdoeHLg8Br1YPLlMdGFzY++NkrwwStVuqF4YUEf/EOO9wS OxeLwg9w==; Received: from [2601:18c:8180:83cc::4801] (helo=fangorn) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1w69O3-000000003cm-1tDy; Fri, 27 Mar 2026 11:46:15 -0400 Date: Fri, 27 Mar 2026 11:46:13 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, kernel-team@meta.com, Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Dave Hansen , Borislav Petkov Subject: [PATCH] perf/x86/intel/ds: Fix loop ordering in release_ds_buffers() Message-ID: <20260327114613.6ee59737@fangorn> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.49; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" release_ds_buffers() has three loops: 1. release_ds_buffer() - NULLs hwev->ds for each CPU 2. fini_debug_store_on_cpu() - clears MSR_IA32_DS_AREA 3. release_pebs_buffer()/release_bts_buffer() - unmaps CEA pages and frees backing pages The problem is that fini_debug_store_on_cpu() checks if hwev->ds is NULL and returns early if so. Since loop 1 already NULLed hwev->ds, loop 2 never actually clears MSR_IA32_DS_AREA. Then loop 3 unmaps the CEA pages, leaving the MSR pointing at now-unmapped memory. When a PEBS overflow fires, the hardware writes to unmapped pages, causing page faults in random victim code. Fix by swapping the first two loops: clear MSR_IA32_DS_AREA first (while hwev->ds is still valid), then NULL hwev->ds, then unmap and free the CEA pages. Fixes: b00233b25080 ("perf/x86/intel/ds: Create separate buffer for CEA") Signed-off-by: Rik van Riel --- PS: this bug was discovered in automatic syzkaller runs, with AI running Chris Mason's /kdebug analysis on every crash found. I'm slowly working my way through the bug analyses, trying to come up with fixes. This one seemed simple and self contained=20 enough to just send it out. arch/x86/events/intel/ds.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index eb07fcb61a9b0..927efea37caf0 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -970,18 +970,18 @@ void release_ds_buffers(void) if (!x86_pmu.bts && !x86_pmu.ds_pebs) return; =20 - for_each_possible_cpu(cpu) - release_ds_buffer(cpu); - for_each_possible_cpu(cpu) { /* - * Again, ignore errors from offline CPUs, they will no longer + * Ignore errors from offline CPUs, they will no longer * observe cpu_hw_events.ds and not program the DS_AREA when * they come up. */ fini_debug_store_on_cpu(cpu); } =20 + for_each_possible_cpu(cpu) + release_ds_buffer(cpu); + for_each_possible_cpu(cpu) { if (x86_pmu.ds_pebs) release_pebs_buffer(cpu); --=20 2.52.0