From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=198.175.65.17 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793605258; b=pH6R8AscsNey362q6U8g3hQOdNH1SdV4BX8NlNvEndTW3c0H3pBXtdyBWhvPsLTWzAs8 aY+J3y6nXkNLRYWvvlCRUuw61zsO5A1lB6zYykbgN/CXRlV8GiPpicymrNLD+9Cp42Sga MWHlWTISLTwC6ea4fZWHomLJG2qWxdZJiZRJlCDfpXXi4fxVLtv5S34xiBmjOirxHDvvU SoXN5SXMU+Jvx+Z40U5yiRaJOpP3Ki8D39eix/hBlxgcAPnHiOPt47riqrpEffmphIZLl q6hfA1UA8KhiWpYBBzumZCPqBE+nGsgX9DQ7EmcWhuW1JJTcJ/oHVLMEilvSQXQ63UA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793605258; h=DMARC-Filter:DKIM-Signature:X-CSE-ConnectionGUID:X-CSE-MsgGUID: X-IronPort-AV:X-IronPort-AV:Received:X-CSE-ConnectionGUID: X-CSE-MsgGUID:X-ExtLoop1:X-IronPort-AV:Received:From:To:Cc:Subject: Date:Message-ID:X-Mailer:MIME-Version:Organization: Content-Transfer-Encoding; bh=CPhb8czvE9Xdht7fm0n0ri1ZxL1wovm/GrL4+C+wKVA=; b=kVvZD2N640AdIhI7R3P8LVAQnQaQ0um29+TgIjO6bppDb8A3QO1Sq2bG2JM8+xPHvm9s VU6SivV+25pS5UFsaTJZHve3zlvYMZSc2KNp1wF2THA3kQ6058gRlUVwzIcVhyFY6J0W8 X9YfXyINtATtpvNR4C/zVXmYuk2wRKBs277KOgmuRO42AK/CT+UxDDn2ERSJY3xK/TRwr +3eH1cjCxctt0JaZe9USmE/6wADtlbKXfs5IhQmTu5ND/IeJ2pnM5/2SbWVWLtUh2PZjj 9D0AtE3Odt8B5uRDBkxtLzz+jNSMEg5Khu3kfoMNsOkvo90++W31mZbv17OQz22LIPg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=aXqFrP0N; arc=none smtp.remote-ip=198.175.65.17 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40E13606A32C for ; Mon, 2 Nov 2026 07:40:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 40E13606A32C Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=aXqFrP0N DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1793605256; x=1825141256; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=YxKlnEZUTR2lBbVDdyn5I7/hmP6Old/LuQJQLG4uhGI=; b=aXqFrP0Ny2WExkMr+U7Vo9YoOrKLwXbnoLcdPaWhMcjTSXQGtnM29fA2 zX/5N9OD192drdFT9xGqaguYZyofwQzr5998OgoPClP4cNswc27qWwv1p pCIEsnrTAZidtCDUhrR3zBSeGOUhC8TWjFN5RSOnTazLMMF8yix0vvdoM xkoIWVJuIG+yiTZEBizazH/KS//PiVqjQSZvjRPflJm38QctnPiNuOMc3 aOfRVRMBR4K+GmxoObmVV5xs2MW8YBK5Q3vuRSd2fYQ7NaMC2HpYaCopI llAGthYA8WilLoAQ/I7BHClRBZbQ/yI7tjUpN72Asbaw9T8ZgskILeaCE Q==; X-CSE-ConnectionGUID: 9DH2YAahSIytorRgiRNztg== X-CSE-MsgGUID: ftE25qG0T4KN2ozw8pQkrw== X-IronPort-AV: E=McAfee;i="6800,10657,11953"; a="2300060" X-IronPort-AV: E=Sophos;i="6.27,191,1787036400"; d="scan'208";a="2300060" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2026 23:40:54 -0800 X-CSE-ConnectionGUID: WRNMMPeXQQa6Ib0jPUhH1g== X-CSE-MsgGUID: FbAbFZLaTz+f8kzfidTMJQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,191,1787036400"; d="scan'208";a="6181954" Received: from pgcooper-mobl3.ger.corp.intel.com (HELO ahunter6-desk) ([10.245.244.189]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Nov 2026 23:40:47 -0800 From: Adrian Hunter To: Peter Zijlstra Cc: Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , James Clark , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , "Rafael J. Wysocki" , Pavel Machek , Greg Kroah-Hartman , Danilo Krummrich , Johan Hovold , Sebastian Andrzej Siewior , Mathieu Desnoyers , Jiayuan Chen , "Steven Rostedt (Google)" , "Vineeth Pillai (Google)" , Frederic Weisbecker , Andi Kleen , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, driver-core@lists.linux.dev Subject: [PATCH 0/6] perf/x86/intel/pt: Fix tracing across kexec, kdump and suspend Date: Mon, 2 Nov 2026 09:40:33 +0200 Message-ID: <20261102074039.26983-1-adrian.hunter@intel.com> X-Mailer: git-send-email 2.53.0 X-Mailing-List: driver-core@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Organization: Intel Finland Oy, Registered Address: c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Content-Transfer-Encoding: 8bit Hi Intel PT writes trace data directly to physical memory, so tracing must be stopped whenever the trace buffers or the hardware state describing them can no longer be relied on. This series fixes several cases where that does not currently happen: - tracing can survive kexec and kdump. After kexec, Intel PT continues writing into buffers configured by the old kernel, corrupting memory that the new kernel may have reused - suspend-related state loss can leave the driver's cached PT MSR state out of sync with hardware, allowing tracing to restart with reset output registers and corrupt memory (typically beginning at page 0) - races can leave TraceEn set in hardware after perf believes tracing has stopped, preventing tracing from being reliably disabled and potentially causing subsequent PT MSR accesses to #GP The fixes stop relying solely on perf's software state where it is not authoritative: TraceEn is cleared directly in hardware during shutdown and emergency-stop paths, tracing is prevented from restarting once shutdown begins, cached PT MSR state is invalidated whenever hardware state may have been lost, and active tracing is stopped and restarted across suspend on the CPU that remains online. The first patch is a general irq_work fix, not specific to Intel PT. It re-raises a lost irq_work self-interrupt after resume, preventing irq_work from remaining permanently pending if the interrupt state is lost across suspend. The final Intel PT suspend fix depends on it. All patches are marked for stable. The last patch also depends on commit 2e17bf3a469a ("perf/x86/intel/pt: Fix stop/start with no update") and its two preparatory patches. An alternative to the last patch would be for perf core to schedule out all active events from a syscore suspend callback, and schedule them back in from the syscore resume callback. That would be a more general change, but the last patch keeps the fix within the Intel PT driver. AI disclosure: all issues addressed by this series were identified using AI assistance, and AI was also used in development of the patches. Problems described with reproducer examples in the individual changelogs were reproduced and fixes validated. The race fixed by "perf/x86/intel/pt: Clear TraceEn in hardware in cpu_emergency_stop_pt()" was identified by analysis and has not been reproduced. Adrian Hunter (6): irq_work: Re-raise pending irq_work after system resume perf/x86/intel/pt: Stop tracing if VMXON has not yet happened perf/x86/intel/pt: Stop tracing at syscore shutdown perf/x86/intel/pt: Clear TraceEn in hardware in cpu_emergency_stop_pt() perf/x86/intel/pt: Reset stale MSR state on CPU start and resume perf/x86/intel/pt: Stop tracing across system suspend arch/x86/events/intel/core.c | 9 ++ arch/x86/events/intel/pt.c | 170 ++++++++++++++++++++++++++++++++++++-- arch/x86/events/intel/pt.h | 6 +- arch/x86/events/perf_event.h | 4 + arch/x86/include/asm/perf_event.h | 3 + arch/x86/power/cpu.c | 3 +- drivers/base/syscore.c | 10 +++ include/linux/irq_work.h | 2 + include/linux/perf_event.h | 6 -- kernel/irq_work.c | 12 +++ 10 files changed, 208 insertions(+), 17 deletions(-) base-commit: f96ebf32b3135db4c9eeb868e4cb98e5dfe79ac0 Regards Adrian