public inbox for [email protected]
 help / color / mirror / Atom feed
From: Linus Torvalds <[email protected]>
To: "Eric W. Biederman" <[email protected]>
Cc: Jens Axboe <[email protected]>, io-uring <[email protected]>,
	Linux Kernel Mailing List <[email protected]>,
	Oleg Nesterov <[email protected]>
Subject: Re: [PATCHSET 0/2] PF_IO_WORKER signal tweaks
Date: Sat, 20 Mar 2021 10:51:47 -0700	[thread overview]
Message-ID: <CAHk-=whyL6prwWR0GdgxLZm_w-QWwo7jPw_DkEGYFbMeCdo8YQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>

On Sat, Mar 20, 2021 at 9:27 AM Eric W. Biederman <[email protected]> wrote:
>
> That makes me uneasy.  Because especially the SIGSTOP changes feels like
> it is the wrong thing semantically.  The group_send_sig_info change
> simply feels like it is unnecessary.

SIGSTOP handling is fundamentally done at signal handling time, and
signal handling is fundamentally done at "return to user space" time.

End result: you cannot send kernel threads any signals at all, unless
it _explicitly_ handles them manually.  SIGSTOP isn't different from
user space delivery of an "actual" signal handler in this respect.

And practically speaking, the only signal a kernel thread generally
can handle is SIGKILL (and exit on it).

Now, to make matters actually more confusing for SIGSTOP, it's a
two-phase operation - initiated from that usual "about to return to
user space with signals pending" logic (which doesn't happen for
kernel threads, including IO threads), _and_ then it has that magic
accounting for when to notify the parent about stoppage (which has
some across-thread handling).

I really think IO threads need to not participate, because they simply
cannot handle signals in any sane manner.

You should think of the IO threads as fully kernel threads that just
share VM and fs with the user thing.

In fact, it might be a good idea to disassociate them from the thread
group entirely when they are created, so that none of
"for_each_thread()" or "next_thread()" logic ever finds them.

Maybe the right thing to do is to add a new case to that whole thread
group initialization code in copy_process() - something like this fake
and intentionally whitespace-damaged pseudo-patch:

  diff --git a/kernel/fork.c b/kernel/fork.c
  index 54cc905e5fe0..b87abe3a9ac6 100644
  --- a/kernel/fork.c
  +++ b/kernel/fork.c
  @@ -2296,7 +2296,7 @@ static __latent_entropy struct task_struct
*copy_process(
                attach_pid(p, PIDTYPE_PGID);
                attach_pid(p, PIDTYPE_SID);
                __this_cpu_inc(process_counts);
  -     } else {
  +     } else if (!IOTHREAD) {
                current->signal->nr_threads++;
                atomic_inc(&current->signal->live);
                refcount_inc(&current->signal->sigcnt);

so that the IO thread isn't considered "really" part of the existing
signal state. Alternatively, make it not use
CLONE_SIGHAND|CLONE_THREAD at all, but that would make it
unnecessarily allocate its own signal state, so that's "cleaner" but
not great either.

Hmm.

            Linus

  reply	other threads:[~2021-03-20 17:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-20 15:38 [PATCHSET 0/2] PF_IO_WORKER signal tweaks Jens Axboe
2021-03-20 15:38 ` [PATCH 1/2] signal: don't allow sending any signals to PF_IO_WORKER threads Jens Axboe
2021-03-20 16:18   ` Eric W. Biederman
2021-03-20 17:56     ` Linus Torvalds
2021-03-20 21:38       ` Eric W. Biederman
2021-03-20 22:42         ` Jens Axboe
2021-03-21 14:54           ` Eric W. Biederman
2021-03-21 15:40             ` Jens Axboe
2021-03-20 15:38 ` [PATCH 2/2] signal: don't allow STOP on " Jens Axboe
2021-03-20 16:21   ` Eric W. Biederman
2021-03-22 16:18     ` Oleg Nesterov
2021-03-22 16:15   ` Oleg Nesterov
2021-03-20 16:26 ` [PATCHSET 0/2] PF_IO_WORKER signal tweaks Eric W. Biederman
2021-03-20 17:51   ` Linus Torvalds [this message]
2021-03-20 19:18     ` Linus Torvalds
2021-03-20 22:08       ` Eric W. Biederman
2021-03-20 22:53         ` Jens Axboe
2021-03-21 15:18           ` Eric W. Biederman
2021-03-21 15:42             ` Jens Axboe
2021-03-20 22:56       ` Jens Axboe
2021-03-20 17:05 ` kernel test robot
2021-03-20 17:05 ` kernel test robot
2021-03-20 19:10 ` kernel test robot
2021-03-22 16:05 ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=whyL6prwWR0GdgxLZm_w-QWwo7jPw_DkEGYFbMeCdo8YQ@mail.gmail.com' \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox