From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DB19C4A3A68; Thu, 8 Jan 2026 14:02:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767880957; cv=none; b=p02SUFzrCkI/jtH9WHBziaH97yMY0RkBxm2PY7GlEAocPAgD/3VjzCbqL0WCZFBST18F2asVN6z2Z8P6hT/tQ2BoG3szj6QI21ON9fyZQBV+XyYWD4TU7EM00rIhmm3Uf9xaJHqtJ4dyhsveanLhnf2hHxuuZcL84ZpwNesni38= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767880957; c=relaxed/simple; bh=/7wHh03YhaOtFfjZCYGUPqn0HgKaPyuACzUAPG/AE2A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XOMOrOTXEb6imGARei8pE6xVQ5f5TyiAFlV+uvoYqgqEN6HDUOxSau+bbssMJp0EptBQfYmwbni5vLg8rp7zCXVYERmE8yRCO2Rw3WibXCw8lW4FXswAZl6zfESiSpPlCBdIzYyh8eif5UI8xE67W3h20bIX5RKfuyCLIvNcdq8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=00GzxAMj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="00GzxAMj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9A9BC116C6; Thu, 8 Jan 2026 14:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1767880956; bh=/7wHh03YhaOtFfjZCYGUPqn0HgKaPyuACzUAPG/AE2A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=00GzxAMjgNrhsxCZo0EtcB6q020utaPpkEFLLcVazeaucsGGb3N3GOWl2XSrCoFZo FmtinC7s2xT4j9rwIlkgv1RzXW5yAw2j61Swev31+n4jmVvYOJ5bNcOu504nFWkO87 oa4txM4EFfofgQSUeG2lLuyeA23SALOJlLOnO1MM= Date: Thu, 8 Jan 2026 15:02:33 +0100 From: Greg KH To: Leon Hwang Cc: stable@vger.kernel.org, Andrii Nakryiko , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, "H . Peter Anvin" , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6.6.y 0/4] perf/x86/amd: add LBR capture support outside of hardware events Message-ID: <2026010856-ethics-lethargic-b9e9@gregkh> References: <20260102090320.32843-1-leon.hwang@linux.dev> <2026010809-matchless-reporter-3129@gregkh> <72a635cb-05c7-47d2-84aa-4d82d1e0aebd@linux.dev> Precedence: bulk X-Mailing-List: stable@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: <72a635cb-05c7-47d2-84aa-4d82d1e0aebd@linux.dev> On Thu, Jan 08, 2026 at 09:53:46PM +0800, Leon Hwang wrote: > > > On 2026/1/8 19:11, Greg KH wrote: > > On Fri, Jan 02, 2026 at 05:03:16PM +0800, Leon Hwang wrote: > >> Hi all, > >> > >> This backport wires up AMD perfmon v2 so BPF and other software clients > >> can snapshot LBR stacks on demand, similar to the Intel support > >> upstream. The series keeps the LBR-freeze path branchless, adds the > >> perf_snapshot_branch_stack callback for AMD, and drops the > >> sampling-only restriction now that snapshots can be taken from software > >> contexts. > >> > >> Leon Hwang (4): > >> perf/x86/amd: Ensure amd_pmu_core_disable_all() is always inlined > >> perf/x86/amd: Avoid taking branches before disabling LBR > >> perf/x86/amd: Support capturing LBR from software events > >> perf/x86/amd: Don't reject non-sampling events with configured LBR > > > > > > Why is this for a stable kernel? Isn't it a new feature? If you need > > this feature, why not use a newer kernel tree? > > > > This series enables LBR snapshot support on AMD CPUs. > > You are right that this is not a bug fix but a feature enablement. > If backporting this to the stable tree is not appropriate, that is > totally fine. In that case, I will carry these changes in our in-house > stable kernel instead. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html For what types of patches are acceptable for stable kernels. And really, you should be moving off of 6.6.y now anyway :) thanks, greg k-h