From nobody Tue Sep 29 08:22:34 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 C4CCC2EB5B8; Mon, 10 Aug 2026 13:35:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368950; cv=none; b=L/rCxo3PVIe0xsOtXSAjWE4fGf39S+jCXmU2Z4xI99EWxgYeKtNFpI3gKmMte21NkMV5PLWKqJ56U2LMGwMS2JOUG4MBayNU6yISfqdLcWUJavMGX1udR5ps55Buw72RhRMOCMFqWA1oK7nO0EoPYuFq5t78CiCTbMTIlenSVCY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368950; c=relaxed/simple; bh=R5gNkinJAQZpQHyvJ4gIHrE9rkfG9/HhjapIRjtSNmY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jpL6uRfySxnJ496g2EVMuc9IGNjHjpzZhpBAboKlZxcIGsCxbs4mM3/A+3dWBR9D0eCQNb6K33vCgkFGFZq0ieDm8udeIaVZFnzMdyLrEhnZkcPp/EENmSu8R5wzEZcU/tfa+CGVm4xttlpOtsQ3pQF0i4gHkUI63V2M1cgbKSM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X6sAuLM7; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X6sAuLM7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 609B91F000E9; Mon, 10 Aug 2026 13:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786368949; bh=gNT7bjfQ5ypnw0lOWzF1yyyxocddeiAffZrZpT0iW/c=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=X6sAuLM7PSbNKjIqL5Inn5dbxuj6R3Jjv4N9KexgPyTH/woXMpcvOw9bjRRHqNkS5 Ak5ID5Pl9iAEMcp07Y+K6+UHahvFTFJMIQpZyd+jPUrn+GttdTFz7zPIiS0RLgerZU Srh7e9TR9+6wneRLif7eiTv3xBp09puNC+fHTtryjGK4WIjxEroVHRJFnUmgt5vQSz i0AciJNQbSNH3gteOgkLq4MbgsbXDjMvgLoUx3muvky00oEJ7VmKyXKMnogPjJlFLM 7r0gbDzwQHXpuFGFLVi0nS4Gq2OxA72jiGmMIBfez+IsSodTzDSGts8IOjyV6p88SJ 7nE+UlO3R1KmQ== From: Puranjay Mohan To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim Cc: Puranjay Mohan , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Usama Arif , Will Deacon , Anshuman Khandual , Ravi Bangoria , Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v7 1/3] perf/core: Fix NULL pmu_ctx passed to pmu->sched_task() Date: Mon, 10 Aug 2026 06:35:34 -0700 Message-ID: <20260810133540.1947118-2-puranjay@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260810133540.1947118-1-puranjay@kernel.org> References: <20260810133540.1947118-1-puranjay@kernel.org> 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" perf_pmu_sched_task() returns early when cpuctx->task_ctx is set, and cpc->task_epc is only non-NULL while a task context is scheduled in on this CPU. __perf_pmu_sched_task() therefore always passes NULL: Unable to handle kernel NULL pointer dereference at virtual address 00 pc : armv8pmu_sched_task+0x14/0x50 Call trace: armv8pmu_sched_task+0x14/0x50 (P) perf_pmu_sched_task+0xac/0x108 __perf_event_task_sched_out+0x6c/0xe0 Pass &cpc->epc instead, the CPU-wide context for this PMU, which the function already dereferences a few lines up to find pmu. armv8pmu_sched_task() is the only in-tree implementation that dereferences the argument, and it only reads ->pmu, so the oops needs BRBE, added in v6.17. Fixes: bd2756811766 ("perf: Rewrite core context handling") Cc: stable@vger.kernel.org Signed-off-by: Puranjay Mohan Tested-by: Yifan Wu --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 4638544205f28..05635217696c2 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -3907,7 +3907,7 @@ static void __perf_pmu_sched_task(struct perf_cpu_pmu= _context *cpc, perf_ctx_lock(cpuctx, cpuctx->task_ctx); perf_pmu_disable(pmu); =20 - pmu->sched_task(cpc->task_epc, task, sched_in); + pmu->sched_task(&cpc->epc, task, sched_in); =20 perf_pmu_enable(pmu); perf_ctx_unlock(cpuctx, cpuctx->task_ctx); --=20 2.53.0-Meta From nobody Tue Sep 29 08:22:34 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 61E143E0096; Mon, 10 Aug 2026 13:35:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368955; cv=none; b=AAfZqT474HVzkzeTmsFbvbc84VuAPoOq63PMl0+VhTez52whSuEkOT+5OEDCuFJ7EAejKXoeH0uFZ/bjECu5ytNCE/Zz5qgxQm4LmKDUOj1FJhyokM6iIXe767utBJZIKYtpDe12wlsioYHAIuqBPNZbh/403G701xTkGGXAXsg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368955; c=relaxed/simple; bh=EgSOJGmrrtDIwoONebb2VWePpMr0xPNQX6dcGwPtH1Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EP/Y44fGs2BptRrZ+EmCDP3+0ff/0YMw6+gIscaeuaceo1P0IfxwappAIKaTd9947y8G9c7OTHU6EVyhHZEZWqrPdBNUeyuFMYFxTqm1zXeVbd4fTUWLo2genzIvv/hY78VgkkhULcFzGoTU04wkkd1K7r7t5ONv7AiR0qEcgjY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fA6+rlWx; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fA6+rlWx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD2341F000E9; Mon, 10 Aug 2026 13:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786368954; bh=utuvlWj153YehjtmXoJH+cLSsBfPwLyLld+tIz5367I=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=fA6+rlWx9MznANhijGPEQXzbpI+LfE4qbpQQzwavQcB45kKtouBfKT5U9NOxNwiiv zU8TntJjpdOWZiPYDOBnphwZgS3LsNYyjIiiFeU7o7kmYZrKgUa0BR0SDgMYiKa8Ik HBTgYwWgNtUwhBoR5iETKkE3/Bleroy4htu44CaW5JR4yLIlc0Ixwb0Ecgt2pyiKTG PIoEh7rHabI5Y+BS3Wh77wgGVMRmB1wP222iPgsfAEEaxRckTCq8GE/vb/owHcKSbQ 76biHZgc4hv+CKXusKGQWmL1Fp3yBsD39NI8u5TvECj50IV4aivyfG9QuZudT3CEAi z813PvehqSf5w== From: Puranjay Mohan To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim Cc: Puranjay Mohan , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Usama Arif , Will Deacon , Anshuman Khandual , Ravi Bangoria , Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v7 2/3] perf/core: Run sched_task() for PMUs with only CPU-wide events Date: Mon, 10 Aug 2026 06:35:35 -0700 Message-ID: <20260810133540.1947118-3-puranjay@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260810133540.1947118-1-puranjay@kernel.org> References: <20260810133540.1947118-1-puranjay@kernel.org> 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" perf_pmu_sched_task() returns early when cpuctx->task_ctx is set and leaves the work to perf_ctx_sched_task_cb(), which only walks ctx->pmu_ctx_list. A PMU whose events are all CPU-wide is not on that list, so nothing calls its sched_task(). With perf record -b -e cycles -a -- ls armv8pmu_sched_task() is skipped on every switch to a task that has a perf context but no event on that PMU, and BRBE records leak across the task boundary. intel_pmu_lbr_add() calls perf_sched_cb_inc() unconditionally too, so LBR records leak the same way on x86. Drop the early return and skip only the CPCs that perf_ctx_sched_task_cb() handles. That one needs a gate of its own to make the split exact: it tests cpc->sched_cb_usage, which perf_sched_cb_inc() sets per CPU for every branch stack user, so a task with an event for that PMU pinned to another CPU would be handled twice. On x86 the second __intel_pmu_lbr_restore() finds lbr_stack_state =3D=3D LBR_NONE and calls intel_pmu_lbr_reset(), throwing away the callstack the first one restored. cpc->task_epc is set only while a task context is scheduled in, and there is one epc per PMU on ctx->pmu_ctx_list, so the two gates are inverses. For the CPCs perf_pmu_sched_task() picks up, the callback now runs outside the perf_ctx_disable() and perf_ctx_enable() pair in perf_event_context_sched_in(). __perf_pmu_sched_task() disables the PMU around the call itself. Fixes: bd2756811766 ("perf: Rewrite core context handling") Cc: stable@vger.kernel.org Signed-off-by: Puranjay Mohan Tested-by: Yifan Wu --- kernel/events/core.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 05635217696c2..34eb05e9d74d0 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -3757,6 +3757,9 @@ static void perf_ctx_sched_task_cb(struct perf_event_= context *ctx, list_for_each_entry(pmu_ctx, &ctx->pmu_ctx_list, pmu_ctx_entry) { cpc =3D this_cpc(pmu_ctx->pmu); =20 + if (cpc->task_epc !=3D pmu_ctx) + continue; + if (cpc->sched_cb_usage && pmu_ctx->pmu->sched_task) pmu_ctx->pmu->sched_task(pmu_ctx, task, sched_in); } @@ -3917,15 +3920,17 @@ static void perf_pmu_sched_task(struct task_struct = *prev, struct task_struct *next, bool sched_in) { - struct perf_cpu_context *cpuctx =3D this_cpu_ptr(&perf_cpu_context); struct perf_cpu_pmu_context *cpc; =20 - /* cpuctx->task_ctx will be handled in perf_event_context_sched_in/out */ - if (prev =3D=3D next || cpuctx->task_ctx) + if (prev =3D=3D next) return; =20 - list_for_each_entry(cpc, this_cpu_ptr(&sched_cb_list), sched_cb_entry) + list_for_each_entry(cpc, this_cpu_ptr(&sched_cb_list), sched_cb_entry) { + if (cpc->task_epc) + continue; + __perf_pmu_sched_task(cpc, sched_in ? next : prev, sched_in); + } } =20 static void perf_event_switch(struct task_struct *task, --=20 2.53.0-Meta From nobody Tue Sep 29 08:22:34 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 86FE03E3159; Mon, 10 Aug 2026 13:35:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368959; cv=none; b=PJ1NkRecZDorD82h3Pw478zyqIDvUVjY7V8Ngkt4hUn0hAGAyeej9sG9bzcIj27fc36zu6gqj3PjizUdH62m2xv5oy36TPF1XlP45t4vu2bbNJmKDghCXmO+/BPJJwuaBA8LG+Uid5l87PngCfe5izzg00FNYjFjmfbrWjhF/DU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786368959; c=relaxed/simple; bh=O8IjTvx7ifftU2TvVuTVQDB1ccGcZuEgUJtDUCq73so=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=g1UDoaHk+oAN1Om4FqgyIJk0rj6fQ3xTlEd+AM4mazoic85XMd/Y4dqC8vzFK6stz7Ji9ujJAUzxgvqOMV4fYqjRI+yAN/BiFnk+PoiWNPNkjjrNmgAbtG3fFXU4Grn8DtcWMto3l+R/takySpAtnsb5LPKHAWAe2e4bMCPp6ws= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T4vhV/b0; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T4vhV/b0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35B2E1F000E9; Mon, 10 Aug 2026 13:35:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786368957; bh=hFHU+itqilLFa2LW0TtwgKnJ6JyHbm/bvFBqWleVcaQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=T4vhV/b0nCCPFZdxOdMKj8mLQsh5U7ab1MRrcw7L0WVBcQHZnHZz0nN4rFe7Ob8wh rUfUn7rFK4T/fWbLJynD9pFEnSgUAjO+Cntd/9xkrRjG4UJu7zgI2Qi9flHLTP/Y4M 3mRATErduz+Tat/u/n1GLiphCpEACk89Jn8hmYFaNHcRq0Lo3D8ClL+MUWZG/PUvra 8sJbQVLBPat1wGl0tHbl53NdqYxEfnZQZRNrD0PIQUjcJKPR3XG3gLVXnoPk2SBnt6 98XGgONqvKeSdB2lRlo2rXS6SesDbsblbrblCaB8GFY1fzdH3QlereB3PBCbaSHD19 9qCXnfJekK6pw== From: Puranjay Mohan To: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim Cc: Puranjay Mohan , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Usama Arif , Will Deacon , Anshuman Khandual , Ravi Bangoria , Thomas Gleixner , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v7 3/3] perf/core: Fill branch entries with a single assignment Date: Mon, 10 Aug 2026 06:35:36 -0700 Message-ID: <20260810133540.1947118-4-puranjay@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260810133540.1947118-1-puranjay@kernel.org> References: <20260810133540.1947118-1-puranjay@kernel.org> 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" perf_clear_branch_entry_bitfields() clears the bitfields of struct perf_branch_entry one by one and leaves from/to alone, since callers overwrite those straight away. The list has to be kept in sync with the struct by hand and has already fallen behind: new_type and priv were added to perf_branch_entry and never added here. Only BRBE writes those two, and neither for every record. brbe_set_perf_entry_type() leaves new_type alone for a branch type it does not recognise, and priv is not set for source-only records. arm_pmuv3.c allocates the per-CPU branch stack with kmalloc(), so such a record reaches userspace with whatever the slot held: uninitialised kmalloc() data on the first pass over the buffer, the previous record's values after that. Nothing under arch/x86/events/ writes either field, so only arm64 is affected. Assign the whole entry at each site instead. Everything not named is then zero, and there is no list to keep in sync. The bitfields add up to exactly 64 bits, so the struct has no padding to leave undefined. perf_clear_branch_entry_bitfields() has no callers left, so remove it. perf_entry_from_brbe_regset() assigns an empty literal instead, since it fills from/to conditionally. PERF_BR_SPEC_NA is 0, so dropping the explicit spec assignment changes nothing. Fixes: b190bc4ac9e6 ("perf: Extend branch type classification") Fixes: 5402d25aa571 ("perf: Capture branch privilege information") Suggested-by: Peter Zijlstra Signed-off-by: Puranjay Mohan Tested-by: Yifan Wu --- arch/x86/events/amd/brs.c | 9 +++-- arch/x86/events/amd/lbr.c | 16 ++++----- arch/x86/events/intel/lbr.c | 65 ++++++++++++++++++++----------------- drivers/perf/arm_brbe.c | 2 +- include/linux/perf_event.h | 17 ---------- 5 files changed, 48 insertions(+), 61 deletions(-) diff --git a/arch/x86/events/amd/brs.c b/arch/x86/events/amd/brs.c index dc564688f3d73..54b13faba116c 100644 --- a/arch/x86/events/amd/brs.c +++ b/arch/x86/events/amd/brs.c @@ -343,11 +343,10 @@ void amd_brs_drain(void) if (!amd_brs_match_plm(event, from, to)) continue; =20 - perf_clear_branch_entry_bitfields(br+nr); - - br[nr].from =3D from; - br[nr].to =3D to; - + br[nr] =3D (struct perf_branch_entry){ + .from =3D from, + .to =3D to, + }; nr++; } empty: diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c index 9d9c961989d51..a55646fcb8465 100644 --- a/arch/x86/events/amd/lbr.c +++ b/arch/x86/events/amd/lbr.c @@ -184,13 +184,6 @@ void amd_pmu_lbr_read(void) entry.to.split.reserved) continue; =20 - perf_clear_branch_entry_bitfields(br + out); - - br[out].from =3D sign_ext_branch_ip(entry.from.split.ip); - br[out].to =3D sign_ext_branch_ip(entry.to.split.ip); - br[out].mispred =3D entry.from.split.mispredict; - br[out].predicted =3D !br[out].mispred; - /* * Set branch speculation information using the status of * the valid and spec bits. @@ -208,7 +201,14 @@ void amd_pmu_lbr_read(void) * speculative and took the correct path */ idx =3D (entry.to.split.valid << 1) | entry.to.split.spec; - br[out].spec =3D lbr_spec_map[idx]; + + br[out] =3D (struct perf_branch_entry){ + .from =3D sign_ext_branch_ip(entry.from.split.ip), + .to =3D sign_ext_branch_ip(entry.to.split.ip), + .mispred =3D entry.from.split.mispredict, + .predicted =3D !entry.from.split.mispredict, + .spec =3D lbr_spec_map[idx], + }; out++; } =20 diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c index f8fadb0b16a45..0a9b34261ebe3 100644 --- a/arch/x86/events/intel/lbr.c +++ b/arch/x86/events/intel/lbr.c @@ -756,10 +756,10 @@ void intel_pmu_lbr_read_32(struct cpu_hw_events *cpuc) =20 rdmsrq(x86_pmu.lbr_from + lbr_idx, msr_lastbranch.lbr); =20 - perf_clear_branch_entry_bitfields(br); - - br->from =3D msr_lastbranch.from; - br->to =3D msr_lastbranch.to; + *br =3D (struct perf_branch_entry){ + .from =3D msr_lastbranch.from, + .to =3D msr_lastbranch.to, + }; br++; } cpuc->lbr_stack.nr =3D i; @@ -847,14 +847,15 @@ void intel_pmu_lbr_read_64(struct cpu_hw_events *cpuc) if (abort && x86_pmu.lbr_double_abort && out > 0) out--; =20 - perf_clear_branch_entry_bitfields(br+out); - br[out].from =3D from; - br[out].to =3D to; - br[out].mispred =3D mis; - br[out].predicted =3D pred; - br[out].in_tx =3D in_tx; - br[out].abort =3D abort; - br[out].cycles =3D cycles; + br[out] =3D (struct perf_branch_entry){ + .from =3D from, + .to =3D to, + .mispred =3D mis, + .predicted =3D pred, + .in_tx =3D in_tx, + .abort =3D abort, + .cycles =3D cycles, + }; out++; } cpuc->lbr_stack.nr =3D out; @@ -905,6 +906,7 @@ static void intel_pmu_store_lbr(struct cpu_hw_events *c= puc, struct perf_branch_entry *e; struct lbr_entry *lbr; u64 from, to, info; + bool mispred; int i; =20 for (i =3D 0; i < x86_pmu.lbr_nr; i++) { @@ -921,24 +923,27 @@ static void intel_pmu_store_lbr(struct cpu_hw_events = *cpuc, to =3D rdlbr_to(i, lbr); info =3D rdlbr_info(i, lbr); =20 - perf_clear_branch_entry_bitfields(e); - - e->from =3D from; - e->to =3D to; - e->mispred =3D get_lbr_mispred(info); - e->predicted =3D !e->mispred; - e->in_tx =3D !!(info & LBR_INFO_IN_TX); - e->abort =3D !!(info & LBR_INFO_ABORT); - e->cycles =3D get_lbr_cycles(info); - e->type =3D get_lbr_br_type(info); - - /* - * Leverage the reserved field of cpuc->lbr_entries[i] to - * temporarily store the branch counters information. - * The later code will decide what content can be disclosed - * to the perf tool. Pleae see intel_pmu_lbr_counters_reorder(). - */ - e->reserved =3D (info >> LBR_INFO_BR_CNTR_OFFSET) & LBR_INFO_BR_CNTR_FUL= L_MASK; + mispred =3D get_lbr_mispred(info); + + *e =3D (struct perf_branch_entry){ + .from =3D from, + .to =3D to, + .mispred =3D mispred, + .predicted =3D !mispred, + .in_tx =3D !!(info & LBR_INFO_IN_TX), + .abort =3D !!(info & LBR_INFO_ABORT), + .cycles =3D get_lbr_cycles(info), + .type =3D get_lbr_br_type(info), + /* + * Leverage the reserved field of + * cpuc->lbr_entries[i] to temporarily store the + * branch counters information. The later code will + * decide what content can be disclosed to the perf + * tool. Pleae see intel_pmu_lbr_counters_reorder(). + */ + .reserved =3D (info >> LBR_INFO_BR_CNTR_OFFSET) & + LBR_INFO_BR_CNTR_FULL_MASK, + }; } =20 cpuc->lbr_stack.nr =3D i; diff --git a/drivers/perf/arm_brbe.c b/drivers/perf/arm_brbe.c index ba554e0c846c4..254be4da8ae29 100644 --- a/drivers/perf/arm_brbe.c +++ b/drivers/perf/arm_brbe.c @@ -604,7 +604,7 @@ static bool perf_entry_from_brbe_regset(int index, stru= ct perf_branch_entry *ent return false; =20 brbinf =3D bregs.brbinf; - perf_clear_branch_entry_bitfields(entry); + *entry =3D (struct perf_branch_entry){ }; if (brbe_record_is_complete(brbinf)) { entry->from =3D bregs.brbsrc; entry->to =3D bregs.brbtgt; diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 48d851fbd8ea5..310681cccb50a 100644 --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -1467,23 +1467,6 @@ static inline u32 perf_sample_data_size(struct perf_= sample_data *data, return size; } =20 -/* - * Clear all bitfields in the perf_branch_entry. - * The to and from fields are not cleared because they are - * systematically modified by caller. - */ -static inline void perf_clear_branch_entry_bitfields(struct perf_branch_en= try *br) -{ - br->mispred =3D 0; - br->predicted =3D 0; - br->in_tx =3D 0; - br->abort =3D 0; - br->cycles =3D 0; - br->type =3D 0; - br->spec =3D PERF_BR_SPEC_NA; - br->reserved =3D 0; -} - extern void perf_output_sample(struct perf_output_handle *handle, struct perf_event_header *header, struct perf_sample_data *data, --=20 2.53.0-Meta