* 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?
Thanks,
Ingo