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.