On Sat, 1 May 2021 at 02:37, Marco Elver [off-list ref] wrote:

On Sat, 1 May 2021 at 01:48, Eric W. Biederman [off-list ref] wrote:

quoted

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