On 06/13, Eric W. Biederman wrote: > > 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. because exit_task_work() -> task_work_run() doesn't clear TIF_NOTIFY_SIGNAL. So yes, it is spurious, but to me a possible TIF_SIGPENDING is even more "spurious". See my reply to Wei. We don't need to clear TIF_NOTIFY_SIGNAL inside the loop, task_work_addd() can't succeed after exit_task_work() sets ->task_works =&work_exited, but this is another story and this doesn't (well, shouldn't) differ from TIF_SIGPENDING. > If I had infinite time and energy the ideal is to rework the pid > namespace exit logic Perhaps in this case you could take a look at the next loop waiting for pid_ns->pid_allocated == init_pids ;) I always hated the fact that the the exiting sub-namespace init can "hang forever" if this namespace has the tasks injected from the parent namespace. And I had enough hard-to-debug internal bug reports which blamed the kernel. > This active waiting is weird and non-standard in the kernel and winds up > causeing a problem every couple of years because of that. Agreed. Oleg.
