* Marco Elver [off-list ref] wrote:

quoted

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