lkml.org 
[lkml]   [2021]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread
    Jens Axboe <axboe@kernel.dk> writes:

    > On 3/26/21 2:29 PM, Eric W. Biederman wrote:
    >> Jens Axboe <axboe@kernel.dk> writes:
    >>
    >>> We go through various hoops to disallow signals for the IO threads, but
    >>> there's really no reason why we cannot just allow them. The IO threads
    >>> never return to userspace like a normal thread, and hence don't go through
    >>> normal signal processing. Instead, just check for a pending signal as part
    >>> of the work loop, and call get_signal() to handle it for us if anything
    >>> is pending.
    >>>
    >>> With that, we can support receiving signals, including special ones like
    >>> SIGSTOP.
    >>>
    >>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
    >>> ---
    >>> fs/io-wq.c | 24 +++++++++++++++++-------
    >>> fs/io_uring.c | 12 ++++++++----
    >>> 2 files changed, 25 insertions(+), 11 deletions(-)
    >>>
    >>> diff --git a/fs/io-wq.c b/fs/io-wq.c
    >>> index b7c1fa932cb3..3e2f059a1737 100644
    >>> --- a/fs/io-wq.c
    >>> +++ b/fs/io-wq.c
    >>> @@ -16,7 +16,6 @@
    >>> #include <linux/rculist_nulls.h>
    >>> #include <linux/cpu.h>
    >>> #include <linux/tracehook.h>
    >>> -#include <linux/freezer.h>
    >>>
    >>> #include "../kernel/sched/sched.h"
    >>> #include "io-wq.h"
    >>> @@ -503,10 +502,16 @@ static int io_wqe_worker(void *data)
    >>> if (io_flush_signals())
    >>> continue;
    >>> ret = schedule_timeout(WORKER_IDLE_TIMEOUT);
    >>> - if (try_to_freeze() || ret)
    >>> + if (signal_pending(current)) {
    >>> + struct ksignal ksig;
    >>> +
    >>> + if (fatal_signal_pending(current))
    >>> + break;
    >>> + if (get_signal(&ksig))
    >>> + continue;
    >> ^^^^^^^^^^^^^^^^^^^^^^
    >>
    >> That is wrong. You are promising to deliver a signal to signal
    >> handler and them simply discarding it. Perhaps:
    >>
    >> if (!get_signal(&ksig))
    >> continue;
    >> WARN_ON(!sig_kernel_stop(ksig->sig));
    >> break;
    >
    > Thanks, updated.

    Gah. Kill the WARN_ON.

    I was thinking "WARN_ON(!sig_kernel_fatal(ksig->sig));"
    The function sig_kernel_fatal does not exist.

    Fatal is the state that is left when a signal is neither
    ignored nor a stop signal, and does not have a handler.

    The rest of the logic still works.

    Eric

    \
     
     \ /
      Last update: 2021-03-26 23:25    [W:3.107 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site