On Thu, 25 Mar 2021 at 15:18, Ingo Molnar mingo@kernel.org wrote:
- Dmitry Vyukov dvyukov@google.com wrote:
On Wed, Mar 24, 2021 at 3:05 PM Marco Elver elver@google.com wrote:
On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra peterz@infradead.org wrote:
One last try, I'll leave it alone now, I promise :-)
This looks like it does what you suggested, thanks! :-)
I'll still need to think about it, because of the potential problem with modify-signal-races and what the user's synchronization story would look like then.
I agree that this looks inherently racy. The attr can't be allocated on stack, user synchronization may be tricky and expensive. The API may provoke bugs and some users may not even realize the race problem.
Yeah, so why cannot we allocate enough space from the signal handler user-space stack and put the attr there, and point to it from sig_info?
The idea would be to create a stable, per-signal snapshot of whatever the perf_attr state is at the moment the event happens and the signal is generated - which is roughly what user-space wants, right?
I certainly couldn't say how feasible this is. Is there infrastructure in place to do this? Or do we have to introduce support for stashing things on the signal stack?
From what we can tell, the most flexible option though appears to be
just some user settable opaque data in perf_event_attr, that is copied to siginfo. It'd allow user space to store a pointer or a hash/key, or just encode the relevant information it wants; but could also go further, and add information beyond perf_event_attr, such as things like a signal receiver filter (e.g. task ID or set of threads which should process the signal etc.).
So if there's no strong objection to the additional field in perf_event_attr, I think it'll give us the simplest and most flexible option.
Thanks, -- Marco
Thanks,
Ingo