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