From: Kees Cook <keescook@chromium.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-api@vger.kernel.org
Subject: Re: [PATCH 5/6] coredump: Don't perform any cleanups before dumping core
Date: Fri, 24 Sep 2021 14:41:07 -0700 [thread overview]
Message-ID: <202109241440.29214C9@keescook> (raw)
In-Reply-To: <87lf3lirxh.fsf@disp2133>
On Fri, Sep 24, 2021 at 04:28:58PM -0500, Eric W. Biederman wrote:
> So everything should work from a locking perspective as I am not
> changing the locking I am simply moving the call from exit_mm earlier.
>
> To explain how the locking works.
>
> Coredumps are not handled in complete_signal, so when
> a thread dequeues the signal the other threads are all running.
>
> If two threads dequeue core dumping signals at the same time both will
> contend for mmap_write_lock one will get it and set core_state the
> second will return -EBUSY from coredump_wait and return from do_coredump
> and proceed to do_exit.
>
> There similar set of races that zap_threads called from coredump_wait
> resolves by testing for signal_group_exit inside of sighand lock.
>
> The normal case is one thread runs through do_coredump, coredump_wait,
> and zap_threads, counts the threads and waits in coredump_wait for
> all of the other threads to stop.
>
> The other threads proceed to do_exit and coredump_task_exit.
> From their the discover that core_state is set. And holding
> the mmap_read_lock is enough to know ensure that either
> no coredump is in progress or all of the setup is complete in
> coredump_wait.
>
> If core_state is found it is known that there is a waiter waiting in
> coredump_wait. So the tasks add themselves to the list. Decrement
> the count to indicate they don't need to be waited for any longer
> and the last one waits up the waiter in coredump_wait.
>
> The threads then spin in TASK_UNINTERRUPTLE until the coredump
> completes.
>
> The dumping thread takes the coredump then calls coredump_finish.
> In coredump_finish the linked list is torn down, and each element
> of the linked list has sets ".task = NULL" Then the task is woken
> up.
>
> The task waiting in TASK_UNINTERRUPTIBLE wakes up. Sees that .task =
> NULL and proceeds with the rest of do_exit.
>
>
> The only change this patch makes to that entire process is
> "task->mm = NULL" is replaced by setting PF_POSTCOREDUMP.
>
> Does that help?
That does! Thanks very much for the run-down on the flow there. I'm
convinced. :)
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
--
Kees Cook
next prev parent reply other threads:[~2021-09-24 21:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-24 0:08 [PATCH 0/6] per signal_struct coredumps Eric W. Biederman
2021-09-24 0:09 ` [PATCH 1/6] signal: Remove the bogus sigkill_pending in ptrace_stop Eric W. Biederman
2021-09-24 15:22 ` Kees Cook
2021-09-24 15:48 ` Eric W. Biederman
2021-09-24 19:06 ` Kees Cook
2021-09-24 0:10 ` [PATCH 2/6] ptrace: Remove the unnecessary arguments from arch_ptrace_stop Eric W. Biederman
2021-09-24 15:26 ` Kees Cook
2021-09-24 0:10 ` [PATCH 3/6] exec: Check for a pending fatal signal instead of core_state Eric W. Biederman
2021-09-24 15:38 ` Kees Cook
2021-09-24 0:11 ` [PATCH 4/6] exit: Factor coredump_exit_mm out of exit_mm Eric W. Biederman
2021-09-24 18:28 ` Kees Cook
2021-09-24 0:11 ` [PATCH 5/6] coredump: Don't perform any cleanups before dumping core Eric W. Biederman
2021-09-24 18:51 ` Kees Cook
2021-09-24 21:28 ` Eric W. Biederman
2021-09-24 21:41 ` Kees Cook [this message]
2021-09-24 0:12 ` [PATCH 6/6] coredump: Limit coredumps to a single thread group Eric W. Biederman
2021-09-24 18:56 ` Kees Cook
2021-10-06 17:03 ` Eric W. Biederman
2021-11-19 16:03 ` Kyle Huey
2021-11-19 17:38 ` Eric W. Biederman
2021-09-24 5:59 ` [PATCH 0/6] per signal_struct coredumps Kees Cook
2021-09-24 14:00 ` Eric W. Biederman
2021-09-24 15:22 ` [PATCH 2/6] ptrace: Remove the unnecessary arguments from arch_ptrace_stop Eric W. Biederman
2021-09-24 15:22 ` Eric W. Biederman
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=202109241440.29214C9@keescook \
--to=keescook@chromium.org \
--cc=ebiederm@xmission.com \
--cc=linux-api@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.