On 5/21/21 9:23 AM, Sargun Dhillon wrote: > Andy pointed out that we need a mechanism to determine whether or > notifications are preempted. He suggested we use EPOLLPRI to indicate > whether or not notifications are preempted. My outstanding question is > whether or not we need to be able to get insight of what caused the > preemption, and to which notification. > > In the past, Christian has suggested just background polling > notification IDs for validity, which is a fine mechanism to determine > that preemption has occurred. We could raise EPOLLPRI whenever a > notification has changed into the preempted state, but that would > require an O(n) operations across all outstanding notifications to > determine which one was preempted, and in addition, it doesn't give a > lot of information as to why the preemption occurred (fatal signal, > preemption?). > > In order to try to break this into small parts, I suggest: > 1. We make it so EPOLLPRI is raised (always) on preempted notifications > 2. We allow the user to set a flag to "track" notifications. If they > specify this flag, they can then run a "stronger" ioctl -- let's say > SECCOMP_IOCTL_NOTIF_STATUS, which, if the flag was specified upon > receiving the notification will return the current state of the > notification and if a signal preempted it, it will always do that. > > --- > Alternatively (and this is my preference), we add another filter flag, > like SECCOMP_FILTER_FLAG_NOTIF_PREEMPT, which changes the behaviour > to: > 1. Raise EPOLLPRI on preempted notifications > 2. All preemption notifications must be cleared via > SECCOMP_IOCTL_NOTIF_RECV_STATUS. This seems sensible, except I don't think "preempted" is the right word. The state machine is pretty simple: live -> signaled -> killed (and we can go straight from live to killed, too.) So EPOLLPRI could be signaled if any notification changes state, and a new ioctl could read the list of notifications that have changed state. --Andy
