From: Jens Axboe <axboe@kernel.dk>
To: Olivier Langlois <olivier@trillion01.com>,
Pavel Begunkov <asml.silence@gmail.com>,
io-uring@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] io_uring: handle signals before letting io-worker exit
Date: Thu, 27 May 2021 09:30:14 -0600 [thread overview]
Message-ID: <7e10ffd2-5948-3869-b0dc-fd81d693fe33@kernel.dk> (raw)
In-Reply-To: <1e5c308bd25055ac8a899d40f00df08fc755e066.camel@trillion01.com>
On 5/27/21 9:21 AM, Olivier Langlois wrote:
> On Thu, 2021-05-27 at 07:46 -0600, Jens Axboe wrote:
>> On 5/26/21 12:21 PM, Olivier Langlois wrote:
>>> This is required for proper core dump generation.
>>>
>>> Because signals are normally serviced before resuming userspace and
>>> an
>>> io_worker thread will never resume userspace, it needs to
>>> explicitly
>>> call the signal servicing functions.
>>>
>>> Also, notice that it is possible to exit from the io_wqe_worker()
>>> function main loop while having a pending signal such as when
>>> the IO_WQ_BIT_EXIT bit is set.
>>>
>>> It is crucial to service any pending signal before calling
>>> do_exit()
>>> Proper coredump generation is relying on PF_SIGNALED to be set.
>>>
>>> More specifically, exit_mm() is using this flag to wait for the
>>> core dump completion before releasing its memory descriptor.
>>>
>>> Signed-off-by: Olivier Langlois <olivier@trillion01.com>
>>> ---
>>> fs/io-wq.c | 22 ++++++++++++++++++++--
>>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/io-wq.c b/fs/io-wq.c
>>> index 5361a9b4b47b..b76c61e9aff2 100644
>>> --- a/fs/io-wq.c
>>> +++ b/fs/io-wq.c
>>> @@ -9,8 +9,6 @@
>>> #include <linux/init.h>
>>> #include <linux/errno.h>
>>> #include <linux/sched/signal.h>
>>> -#include <linux/mm.h>
>>> -#include <linux/sched/mm.h>
>>> #include <linux/percpu.h>
>>> #include <linux/slab.h>
>>> #include <linux/rculist_nulls.h>
>>> @@ -193,6 +191,26 @@ static void io_worker_exit(struct io_worker
>>> *worker)
>>>
>>> kfree_rcu(worker, rcu);
>>> io_worker_ref_put(wqe->wq);
>>> + /*
>>> + * Because signals are normally serviced before resuming
>>> userspace and an
>>> + * io_worker thread will never resume userspace, it needs
>>> to explicitly
>>> + * call the signal servicing functions.
>>> + *
>>> + * Also notice that it is possible to exit from the
>>> io_wqe_worker()
>>> + * function main loop while having a pending signal such as
>>> when
>>> + * the IO_WQ_BIT_EXIT bit is set.
>>> + *
>>> + * It is crucial to service any pending signal before
>>> calling do_exit()
>>> + * Proper coredump generation is relying on PF_SIGNALED to
>>> be set.
>>> + *
>>> + * More specifically, exit_mm() is using this flag to wait
>>> for the
>>> + * core dump completion before releasing its memory
>>> descriptor.
>>> + */
>>> + if (signal_pending(current)) {
>>> + struct ksignal ksig;
>>> +
>>> + get_signal(&ksig);
>>> + }
>>> do_exit(0);
>>> }
>>
>> Do we need the same thing in fs/io_uring.c:io_sq_thread()?
>>
> Jens,
>
> You are 100% correct. In fact, this is the same problem for ALL
> currently existing and future io threads. Therefore, I start to think
> that the right place for the fix might be straight into do_exit()...
That is what I was getting at. To avoid poluting do_exit() with it, I
think it'd be best to add an io_thread_exit() that simply does:
void io_thread_exit(void)
{
if (signal_pending(current)) {
struct ksignal ksig;
get_signal(&ksig);
}
do_exit(0);
}
and convert the do_exit() calls in io_uring/io-wq to io_thread_exit()
instead.
--
Jens Axboe
next prev parent reply other threads:[~2021-05-27 15:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <60ae94d1.1c69fb81.94f7a.2a35SMTPIN_ADDED_MISSING@mx.google.com>
2021-05-27 13:46 ` [PATCH] io_uring: handle signals before letting io-worker exit Jens Axboe
2021-05-27 15:21 ` Olivier Langlois
2021-05-27 15:30 ` Jens Axboe [this message]
2021-05-27 16:09 ` Olivier Langlois
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=7e10ffd2-5948-3869-b0dc-fd81d693fe33@kernel.dk \
--to=axboe@kernel.dk \
--cc=asml.silence@gmail.com \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olivier@trillion01.com \
/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.