From mboxrd@z Thu Jan 1 00:00:00 1970 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-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 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; - 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); } + for_each_possible_cpu(cpu) + release_ds_buffer(cpu); + for_each_possible_cpu(cpu) { if (x86_pmu.ds_pebs) release_pebs_buffer(cpu); -- 2.52.0