All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Kees Cook <keescook@chromium.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	openrisc@lists.librecores.org, Nick Hu <nickhu@andestech.com>,
	Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	linux-s390@vger.kernel.org,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	linux-sh@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	Chris Zankel <chris@zankel.net>,
	Max Filippov <jcmvbkbc@gmail.com>
Subject: Re: [PATCH 02/20] exit: Remove calls of do_exit after noreturn versions of die
Date: Thu, 21 Oct 2021 11:25:08 -0500	[thread overview]
Message-ID: <87cznycpln.fsf@disp2133> (raw)
In-Reply-To: <202110210858.41719190D2@keescook> (Kees Cook's message of "Thu, 21 Oct 2021 09:02:04 -0700")

Kees Cook <keescook@chromium.org> writes:

> On Wed, Oct 20, 2021 at 12:43:48PM -0500, Eric W. Biederman wrote:
>> On nds32, openrisc, s390, sh, and xtensa the function die never
>> returns.  Mark die __noreturn so that no one expects die to return.
>> Remove the do_exit calls after die as they will never be reached.
>
> Maybe note that the "bust_spinlocks" calls are also redundant, since
> they're in die(). I note that is a "mismatch" between the do_kill()
> in die() (SIGSEGV) and after die() (SIGKILL). This patch makes no
> behavioral change (the first caller would "win"), but I thought I'd note
> it in case some architecture would prefer a different signal.

If someone has some strong preferences in the matter of which signal a
wait on a processes that has oopsed should return please let me know.

My next step in cleaning up the uses of do_exit looks like it is going
to be getting all of the architectures to use the same signal for oopses
(aka die), and then introducing a helper (called something like
"make_task_dead" or "oops_task_exit" ) that will replace do_exit on the
oops path and not take a signal number at all.

That helper I can then remove the ptrace break point from and possibly
some of the coredump logic as well.  Ultimately it will be something
we can optimize for the case when we know there is a kernel bug and we
just want the task to exit so the rest of the system can limp along
as best as it can.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric W. Biederman <ebiederm@xmission.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 02/20] exit: Remove calls of do_exit after noreturn versions of die
Date: Thu, 21 Oct 2021 11:25:08 -0500	[thread overview]
Message-ID: <87cznycpln.fsf@disp2133> (raw)
In-Reply-To: <202110210858.41719190D2@keescook> (Kees Cook's message of "Thu,  21 Oct 2021 09:02:04 -0700")

Kees Cook <keescook@chromium.org> writes:

> On Wed, Oct 20, 2021 at 12:43:48PM -0500, Eric W. Biederman wrote:
>> On nds32, openrisc, s390, sh, and xtensa the function die never
>> returns.  Mark die __noreturn so that no one expects die to return.
>> Remove the do_exit calls after die as they will never be reached.
>
> Maybe note that the "bust_spinlocks" calls are also redundant, since
> they're in die(). I note that is a "mismatch" between the do_kill()
> in die() (SIGSEGV) and after die() (SIGKILL). This patch makes no
> behavioral change (the first caller would "win"), but I thought I'd note
> it in case some architecture would prefer a different signal.

If someone has some strong preferences in the matter of which signal a
wait on a processes that has oopsed should return please let me know.

My next step in cleaning up the uses of do_exit looks like it is going
to be getting all of the architectures to use the same signal for oopses
(aka die), and then introducing a helper (called something like
"make_task_dead" or "oops_task_exit" ) that will replace do_exit on the
oops path and not take a signal number at all.

That helper I can then remove the ptrace break point from and possibly
some of the coredump logic as well.  Ultimately it will be something
we can optimize for the case when we know there is a kernel bug and we
just want the task to exit so the rest of the system can limp along
as best as it can.

Eric

  reply	other threads:[~2021-10-21 16:25 UTC|newest]

Thread overview: 110+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20 17:32 [PATCH 00/20] exit cleanups Eric W. Biederman
2021-10-20 17:32 ` [OpenRISC] " Eric W. Biederman
2021-10-20 17:32 ` Eric W. Biederman
2021-10-20 17:43 ` [PATCH 01/20] exit/doublefault: Remove apparently bogus comment about rewind_stack_do_exit Eric W. Biederman
2021-10-21 16:02   ` Kees Cook
2021-10-20 17:43 ` [PATCH 02/20] exit: Remove calls of do_exit after noreturn versions of die Eric W. Biederman
2021-10-20 17:43   ` [OpenRISC] " Eric W. Biederman
2021-10-21 16:02   ` Kees Cook
2021-10-21 16:02     ` [OpenRISC] " Kees Cook
2021-10-21 16:25     ` Eric W. Biederman [this message]
2021-10-21 16:25       ` Eric W. Biederman
2021-10-20 17:43 ` [PATCH 03/20] reboot: Remove the unreachable panic after do_exit in reboot(2) Eric W. Biederman
2021-10-21 16:05   ` Kees Cook
2021-10-20 17:43 ` [PATCH 04/20] signal/sparc32: Remove unreachable do_exit in do_sparc_fault Eric W. Biederman
2021-10-21 16:05   ` Kees Cook
2021-10-20 17:43 ` [PATCH 05/20] signal/mips: Update (_save|_restore)_fp_context to fail with -EFAULT Eric W. Biederman
2021-10-21 16:06   ` Kees Cook
2021-10-24  4:24   ` Maciej W. Rozycki
2021-10-25 20:55     ` Eric W. Biederman
2021-10-24 15:27   ` Thomas Bogendoerfer
2021-10-20 17:43 ` [PATCH 06/20] signal/sh: Use force_sig(SIGKILL) instead of do_group_exit(SIGKILL) Eric W. Biederman
2021-10-20 19:57   ` Linus Torvalds
2021-10-27 14:24     ` Rich Felker
2021-10-21 16:08   ` Kees Cook
2021-10-20 17:43 ` [PATCH 07/20] signal/powerpc: On swapcontext failure force SIGSEGV Eric W. Biederman
2021-10-20 17:43   ` Eric W. Biederman
2021-10-21 16:09   ` Kees Cook
2021-10-21 16:09     ` Kees Cook
2021-10-20 17:43 ` [PATCH 08/20] signal/sparc: In setup_tsb_params convert open coded BUG into BUG Eric W. Biederman
2021-10-21 16:12   ` Kees Cook
2021-10-20 17:43 ` [PATCH 09/20] signal/vm86_32: Replace open coded BUG_ON with an actual BUG_ON Eric W. Biederman
2021-10-21 16:15   ` Kees Cook
2021-11-12 15:40   ` Eric W. Biederman
2021-11-12 17:51     ` Brian Gerst
2021-11-12 19:57       ` Eric W. Biederman
2021-11-12 20:40         ` Linus Torvalds
2021-11-12 21:03           ` Eric W. Biederman
2021-11-12 21:23             ` Linus Torvalds
2021-11-12 21:24               ` Linus Torvalds
2021-11-12 21:37                 ` [GIT PULL ] signal/vm86_32: Remove pointless test in BUG_ON Eric W. Biederman
2021-11-13 19:15                   ` pr-tracker-bot
2021-11-12 21:43                 ` [PATCH 09/20] signal/vm86_32: Replace open coded BUG_ON with an actual BUG_ON Eric W. Biederman
2021-10-20 17:43 ` [PATCH 10/20] signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved Eric W. Biederman
2021-10-21 16:16   ` Kees Cook
2021-10-21 17:02     ` Eric W. Biederman
2021-10-21 20:33       ` Kees Cook
2021-10-21 23:08   ` Andy Lutomirski
2021-10-24 16:06     ` Eric W. Biederman
     [not found]   ` <875ytkygfj.fsf_-_@disp2133>
2021-10-25 21:12     ` [PATCH v2 10/32] " Linus Torvalds
2021-10-25 21:28       ` Eric W. Biederman
2021-10-25 22:25     ` Andy Lutomirski
2021-10-25 23:45       ` Linus Torvalds
2021-10-26  0:21         ` Andy Lutomirski
2021-10-20 17:43 ` [PATCH 11/20] signal/s390: Use force_sigsegv in default_trap_handler Eric W. Biederman
2021-10-21 16:17   ` Kees Cook
2021-10-26  9:38   ` Christian Borntraeger
2021-10-28 15:56     ` Eric W. Biederman
2021-10-29 19:32       ` Eric W. Biederman
2021-10-20 17:43 ` [PATCH 12/20] exit/kthread: Have kernel threads return instead of calling do_exit Eric W. Biederman
2021-10-21 11:12   ` Christoph Hellwig
2021-10-21 15:11     ` Eric W. Biederman
2021-10-21 16:21   ` Kees Cook
2021-10-20 17:43 ` [PATCH 13/20] signal: Implement force_fatal_sig Eric W. Biederman
2021-10-20 20:05   ` Linus Torvalds
2021-10-20 21:25     ` Eric W. Biederman
2021-10-25 22:41     ` Andy Lutomirski
2021-10-25 23:15       ` Linus Torvalds
2021-10-26  4:45         ` Eric W. Biederman
2021-10-26  4:57         ` Eric W. Biederman
2021-10-26 16:15           ` Linus Torvalds
2021-10-28 16:33             ` Eric W. Biederman
2021-10-21 16:24   ` Kees Cook
2021-10-21 16:33     ` Eric W. Biederman
2021-10-21 16:39       ` Kees Cook
2021-10-20 17:44 ` [PATCH 14/20] exit/syscall_user_dispatch: Send ordinary signals on failure Eric W. Biederman
2021-10-21 16:25   ` Kees Cook
2021-10-21 16:37     ` Eric W. Biederman
2021-10-21 16:40       ` Kees Cook
2021-10-21 17:05         ` Eric W. Biederman
2021-10-25 22:32     ` Andy Lutomirski
2021-10-21 16:35   ` Gabriel Krisman Bertazi
2021-10-20 17:44 ` [PATCH 15/20] signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails Eric W. Biederman
2021-10-21 16:34   ` Kees Cook
2021-10-21 16:56     ` Eric W. Biederman
2021-10-20 17:44 ` [PATCH 16/20] signal/sparc32: In setup_rt_frame and setup_fram use force_fatal_sig Eric W. Biederman
2021-10-21 16:34   ` Kees Cook
2021-10-20 17:44 ` [PATCH 17/20] signal/x86: In emulate_vsyscall force a signal instead of calling do_exit Eric W. Biederman
2021-10-21 16:36   ` Kees Cook
2021-10-20 17:44 ` [PATCH 18/20] exit/rtl8723bs: Replace the macro thread_exit with a simple return 0 Eric W. Biederman
2021-10-21  7:06   ` Greg KH
2021-10-21 15:06     ` Eric W. Biederman
2021-10-21 16:37   ` Kees Cook
2021-10-20 17:44 ` [PATCH 19/20] exit/rtl8712: " Eric W. Biederman
2021-10-21  7:07   ` Greg KH
2021-10-21 16:37   ` Kees Cook
2021-10-20 17:44 ` [PATCH 20/20] exit/r8188eu: " Eric W. Biederman
2021-10-21  7:07   ` Greg KH
2021-10-21 16:37   ` Kees Cook
2021-10-20 21:51 ` [PATCH 21/20] signal: Replace force_sigsegv(SIGSEGV) with force_fatal_sig(SIGSEGV) Eric W. Biederman
2021-10-20 21:51   ` [OpenRISC] " Eric W. Biederman
2021-10-20 21:51   ` Eric W. Biederman
2021-10-21  8:09   ` Geert Uytterhoeven
2021-10-21  8:09     ` [OpenRISC] " Geert Uytterhoeven
2021-10-21  8:09     ` Geert Uytterhoeven
2021-10-21 13:33     ` Eric W. Biederman
2021-10-21 13:33       ` [OpenRISC] " Eric W. Biederman
2021-10-21 13:33       ` Eric W. Biederman
2021-10-21  8:32   ` Philippe Mathieu-Daudé
2021-10-21  8:32     ` [OpenRISC] " Philippe =?unknown-8bit?q?Mathieu-Daud=C3=A9?=
2021-10-21  8:32     ` Philippe Mathieu-Daudé

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=87cznycpln.fsf@disp2133 \
    --to=ebiederm@xmission.com \
    --cc=borntraeger@de.ibm.com \
    --cc=chris@zankel.net \
    --cc=dalias@libc.org \
    --cc=deanbo422@gmail.com \
    --cc=gor@linux.ibm.com \
    --cc=green.hu@gmail.com \
    --cc=hca@linux.ibm.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=jonas@southpole.se \
    --cc=keescook@chromium.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=nickhu@andestech.com \
    --cc=oleg@redhat.com \
    --cc=openrisc@lists.librecores.org \
    --cc=shorne@gmail.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=ysato@users.sourceforge.jp \
    /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.