by Oleg Nesterov

[permalink] [raw]

Subject: Re: [PATCH] zap_pid_ns_processes: clear TIF_NOTIFY_SIGNAL along with TIF_SIGPENDING

On 06/13, Eric W. Biederman wrote:
>
> Oleg Nesterov <[email protected]> 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.

2024-06-13 16:24:17

by Eric W. Biederman

[permalink] [raw]

Subject: Re: [PATCH] zap_pid_ns_processes: don't send SIGKILL to sub-threads

Oleg Nesterov <[email protected]> writes:

> On 06/13, Eric W. Biederman wrote:
>>
>> Oleg Nesterov <[email protected]> writes:
>>
>> > The comment above the idr_for_each_entry_continue() loop tries to explain
>> > why we have to signal each thread in the namespace, but it is outdated.
>> > This code no longer uses kill_proc_info(), we have a target task so we can
>> > check thread_group_leader() and avoid the unnecessary group_send_sig_info.
>> > Better yet, we can change pid_task() to use PIDTYPE_TGID rather than _PID,
>> > this way it returns NULL if this pid is not a group-leader pid.
>> >
>> > Also, change this code to check SIGNAL_GROUP_EXIT, the exiting process /
>> > thread doesn't necessarily has a pending SIGKILL. Either way these checks
>> > are racy without siglock, so the patch uses data_race() to shut up KCSAN.
>>
>> You remove the comment but the meat of what it was trying to say remains
>> true. For processes in a session or processes is a process group a list
>> of all such processes is kept. No such list is kept for a pid
>> namespace. So the best we can do is walk through the allocated pid
>> numbers in the pid namespace.
>
> OK, I'll recheck tomorrow. Yet I think it doesn't make sense to send
> SIGKILL to sub-threads, and the comment looks misleading today. This was
> the main motivation, but again, I'll recheck.

Yes, we only need to send SIGKILL to only one thread.
Of course there are a few weird cases with zombie leader threads,
but I think the pattern you are using handles them.

>> It would also help if this explains that in the case of SIGKILL
>> complete_signal always sets SIGNAL_GROUP_EXIT which makes that a good
>> check to use to see if the process has been killed (with SIGKILL).
>
> Well, if SIGNAL_GROUP_EXIT is set we do not care if this process was
> killed or not. It (the whole thread group) is going to exit, that is all.
>
> We can even remove this check, it is just the optimization, just like
> the current fatal_signal_pending() check.

I just meant that the optimization is effective because
group_send_sig_info calls complete_signal which sets SIGNAL_GROUP_EXIT.

Which makes it an almost 100% accurate test, which makes it a very
good optimization. Especially in the case of multi-threaded processes
where the code will arrive there for every thread.

Eric