Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1811862pxf; Fri, 26 Mar 2021 15:51:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyr05Lredjt4Qcen9b3Jm4bByPyX0RYFDXSmLYzWn8VqnDSs97YbYZByS/42UFBKMArb2dd X-Received: by 2002:aa7:cd05:: with SMTP id b5mr6792754edw.263.1616799103256; Fri, 26 Mar 2021 15:51:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616799103; cv=none; d=google.com; s=arc-20160816; b=rX6pgASYoN5m07Mb/dyC7vsUtM5Gvqda7b3KkLeoaG34KjNDL9s9CrzsRaxiBjNMlq VLNAP9q+UD9bHkQHkx5rHbSYzry+L2Ip606x46k0UIMSoC8lqx0YX0BXDlKGz+hskNrc Y90sKTub09JxtSWaPofvG2MI5+gTZgkZZXMu/dWXKfmhEwbE2Oz6l1hLFCcRZQRI7Kkj SrRBUMu50yIu7YinNzCyKS3i5BEgQIz4Eoju9pFbG+7uZpI6JbDKvpG+qhJ0vzd1gO8O U0J/W1XcYQyoExU+gBAKtIFFZzp1iSUE2RTJtzLJ/iizfH8t2a8e1q370MzXqTWDMASH hduQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject:dkim-signature; bh=WF2hlz+Ai/cjDbzWcWmpYPi5es4Hx8NEZ//VoJpE6zY=; b=L/wj5hHK9iN3sTRqlm7YqEyrfftpNtDRcz6aMwUR7pQvEGo2YGnF1UnPtrNiuc9Af8 gpd6GMxAuyPqW6Y7BCgdoBjO9PVI2o/FIdffAGQXHsBROpCN0sDoerQF1sSw5MU2458N 4GDA2sgI/m1A5XkDwsLbuomGeW2ib1oDzNbi4lWYNciFFTzgCOgevWeonoUD2DUWE4xd EYxepz5nKlOg1yZIgjlCNKgNZdQyRBIFCdZ8APUdlpgPAK/+ALdEoMLoR89yu6xvKASt 9gLWywJH+T1e1WBtVvvxcb41wv2w44/A2rAy9OSOa5m89ay5DMpBBaaZSRvE+07WFHiV Ep2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=v1sDuCpo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bz20si8830963ejc.70.2021.03.26.15.51.20; Fri, 26 Mar 2021 15:51:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=v1sDuCpo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230027AbhCZWuY (ORCPT + 99 others); Fri, 26 Mar 2021 18:50:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230043AbhCZWt4 (ORCPT ); Fri, 26 Mar 2021 18:49:56 -0400 Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCA25C0613B1 for ; Fri, 26 Mar 2021 15:49:55 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id i81so7228162oif.6 for ; Fri, 26 Mar 2021 15:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WF2hlz+Ai/cjDbzWcWmpYPi5es4Hx8NEZ//VoJpE6zY=; b=v1sDuCpoqSChDI5/ibiue/oBxil3nTCJIB/+sanO8Pk7QbJ0OIHIiTxRkgUaJRLHTO P+mO9AzrDt/7oPGmKDygV755z2q66rAotsy21bsKVFlCwjdkdNB27Myww96DMgnYgwXK D1mR0Xl2hwaUHH/jySc8+nS4WjUn7FeLVrR1iLL44oAK1Hr9JOe2SZ0XbthbHbBWtUkV hsieo2beoFI4oAhfDWlGrgzSCfolzKpzorJeqyVKz9P8u+cT+Z0N3mCknJwFq7H3JSMe LCQABvWoFX1f13g8iG71WKP9IzDFCLmLz1nFUw15DpiMv73MZdaxZoaHG+ue37uBK9Yq pjsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WF2hlz+Ai/cjDbzWcWmpYPi5es4Hx8NEZ//VoJpE6zY=; b=d1R5rVOFlVyVooePTDGk5vkgcoezcTrrWr2Rb6R2IsmWEhfpPrTH8rsjl4MhmCdk4t vnYpPKKjCZRIamCmMyBTl37dxWkRY8+Qx0r9ZjCLiRx1ELGzGJhamstkyegNBPlt9LOP kCCxzAAppIpH2R8BLaE0fRcShH37Dbs4Mzrq3Bln70n7/6tskBvpmuJukt88aAELVIen 9xC4F4ffPuvhZCzBLUO1oB24HiuAgIW0RiyfZEff1Io9gEjHPzRWtolkkYh+OWu4WruO d5fcbVFlyHAG9zV589j2OcXQdk2vX9F+yKD3K6lSPd2KohuhFHuwUdHjjSrUEw9dQDgQ TuuA== X-Gm-Message-State: AOAM532ZBvyoDIYf6QLbm4ayzWozuBP2krzt5rs5BTBCPna65nlfFOlA Tzn/NuLGXihtPaWqsYT63BW7CbNVTq9rLQ== X-Received: by 2002:a54:409a:: with SMTP id i26mr11386693oii.41.1616798994654; Fri, 26 Mar 2021 15:49:54 -0700 (PDT) Received: from [192.168.1.30] ([207.135.233.147]) by smtp.gmail.com with ESMTPSA id r22sm2389052otg.4.2021.03.26.15.49.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Mar 2021 15:49:54 -0700 (PDT) Subject: Re: [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread From: Jens Axboe To: "Eric W. Biederman" Cc: io-uring@vger.kernel.org, torvalds@linux-foundation.org, metze@samba.org, oleg@redhat.com, linux-kernel@vger.kernel.org References: <20210326155128.1057078-1-axboe@kernel.dk> <20210326155128.1057078-3-axboe@kernel.dk> <106a38d3-5a5f-17fd-41f7-890f5e9a3602@kernel.dk> <01058178-dd66-1bff-4d74-5ff610817ed6@kernel.dk> <7a71da2f-ca39-6bbf-28c1-bcc2eec43943@kernel.dk> Message-ID: <387feabb-e758-220a-fc34-9e9325eab3a6@kernel.dk> Date: Fri, 26 Mar 2021 16:49:53 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7a71da2f-ca39-6bbf-28c1-bcc2eec43943@kernel.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/26/21 4:38 PM, Jens Axboe wrote: > On 3/26/21 4:35 PM, Eric W. Biederman wrote: >> Jens Axboe writes: >> >>> On 3/26/21 4:23 PM, Eric W. Biederman wrote: >>>> Jens Axboe writes: >>>> >>>>> On 3/26/21 2:29 PM, Eric W. Biederman wrote: >>>>>> Jens Axboe 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 >>>>>>> --- >>>>>>> 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 >>>>>>> #include >>>>>>> #include >>>>>>> -#include >>>>>>> >>>>>>> #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. >>> >>> I've just come to the same conclusion myself after testing it. >>> Of the 3 cases, most of them can do the continue, but doesn't >>> really matter with the way the loop is structured. Anyway, looks >>> like this now: >> >> This idiom in the code: >>> + if (signal_pending(current)) { >>> + struct ksignal ksig; >>> + >>> + if (fatal_signal_pending(current)) >>> + break; >>> + if (!get_signal(&ksig)) >>> + continue; >>> } >> >> Needs to be: >>> + if (signal_pending(current)) { >>> + struct ksignal ksig; >>> + >>> + if (!get_signal(&ksig)) >>> + continue; >>> + break; >>> } >> >> Because any signal returned from get_signal is fatal in this case. >> It might make sense to "WARN_ON(ksig->ka.sa.sa_handler != SIG_DFL)". >> As the io workers don't handle that case. >> >> It won't happen because you have everything blocked. >> >> The extra fatal_signal_pending(current) logic is just confusing in this >> case. > > OK good point, and follows the same logic even if it won't make a > difference in my case. I'll make the change. Made the suggested edits and ran the quick tests and the KILL/STOP testing, and no ill effects observed. Kicked off the longer runs now. Not a huge amount of changes from the posted series, but please peruse here if you want to double check: https://git.kernel.dk/cgit/linux-block/log/?h=io_uring-5.12 And diff against v2 posted is below. Thanks! diff --git a/fs/io-wq.c b/fs/io-wq.c index 3e2f059a1737..7434eb40ca8c 100644 --- a/fs/io-wq.c +++ b/fs/io-wq.c @@ -505,10 +505,9 @@ static int io_wqe_worker(void *data) if (signal_pending(current)) { struct ksignal ksig; - if (fatal_signal_pending(current)) - break; - if (get_signal(&ksig)) + if (!get_signal(&ksig)) continue; + break; } if (ret) continue; @@ -722,10 +721,9 @@ static int io_wq_manager(void *data) if (signal_pending(current)) { struct ksignal ksig; - if (fatal_signal_pending(current)) - set_bit(IO_WQ_BIT_EXIT, &wq->state); - else if (get_signal(&ksig)) + if (!get_signal(&ksig)) continue; + set_bit(IO_WQ_BIT_EXIT, &wq->state); } } while (!test_bit(IO_WQ_BIT_EXIT, &wq->state)); diff --git a/fs/io_uring.c b/fs/io_uring.c index 66ae46874d85..880abd8b6d31 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -6746,10 +6746,9 @@ static int io_sq_thread(void *data) if (signal_pending(current)) { struct ksignal ksig; - if (fatal_signal_pending(current)) - break; - if (get_signal(&ksig)) + if (!get_signal(&ksig)) continue; + break; } sqt_spin = false; cap_entries = !list_is_singular(&sqd->ctx_list); diff --git a/kernel/signal.c b/kernel/signal.c index 5b75fbe3d2d6..f2718350bf4b 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -2752,15 +2752,6 @@ bool get_signal(struct ksignal *ksig) */ current->flags |= PF_SIGNALED; - /* - * 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. coredumps also - * do not apply to them. - */ - if (current->flags & PF_IO_WORKER) - return false; - if (sig_kernel_coredump(signr)) { if (print_fatal_signals) print_fatal_signal(ksig->info.si_signo); @@ -2776,6 +2767,14 @@ bool get_signal(struct ksignal *ksig) do_coredump(&ksig->info); } + /* + * 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. + */ + if (current->flags & PF_IO_WORKER) + goto out; + /* * Death signals, no core dump. */ @@ -2783,7 +2782,7 @@ bool get_signal(struct ksignal *ksig) /* NOTREACHED */ } spin_unlock_irq(&sighand->siglock); - +out: ksig->sig = signr; if (!(ksig->ka.sa.sa_flags & SA_EXPOSE_TAGBITS)) -- Jens Axboe