* Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > On Wed, Mar 24, 2021 at 3:05 PM Marco Elver <elver@xxxxxxxxxx> wrote: > > > > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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
