On 10/23/20 10:23 AM, Peter Zijlstra wrote:
On Fri, Oct 23, 2020 at 09:49:53AM +0100, Suzuki Poulose wrote:
On 10/23/20 8:39 AM, Peter Zijlstra wrote:
So then I don't understand the !->owner issue, that only happens when
the task dies, which cannot be concurrent with event creation. Are you
Part of the patch from Sai, fixes this by avoiding the dereferencing
after event creation (by caching it). But the kernel events needs
fixing.
One follow up question on the !->owner issue. Given the ->owner is
dying, does it prevent events from being scheduled ? Or is there a delay
between that and eventually stopping the events. In this case, we hit
the issue when :
A A or B ?
event_start()
... event->owner = NULL
READ_ONCE(event->owner);
Is this expected ?
Yeah, teardown is a bit of an effort. Also, you can pass an fd over a
unix socket to another process, so this isn't something you can rely on
in any case.
The perf tool doesn't do it, but the kernel infra should be able to deal
with someone doing a perf-deamon of sorts, where you can request a perf
event and recieve a fd from it.
Imagine the fun ;-)
As for the kernel events.. why do you care about the actual task_struct
* in there? I see you're using it to grab the task-pid, but how is that
useful?
Correct, kernel events are something that the driver didn't account for.
May be we could handle this case with a "special pid" and simply
disallow sharing (which is fine I believe, given there are not grouping
for the kernel created events).
Why do you need a pid in the first place? Can't you use the "task_struct
*" as a value?
We could. But, without a refcount on the task pointer, that could be
tricky, even though we don't dereference it. In the same situation,
if the tsk owner dies and is freed and is reallocated to a new perf
session task but with different PID, we could be mixing things up again
?
Special pid here could be -1.
