On Sat, 1 May 2021 at 02:37, Marco Elver <elver@xxxxxxxxxx> wrote: > On Sat, 1 May 2021 at 01:48, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > > > Well with 7 patches instead of 3 that was a little more than I thought > > I was going to send. > > > > However that does demonstrate what I am thinking, and I think most of > > the changes are reasonable at this point. > > > > I am very curious how synchronous this all is, because if this code > > is truly synchronous updating signalfd to handle this class of signal > > doesn't really make sense. Just a note on this: the reason for adding signalfd support was based on the comment at SIL_FAULT_PKUERR: > /* > * Fall through to the SIL_FAULT case. Both SIL_FAULT_BNDERR > * and SIL_FAULT_PKUERR are only generated by faults that > * deliver them synchronously to userspace. In case someone > * injects one of these signals and signalfd catches it treat > * it as SIL_FAULT. > */ The same would hold for SIL_FAULT_PERF_EVENT, where somebody injects (re-injects perhaps?) such an event. But otherwise, yes, non-synchronous handling of SIGTRAP/TRAP_PERF is pretty useless for almost all usecases I can think of. Thanks, -- Marco
