On Wed, Oct 30, 2024 at 1:25 AM Tejun Heo <tj@xxxxxxxxxx> wrote: > > I'm not sure if the KVM worker thread should process signals. We want it > > to take the CPU time it uses from the guest, but otherwise it's not running > > on behalf of userspace in the way that io_wq_worker() is. > > I see, so io_wq_worker()'s handle signals only partially. It sets > PF_USER_WORKER which ignores fatal signals, so the only signals which take > effect are STOP/CONT (and friends) which is handled in do_signal_stop() > which is also where the cgroup2 freezer is implemented. What about SIGKILL? That's the one that I don't want to have for KVM workers, because they should only stop when the file descriptor is closed. (Replying to Luca: the kthreads are dropping some internal data structures that KVM had to "de-optimize" to deal with processor bugs. They allow the data structures to be rebuilt in the optimal way using large pages). > Given that the kthreads are tied to user processes, I think it'd be better > to behave similarly to user tasks as possible in this regard if userspace > being able to stop/cont these kthreads are okay. Yes, I totally agree with you on that, I'm just not sure of the best way to do it. I will try keeping the kthread and adding allow_signal(SIGSTOP). That should allow me to process the SIGSTOP via get_signal(). Paolo
