Re: re. Spurious wakeup on a newly created kthread

[Linus Torvalds <torvalds@linux-foundation.org>]

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