> > Oleg Nesterov <oleg@xxxxxxxxxx> writes: > > > kernel_wait4() doesn't sleep and returns -EINTR if there is no > > eligible child and signal_pending() is true. > > > > That is why zap_pid_ns_processes() clears TIF_SIGPENDING but this is not > > enough, it should also clear TIF_NOTIFY_SIGNAL to make signal_pending() > > return false and avoid a busy-wait loop. > > I took a look through the code. It used to be that TIF_NOTIFY_SIGNAL > was all about waking up a task so that task_work_run can be used. > io_uring still mostly uses it that way. There is also a use in > kthread_stop that just uses it as a TIF_SIGPENDING without having a > pending signal. > > At the point in do_exit where exit_notify and thus zap_pid_ns_processes > is called I can't possibly see a use for TIF_NOTIFY_SIGNAL. > exit_task_work, exit_signals, and io_uring_cancel have all been called. > > So TIF_NOTIFY_SIGNAL should be spurious at this point and safe to clear. > Why it remains set is a mystery to me. I think there is a case that TIF_NOTIFY_SIGNAL remains set. Init process has main-thread, sub-thread-X and iou-wrk-thread-X (created by sub-thread-X). When main-thread enters exit_group, both sub-thread-X and iou-wrk-thread-X are set by TIF_SIGPENDING and wake up. The sub-thread-X could call io_uring_cancel to set TIF_NOTIFY_SIGNAL for iou-wrk-thread-X which doesn't have chance to clear it. And then iou-wrk-thread-X gets into zap_pid_ns_processes function with TIF_NOTIFY_SIGNAL flag. If there are active processes in that pid namespace, it will run into this issue. Wei
