Messages in this thread | | | From | Linus Torvalds <> | Date | Sat, 25 Jun 2022 11:25:21 -0700 | Subject | Re: re. Spurious wakeup on a newly created kthread |
| |
On Sat, Jun 25, 2022 at 10:36 AM Eric W. Biederman <ebiederm@xmission.com> wrote: > > Let me suggest someone create a new variant of kthread_create that takes > all of the parameters the workqueue code wants to set.
I suspect the real issue is that that the kthread code simply shouldn't use the kernel_thread() helper at all.
That helper is literally designed for "start a thread, run this thing".
That's what it *does*.
And that's not at all what the kthread code wants. It wants to set affinity masks, it wants to create a name for the thread, it wants to do all those other things.
That code really wants to just do copy_process().
Or maybe it really should just use create_io_thread(), which has a much better interface, except it has that one oddity in that it sets the flag that does this:
if (args->io_thread) { /* * Mark us an IO worker, and block any signal that isn't * fatal or STOP */ p->flags |= PF_IO_WORKER; siginitsetinv(&p->blocked, sigmask(SIGKILL)|sigmask(SIGSTOP)); }
that then has special semantics.
Now, those special semantics may actually be exactly what kthreads wants, but they are important:
/* * PF_IO_WORKER threads will catch and exit on fatal signals * themselves. They have cleanup that must be performed, so * we cannot call do_exit() on their behalf. */
which is about that "what happens for fatal signals" thing.
Linus
| |