* Marco Elver <elver@xxxxxxxxxx> wrote: > > 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. Sounds good to me - it's also probably measurably faster than copying the not-so-small-anymore perf_attr structure. Thanks, Ingo
