Re: [PATCH v3 4/8] coresight: tmc-etr: Prevent per-thread events from sharing a sink

On 13/08/2026 17:05, Leo Yan wrote:
> On Tue, Jul 28, 2026 at 04:00:16PM +0100, James Clark wrote:
> 
> [...]
> 
>> The identity and compatibility of a session are determined by the owning
>> process, the target process, and the inheritance settings together.
> 
> Could you elaborate a bit on the session model you are trying to support
> here?
> 
> My understanding of a legacy sink such as ETR/ETF is that it can be
> owned by only one perf session at a time. Multiple events belonging to
> that session may use the sink, but an attempt from another perf session
> should be rejected with -EBUSY.
> 
> For per-thread mode, I wonder if we could support _only_ non-inherited

non-inheritance is enforced for per-thread mode in the perf core. So we 
already don't support it.

> events. In that case, we would not need to determine compatibility based
> on the target process and inheritance settings.
> 
>  From the patch, it seems trying to support a more flexible model, where

I don't think so. It's actually less flexible than what exists 
currently. Currently we only check the PID of the owner, and all sharing 
is allowed. That means there are a lot of combinations of things that 
result in sharing that are invalid. For example PID re-use and 
incompatible per-thread events, like the original bug.

> an already active legacy sink can also be shared by another perf session

There isn't any sharing with "another perf session", unless there is a 
mistake somewhere? Checking that the owners are equivalent enforces 
this. Or do you mean another event owned by the same process?

> and also support inherit mode for child events?
> 
> Thanks,
> Leo

We need to fix the bugs but still support one process owning multiple 
PERF_ATTACH_TASK events, because that's what you get when you do this:

   perf record -e cs_etm// -- my_task

Perf doesn't do one per-thread event here, it's is still 
PERF_ATTACH_TASK, but with a separate event opened for each CPU. So we 
need a model that still supports this to not cause a regression, but 
doesn't have any sharing bugs.

I'm not sure the exact model you had in mind was that still supports 
this and fixes the bugs? The one in this change is pretty complete and 
only does 4 comparisons, which seems quite simple to me. It only has one 
shortcoming that I'm aware of, that it doesn't take into account the 
cgroup settings, but I don't see a use case where that needs to be 
solved. Even if different events with different cgroup settings should 
would follow different processes, the owning process would have to do 
something quite crazy to get there.