On Wed, 24 Mar 2021 at 15:15, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > On Wed, Mar 24, 2021 at 3:12 PM Dmitry Vyukov <dvyukov@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. > > > > One potential alternative is use of an opaque u64 context (if we could > > shove it into the attr). A user can pass a pointer to the attr in > > there (makes it equivalent to this proposal), or bit-pack size/type > > (as we want), pass some sequence number or whatever. > > Just to clarify what I was thinking about, but did not really state: > perf_event_attr_t includes u64 ctx, and we return it back to the user > in siginfo_t. Kernel does not treat it in any way. This is a pretty > common API pattern in general. Ok, let's go for a new field in perf_event_attr which is copied to si_perf. This gives user space full flexibility to decide what to stick in it, and the kernel does not prescribe some weird encoding or synchronization that user space would have to live with. I'll probably call it perf_event_attr::sig_data, because all si_* things are macros. Thanks, -- Marco
