Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 16 May 2023 20:37:57 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads |
| |
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.
| ![\](/images/icornerr.gif) |