* Dmitry Vyukov <dvyu...@google.com> wrote:
> On Wed, Mar 24, 2021 at 3:05 PM Marco Elver <el...@google.com> wrote:
> >
> > On Wed, 24 Mar 2021 at 15:01, Peter Zijlstra <pet...@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
