All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: io-uring@vger.kernel.org, torvalds@linux-foundation.org,
	metze@samba.org, oleg@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] kernel: don't call do_exit() for PF_IO_WORKER threads
Date: Fri, 26 Mar 2021 16:11:18 -0600	[thread overview]
Message-ID: <80915fd5-7cb1-167a-2c8a-01a0f8f21bd2@kernel.dk> (raw)
In-Reply-To: <m14kgxy7b4.fsf@fess.ebiederm.org>

On 3/26/21 2:43 PM, Eric W. Biederman wrote:
> Jens Axboe <axboe@kernel.dk> writes:
> 
>> Right now we're never calling get_signal() from PF_IO_WORKER threads, but
>> in preparation for doing so, don't handle a fatal signal for them. The
>> workers have state they need to cleanup when exiting, and they don't do
>> coredumps, so just return instead of performing either a dump or calling
>> do_exit() on their behalf. The threads themselves will detect a fatal
>> signal and do proper shutdown.
>>
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>> ---
>>  kernel/signal.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/kernel/signal.c b/kernel/signal.c
>> index f2a1b898da29..e3e1b8fbfe8a 100644
>> --- a/kernel/signal.c
>> +++ b/kernel/signal.c
>> @@ -2756,6 +2756,15 @@ 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;
>> +
> 
> Returning false when get_signal needs the caller to handle a signal
> adds a very weird and awkward special case to how get_signal returns
> arguments.
> 
> Instead you should simply break and let get_signal return SIGKILL like
> any other signal that has a handler that the caller of get_signal needs
> to handle.
> 
> Something like:
>> +		/*
>> +		 * PF_IO_WORKER have cleanup that must be performed,
>> +		 * before calling do_exit().
>> +		 */
>> +		if (current->flags & PF_IO_WORKER)
>> +			break;
> 
> 
> As do_coredump does not call do_exit there is no reason to skip calling into
> the coredump handling either.   And allowing it will remove yet another
> special case from the io worker code.

Thanks, I'll turn it into a break, that does seem like a better idea in
general. Actually it wants to be a goto or similar, as a break will
assume that we have the sighand lock held. With the coredump being
irrelevant, I'll just it before the do_exit() call.

-- 
Jens Axboe


  reply	other threads:[~2021-03-26 22:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 15:51 [PATCHSET v2 0/7] Allow signals for IO threads Jens Axboe
2021-03-26 15:51 ` [PATCH 1/7] kernel: don't call do_exit() for PF_IO_WORKER threads Jens Axboe
2021-03-26 20:43   ` Eric W. Biederman
2021-03-26 22:11     ` Jens Axboe [this message]
2021-03-26 15:51 ` [PATCH 2/7] io_uring: handle signals for IO threads like a normal thread Jens Axboe
2021-03-26 20:29   ` Eric W. Biederman
2021-03-26 22:14     ` Jens Axboe
2021-03-26 22:23       ` Eric W. Biederman
2021-03-26 22:30         ` Jens Axboe
2021-03-26 22:35           ` Eric W. Biederman
2021-03-26 22:38             ` Jens Axboe
2021-03-26 22:49               ` Jens Axboe
2021-03-27 17:40                 ` Eric W. Biederman
2021-03-27 20:08                   ` Jens Axboe
2021-03-26 15:51 ` [PATCH 03/10] Revert "signal: don't allow sending any signals to PF_IO_WORKER threads" Jens Axboe
2021-03-26 15:51 ` [PATCH 3/7] kernel: stop masking signals in create_io_thread() Jens Axboe
2021-03-26 20:44   ` Eric W. Biederman
2021-03-26 15:51 ` [PATCH 04/10] Revert "kernel: treat PF_IO_WORKER like PF_KTHREAD for ptrace/signals" Jens Axboe
2021-03-26 15:51 ` [PATCH 4/7] Revert "signal: don't allow sending any signals to PF_IO_WORKER threads" Jens Axboe
2021-03-26 15:51 ` [PATCH 05/10] Revert "kernel: freezer should treat PF_IO_WORKER like PF_KTHREAD for freezing" Jens Axboe
2021-03-26 15:51 ` [PATCH 5/7] Revert "kernel: treat PF_IO_WORKER like PF_KTHREAD for ptrace/signals" Jens Axboe
2021-03-26 15:51 ` [PATCH 6/7] Revert "kernel: freezer should treat PF_IO_WORKER like PF_KTHREAD for freezing" Jens Axboe
2021-03-26 15:51 ` [PATCH 06/10] Revert "signal: don't allow STOP on PF_IO_WORKER threads" Jens Axboe
2021-03-26 15:51 ` [PATCH 7/7] " Jens Axboe
2021-03-26 15:51 ` [PATCH 07/10] io_uring: fix timeout cancel return code Jens Axboe
2021-03-26 15:51 ` [PATCH 08/10] io_uring: do post-completion chore on t-out cancel Jens Axboe
2021-03-26 15:51 ` [PATCH 09/10] io_uring: don't cancel-track common timeouts Jens Axboe
2021-03-26 15:51 ` [PATCH 10/10] io_uring: don't cancel extra on files match Jens Axboe
2021-03-26 15:54 ` [PATCHSET v2 0/7] Allow signals for IO threads Jens Axboe

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=80915fd5-7cb1-167a-2c8a-01a0f8f21bd2@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=ebiederm@xmission.com \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=metze@samba.org \
    --cc=oleg@redhat.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.