On 05/16, Eric W. Biederman wrote:
>
> A kernel thread can block SIGKILL and that is supported.
>
> For a thread that is part of a process you can't block SIGKILL when the
> task is part of a user mode process.
Or SIGSTOP. Another thread can call do_signal_stop()->signal_wake_up/etc.
> There is this bit in complete_signal when SIGKILL is delivered to any
> thread in the process.
>
> t = p;
> do {
> task_clear_jobctl_pending(t, JOBCTL_PENDING_MASK);
> sigaddset(&t->pending.signal, SIGKILL);
> signal_wake_up(t, 1);
> } while_each_thread(p, t);
That is why the latest version adds try_set_pending_sigkill(). No, no,
it is not that I think this is a good idea.
> For clarity that sigaddset(&t->pending.signal, SIGKILL); Really isn't
> setting SIGKILL pending,
Hmm. it does? Nevermind.
> The important part of that code is that SIGNAL_GROUP_EXIT gets set.
> That indicates the entire process is being torn down.
Yes. and the same is true for io-thread even if it calls get_signal()
and dequeues SIGKILL and clears TIF_SIGPENDING.
> but in that case the vhost logic needs to act like a process, just
> like io_uring does.
confused... create_io_thread() creates a sub-thread too?
Although I never understood this logic. I can't even understand the usage
of lower_32_bits() in create_io_thread().
Oleg.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
