From: Olivier Langlois <olivier@trillion01.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
Jens Axboe <axboe@kernel.dk>
Cc: Pavel Begunkov <asml.silence@gmail.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Oleg Nesterov <oleg@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 2/2] coredump: Allow coredumps to pipes to work with io_uring
Date: Mon, 22 Aug 2022 17:16:59 -0400 [thread overview]
Message-ID: <61abfb5a517e0ee253b0dc7ba9cd32ebd558bcb0.camel@trillion01.com> (raw)
In-Reply-To: <87mtd3rals.fsf_-_@email.froward.int.ebiederm.org>
On Wed, 2022-07-20 at 11:51 -0500, Eric W. Biederman wrote:
>
> Now that io_uring like everything else stops for coredumps in
> get_signal the code can once again allow any interruptible
> condition after coredump_wait to interrupt the coredump.
>
> Clear TIF_NOTIFY_SIGNAL after coredump_wait, to guarantee that
> anything that sets TIF_NOTIFY_SIGNAL before coredump_wait completed
> won't cause the coredumps to interrupted.
>
> With all of the other threads in the process stopped io_uring doesn't
> call task_work_add on the thread running do_coredump. Combined with
> the clearing of TIF_NOTIFY_SIGNAL this allows processes that use
> io_uring to coredump through pipes.
>
> Restore dump_interrupted to be a simple call to signal_pending
> effectively reverting commit 06af8679449d ("coredump: Limit what can
> interrupt coredumps"). At this point only SIGKILL delivered to the
> coredumping thread should be able to cause signal_pending to return
> true.
>
> A nice followup would be to find a reliable race free way to modify
> task_work_add and probably set_notify_signal to skip setting
> TIF_NOTIFY_SIGNAL once it is clear a task will no longer process
> signals and other interruptible conditions. That would allow
> TIF_NOTIFY_SIGNAL to be cleared where TIF_SIGPENDING is cleared in
> coredump_zap_process.
>
> To be as certain as possible that this works, I tested this with
> commit 1d5f5ea7cb7d ("io-wq: remove worker to owner tw dependency")
> reverted. Which means that not only is TIF_NOTIFY_SIGNAL prevented
> from stopping coredumps to pipes, the sequence of stopping threads to
> participate in the coredump avoids deadlocks that were possible
> previously.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
Hi Eric,
What is stopping the task calling do_coredump() to be interrupted and
call task_work_add() from the interrupt context?
This is precisely what I was experiencing last summer when I did work
on this issue.
My understanding of how async I/O works with io_uring is that the task
is added to a wait queue without being put to sleep and when the
io_uring callback is called from the interrupt context, task_work_add()
is called so that the next time io_uring syscall is invoked, pending
work is processed to complete the I/O.
So if:
1. io_uring request is initiated AND the task is in a wait queue
2. do_coredump() is called before the I/O is completed
IMHO, this is how you end up having task_work_add() called while the
coredump is generated.
So far, the only way that I have found making sure that this was not
happening was to cancel every pending io_uring requests before writing
the coredump by calling io_uring_task_cancel():
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -43,7 +43,7 @@
#include <linux/timekeeping.h>
#include <linux/sysctl.h>
#include <linux/elf.h>
-
+#include <linux/io_uring.h>
#include <linux/uaccess.h>
#include <asm/mmu_context.h>
#include <asm/tlb.h>
@@ -561,6 +561,8 @@
need_suid_safe = true;
}
+ io_uring_task_cancel();
+
retval = coredump_wait(siginfo->si_signo, &core_state);
if (retval < 0)
goto fail_creds;
Greetings,
next prev parent reply other threads:[~2022-08-22 22:28 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <192c9697e379bf084636a8213108be6c3b948d0b.camel@trillion01.com>
[not found] ` <9692dbb420eef43a9775f425cb8f6f33c9ba2db9.camel@trillion01.com>
[not found] ` <87h7i694ij.fsf_-_@disp2133>
2021-06-09 20:33 ` [RFC] coredump: Do not interrupt dump for TIF_NOTIFY_SIGNAL Linus Torvalds
2021-06-09 20:48 ` Eric W. Biederman
2021-06-09 20:52 ` Linus Torvalds
2021-06-09 21:02 ` Olivier Langlois
2021-06-09 21:05 ` Eric W. Biederman
2021-06-09 21:26 ` Olivier Langlois
2021-06-09 21:56 ` Olivier Langlois
2021-06-10 14:26 ` Eric W. Biederman
2021-06-10 15:17 ` Olivier Langlois
2021-06-10 18:58 ` [CFT}[PATCH] coredump: Limit what can interrupt coredumps Eric W. Biederman
2021-06-10 19:10 ` Linus Torvalds
2021-06-10 19:18 ` Eric W. Biederman
2021-06-10 19:50 ` Linus Torvalds
2021-06-10 20:11 ` [PATCH] " Eric W. Biederman
2021-06-10 21:04 ` Linus Torvalds
2021-06-12 14:36 ` Olivier Langlois
2021-06-12 16:26 ` Jens Axboe
2021-06-14 14:10 ` Oleg Nesterov
2021-06-14 16:37 ` Eric W. Biederman
2021-06-14 16:59 ` Oleg Nesterov
2021-06-15 22:08 ` Eric W. Biederman
2021-06-16 19:23 ` Olivier Langlois
2021-06-16 20:00 ` Eric W. Biederman
2021-06-18 20:05 ` Olivier Langlois
2021-08-05 13:06 ` Olivier Langlois
2021-08-10 21:48 ` Tony Battersby
2021-08-11 20:47 ` Olivier Langlois
2021-08-12 1:55 ` Jens Axboe
2021-08-12 13:53 ` Tony Battersby
2021-08-15 20:42 ` Olivier Langlois
2021-08-16 13:02 ` Pavel Begunkov
2021-08-16 13:06 ` Pavel Begunkov
2021-08-17 18:15 ` Jens Axboe
2021-08-17 18:24 ` Jens Axboe
2021-08-17 19:29 ` Tony Battersby
2021-08-17 19:59 ` Jens Axboe
2021-08-17 21:28 ` Jens Axboe
2021-08-17 21:39 ` Tony Battersby
2021-08-17 22:05 ` Jens Axboe
2021-08-18 14:37 ` Tony Battersby
2021-08-18 14:46 ` Jens Axboe
2021-08-18 2:57 ` Jens Axboe
2021-08-18 2:58 ` Jens Axboe
2021-08-21 10:08 ` Olivier Langlois
2021-08-21 16:47 ` Olivier Langlois
2021-08-21 16:51 ` Jens Axboe
2021-08-21 17:21 ` Olivier Langlois
2021-08-21 9:52 ` Olivier Langlois
2021-08-21 9:48 ` Olivier Langlois
2021-10-22 14:13 ` [RFC] coredump: Do not interrupt dump for TIF_NOTIFY_SIGNAL Pavel Begunkov
2021-12-24 1:34 ` Olivier Langlois
2021-12-24 10:37 ` Pavel Begunkov
2021-12-24 19:52 ` Eric W. Biederman
2021-12-28 11:24 ` Pavel Begunkov
2022-03-14 23:58 ` Eric W. Biederman
[not found] ` <8218f1a245d054c940e25142fd00a5f17238d078.camel@trillion01.com>
2022-06-01 3:15 ` Jens Axboe
2022-07-20 16:49 ` [PATCH 0/2] coredump: Allow io_uring using apps to dump to pipes Eric W. Biederman
2022-07-20 16:50 ` [PATCH 1/2] signal: Move stopping for the coredump from do_exit into get_signal Eric W. Biederman
2022-07-20 16:51 ` [PATCH 2/2] coredump: Allow coredumps to pipes to work with io_uring Eric W. Biederman
2022-08-22 21:16 ` Olivier Langlois [this message]
2022-08-23 3:35 ` Olivier Langlois
2022-08-23 18:22 ` Eric W. Biederman
2022-08-23 18:27 ` Jens Axboe
2022-08-24 15:11 ` Eric W. Biederman
2022-08-24 15:51 ` Jens Axboe
2022-01-05 19:39 ` [RFC] coredump: Do not interrupt dump for TIF_NOTIFY_SIGNAL 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=61abfb5a517e0ee253b0dc7ba9cd32ebd558bcb0.camel@trillion01.com \
--to=olivier@trillion01.com \
--cc=asml.silence@gmail.com \
--cc=axboe@kernel.dk \
--cc=ebiederm@xmission.com \
--cc=io-uring@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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.