> > Consider the following scenario (with supervisor "S" and target "T"; S > > wants to wait for events on two file descriptors seccomp_fd and > > other_fd): > > > > S: starts poll() to wait for events on seccomp_fd and other_fd > > T: performs a syscall that's filtered with RET_USER_NOTIF > > S: poll() returns and signals readiness of seccomp_fd > > T: receives signal SIGUSR1 > > T: syscall aborts, enters signal handler > > T: signal handler blocks on unfiltered syscall (e.g. write()) > > S: starts SECCOMP_IOCTL_NOTIF_RECV > > S: blocks because no syscalls are pending > > > > Depending on what other_fd is, this could in a worst case even lead to > > a deadlock (if e.g. the signal handler wants to write to stdout, but > > the stdout fd is hooked up to other_fd in the supervisor, but the > > supervisor can't consume the data written because it's stuck in > > seccomp handling). > > > > So we have to ensure that when existing code (like that crun code you > > linked to) triggers this case, SECCOMP_IOCTL_NOTIF_RECV returns > > immediately instead of blocking. > > Or I guess we could also just set O_NONBLOCK on the fd by default? > Since the one existing user is eventloop-based... I feel like it's ok to return an error from the RECV ioctl() if there's never going to be any more events on the fd; was there something fundamentally wrong with your patch here: https://lore.kernel.org/bpf/CAG48ez2xn+_KznEztJ-eVTsTzkbf9CVgPqaAk7TpRNAqbdaRoA@xxxxxxxxxxxxxx/ ? That seemed reasonable to me (although maybe nicer if we could get rid of the open-ish coded semaphore; I couldn't figure out how though). Tycho _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
