linux-kernel - Re: [PATCH bpf-next v8 1/3] perf: Add rctx in perf_callchain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <459af099-540f-4ce3-945e-fdf38896d03c@linux.dev>
Date: Thu, 29 Jan 2026 11:03:02 +0800
From: Tao Chen <chen.dylane@...ux.dev>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com, acme@...nel.org,
 namhyung@...nel.org, mark.rutland@....com,
 alexander.shishkin@...ux.intel.com, jolsa@...nel.org, irogers@...gle.com,
 adrian.hunter@...el.com, kan.liang@...ux.intel.com, song@...nel.org,
 ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
 martin.lau@...ux.dev, eddyz87@...il.com, yonghong.song@...ux.dev,
 john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
 haoluo@...gle.com, linux-perf-users@...r.kernel.org,
 linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v8 1/3] perf: Add rctx in perf_callchain_entry

在 2026/1/29 02:59, Andrii Nakryiko 写道:
> On Wed, Jan 28, 2026 at 8:53 AM Tao Chen <chen.dylane@...ux.dev> wrote:
>>
>> 在 2026/1/28 16:59, Peter Zijlstra 写道:
>>> On Mon, Jan 26, 2026 at 03:43:29PM +0800, Tao Chen wrote:
>>>> Record rctx inside the perf_callchain_entry itself, when callers of
>>>> get_callchain_entry no longer care about the assignment of rctx, and
>>>> will be used in the next patch.
>>>
>>> Sorry, what?
>>>
>>> The recursion context is very much about the caller, and very much not
>>> about the data. This just doesn't make sense.
>>
>> Well, Andrii, it seems we have to go back to the original way.
> 
> Huh, why? Peter is confused by your wording, he didn't say that what
> you are doing is broken.
>

I see, will update the changelog, thanks.
> The point is to couple rctx with the exact perf_callchain_entry
> returned to the caller in that recursion context. There is no
> contradiction.
> 
> It's purely about simplifying the interface. While previously the
> caller would have to juggle perf_callchain_entry and rctx separately
> (but still ensure that entry and rctx do match each other when calling
> put_callchain_entry), now it's more convenient and less error-prone
> because returned entry will record rctx it was retrieved with.
> 
> That perf_callchain_entry should not be reused by anyone else between
> successful get_callchain_entry and put_callchain_entry, so there is no
> problem here.
> 
>>
>> --
>> Best Regards
>> Tao Chen


-- 
Best Regards
Tao Chen