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 ACB6B3A543F for ; Wed, 13 May 2026 15:43:42 +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=1778687024; cv=none; b=TVEQySSVvWUrw/D7Xa96TInwt6EoQBIPhGFoU5dFsWvQByePLP92I/M6c79A8vTd1S9TCJIvCN1xLuOdAEOYtEzOcwn6nm2NSi/vIym90xJ3zqTryiGZ0Vv2XOFt2R4BvX6po2QUzOvR4yGVd+ULkd85AjWBa5fkWSdUyu5lhv4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778687024; c=relaxed/simple; bh=deiZMSwM+g7GcRD8AnxpECwJh1BvDWlDx7A6t8P/bBw=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=BjefIGF7OrEBZwmmsYjlbP90QFF0TJZrpCKZ7j9Ot7pWuuugD2n29kh/uPdR//VnNYKbg73gOlN//jvG0ovIPJiu6Rxwgadz0vLFr9kVZ5/qpxyFkJlrIFHDl9uFllyAUcbmq3+ltY8eiYPDsqlmQlBKpsY5DYQe4WbFhX4+ZW0= 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=NnNOfwsJ; 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="NnNOfwsJ" 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=RYOWTzIgW42/5HJjHh+n84DxJ7KqSVKmLsvhBJVKsqY=; b=NnNOfwsJR81MS6d3IsePn/8qHQ U0xxTqrSiVG+v5c+xzHrrJdJz02+8qcbzzjp/aLotjTffY2++7VhbjixU1+/URDKXdnZn1hkLv0fy SGtp0AI9sB6In2T98QpIujQTp1Yxnz0aVIhbwbbkjgKeQ5UQ2tRlgQ2lhzqcyTSrkpwRr4iIWJZuS VSlVPlgnQfpQ+VagbxTPww2A6qO0chhHgxASSR3geYpyj/yr1scWjveso3nicbVd6X2wNyFg6D3+e 5rcErBr3lTzVNNcHy7f0RXex48kE6AT870gZEx8tI/CVxZeEAgG6CHD6tuY/6aH4GUfzWS2IhYTHU YlVUhrDw==; Received: from [2601:18c:8180:83cc:5a47:caff:fe78:8708] (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 1wNBkH-000000005i6-2ecf; Wed, 13 May 2026 11:43:37 -0400 Date: Wed, 13 May 2026 11:43:33 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: x86@kernel.org, kernel-team@meta.com, "Mi, Dapeng" , Peter Zijlstra , Ingo Molnar , Dave Hansen Subject: [PATCH] perf/x86/intel/ds: Fix loop ordering in release_ds_buffers() Message-ID: <20260513114333.7eff8a4c@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 calling fini_debug_store_on_cpu() BEFORE release_ds_buffer(), so the MSR is cleared while hwev->ds is still valid. Observed crash signature: BUG: unable to handle kernel paging request in __lookup_object CR2: fffffe00004b7028 (CEA range) RIP: __lookup_object+0x39 (cmp %rdi,%rax -- register-only, can't fault) Secondary: TASK stack guard page hit (recursive page fault overflow) Assisted-by: Claude:claude-opus-4.7 syzkaller Signed-off-by: Rik van Riel --- arch/x86/events/intel/ds.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 2abfeb4e2908..85894673f03b 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -973,18 +973,25 @@ 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 - * observe cpu_hw_events.ds and not program the DS_AREA when - * they come up. + * Clear MSR_IA32_DS_AREA BEFORE NULLing hwev->ds. + * fini_debug_store_on_cpu() checks hwev->ds and bails + * if it's NULL, so calling release_ds_buffer() first + * would prevent the MSR from being cleared. That leaves + * the hardware writing into CEA pages that get unmapped + * below, causing asynchronous page faults at random RIPs. + * + * 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.53.0-Meta