All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <linux-kernel@vger.kernel.org>, Oleg Nesterov <oleg@redhat.com>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Kees Cook <keescook@chromium.org>, <linux-api@vger.kernel.org>
Subject: [GIT PULL] per signal_struct coredumps
Date: Wed, 03 Nov 2021 14:07:36 -0500	[thread overview]
Message-ID: <878ry512iv.fsf@disp2133> (raw)


Linus,

Please pull the per_signal_struct_coredumps-for-v5.16 branch from the git tree:

  git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git per_signal_struct_coredumps-for-v5.16

  HEAD: 3f66f86bfed33dee2e9c1d0e14486915bb0750b0 per signal_struct coredumps


Current coredumps are mixed up with the exit code, the signal handling
code, and the ptrace code making coredumps much more complicated than
necessary and difficult to follow.

This series of changes starts with ptrace_stop and cleans it up,
making it easier to follow what is happening in ptrace_stop.
Then cleans up the exec interactions with coredumps.
Then cleans up the coredump interactions with exit.
Then the coredump interactions with the signal handling code is cleaned
up.

The first and last changes are bug fixes for minor bugs.

I believe the fact that vfork followed by execve can kill the process
the called vfork if exec fails is sufficient justification to change
the userspace visible behavior.

In previous discussions some of these changes were organized differently
and individually appeared to make the code base worse.  As currently
written I believe they all stand on their own as cleanups and bug fixes.

Which means that even if the worst should happen and the last change
needs to be reverted for some unimaginable reason, the code base will
still be improved.

If the worst does not happen there are a more cleanups that can be made.
Signals that generate coredumps can easily become eligible for short
circuit delivery in complete_signal.  The entire rendezvous for
generating a coredump can move into get_signal.  The function
force_sig_info_to_task be written in a way that does not modify the
signal handling state of the target task (because coredumps are eligible
for short circuit delivery).  Many of these future cleanups can be done
another way but nothing so cleanly as if coredumps become per
signal_struct.

Eric W. Biederman (7):
      signal: Remove the bogus sigkill_pending in ptrace_stop
      ptrace: Remove the unnecessary arguments from arch_ptrace_stop
      exec: Check for a pending fatal signal instead of core_state
      exit: Factor coredump_exit_mm out of exit_mm
      coredump:  Don't perform any cleanups before dumping core
      coredump: Limit coredumps to a single thread group
      per signal_struct coredumps

 arch/ia64/include/asm/ptrace.h  |  4 +-
 arch/sparc/include/asm/ptrace.h |  8 ++--
 fs/binfmt_elf.c                 |  4 +-
 fs/binfmt_elf_fdpic.c           |  2 +-
 fs/coredump.c                   | 88 ++++++-----------------------------------
 fs/exec.c                       | 14 +++----
 fs/proc/array.c                 |  6 +--
 include/linux/mm_types.h        | 13 ------
 include/linux/ptrace.h          | 22 +++++------
 include/linux/sched.h           |  1 +
 include/linux/sched/signal.h    | 13 ++++++
 kernel/exit.c                   | 76 +++++++++++++++++++----------------
 kernel/fork.c                   |  4 +-
 kernel/signal.c                 | 49 ++++-------------------
 mm/debug.c                      |  4 +-
 mm/oom_kill.c                   |  6 +--
 16 files changed, 106 insertions(+), 208 deletions(-)

Link: https://lkml.kernel.org/r/87v92qx2c6.fsf@disp2133
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

Eric

             reply	other threads:[~2021-11-03 19:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03 19:07 Eric W. Biederman [this message]
2021-11-03 19:32 ` [GIT PULL] per signal_struct coredumps pr-tracker-bot
2021-11-03 19:34 ` Linus Torvalds
2021-11-05 16:37   ` Eric W. Biederman
2021-11-13 19:14     ` Linus Torvalds
2021-11-14  6:32       ` Junio C Hamano
2021-11-14  9:36         ` Ævar Arnfjörð Bjarmason
2021-11-14 17:16         ` Eric W. Biederman
2021-11-16  6:49           ` Junio C Hamano
2021-11-16  8:29           ` Junio C Hamano
2021-11-16 15:14             ` Eric W. Biederman
2021-11-18  9:29             ` Junio C Hamano

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=878ry512iv.fsf@disp2133 \
    --to=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --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.