From: Will Deacon <will@kernel.org> To: Kees Cook <keescook@chromium.org> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, contact@xogium.me, Russell King <linux@armlinux.org.uk>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Ingo Molnar <mingo@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, stable@vger.kernel.org, Feng Tang <feng.tang@intel.com>, Petr Mladek <pmladek@suse.com>, Steven Rostedt <rostedt@goodmis.org>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Subject: Re: [PATCH] panic: Ensure preemption is disabled during panic() Date: Thu, 3 Oct 2019 21:56:34 +0100 [thread overview] Message-ID: <20191003205633.w26geqhq67u4ysit@willie-the-truck> (raw) In-Reply-To: <201910021355.E578D2FFAF@keescook> Hi Kees, On Wed, Oct 02, 2019 at 01:58:46PM -0700, Kees Cook wrote: > On Wed, Oct 02, 2019 at 01:35:38PM +0100, Will Deacon wrote: > > Calling 'panic()' on a kernel with CONFIG_PREEMPT=y can leave the > > calling CPU in an infinite loop, but with interrupts and preemption > > enabled. From this state, userspace can continue to be scheduled, > > despite the system being "dead" as far as the kernel is concerned. This > > is easily reproducible on arm64 when booting with "nosmp" on the command > > line; a couple of shell scripts print out a periodic "Ping" message > > whilst another triggers a crash by writing to /proc/sysrq-trigger: > > > > | sysrq: Trigger a crash > > | Kernel panic - not syncing: sysrq triggered crash > > | CPU: 0 PID: 1 Comm: init Not tainted 5.2.15 #1 > > | Hardware name: linux,dummy-virt (DT) > > | Call trace: > > | dump_backtrace+0x0/0x148 > > | show_stack+0x14/0x20 > > | dump_stack+0xa0/0xc4 > > | panic+0x140/0x32c > > | sysrq_handle_reboot+0x0/0x20 > > | __handle_sysrq+0x124/0x190 > > | write_sysrq_trigger+0x64/0x88 > > | proc_reg_write+0x60/0xa8 > > | __vfs_write+0x18/0x40 > > | vfs_write+0xa4/0x1b8 > > | ksys_write+0x64/0xf0 > > | __arm64_sys_write+0x14/0x20 > > | el0_svc_common.constprop.0+0xb0/0x168 > > | el0_svc_handler+0x28/0x78 > > | el0_svc+0x8/0xc > > | Kernel Offset: disabled > > | CPU features: 0x0002,24002004 > > | Memory Limit: none > > | ---[ end Kernel panic - not syncing: sysrq triggered crash ]--- > > | Ping 2! > > | Ping 1! > > | Ping 1! > > | Ping 2! > > > > The issue can also be triggered on x86 kernels if CONFIG_SMP=n, otherwise > > local interrupts are disabled in 'smp_send_stop()'. > > > > Disable preemption in 'panic()' before re-enabling interrupts. > > Is this perhaps the correct solution for what commit c39ea0b9dd24 ("panic: > avoid the extra noise dmesg") was trying to fix? Hmm, maybe, although that looks like it's focussed more on irq handling than preemption. I've deliberately left the irq part alone, since I think having magic sysrq work via the keyboard interrupt is desirable from the panic loop. > Reviewed-by: Kees Cook <keescook@chromium.org> Thanks! Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org> To: Kees Cook <keescook@chromium.org> Cc: Petr Mladek <pmladek@suse.com>, Feng Tang <feng.tang@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, contact@xogium.me, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Russell King <linux@armlinux.org.uk>, Sergey Senozhatsky <sergey.senozhatsky@gmail.com>, Ingo Molnar <mingo@redhat.com>, Steven Rostedt <rostedt@goodmis.org>, Andrew Morton <akpm@linux-foundation.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] panic: Ensure preemption is disabled during panic() Date: Thu, 3 Oct 2019 21:56:34 +0100 [thread overview] Message-ID: <20191003205633.w26geqhq67u4ysit@willie-the-truck> (raw) In-Reply-To: <201910021355.E578D2FFAF@keescook> Hi Kees, On Wed, Oct 02, 2019 at 01:58:46PM -0700, Kees Cook wrote: > On Wed, Oct 02, 2019 at 01:35:38PM +0100, Will Deacon wrote: > > Calling 'panic()' on a kernel with CONFIG_PREEMPT=y can leave the > > calling CPU in an infinite loop, but with interrupts and preemption > > enabled. From this state, userspace can continue to be scheduled, > > despite the system being "dead" as far as the kernel is concerned. This > > is easily reproducible on arm64 when booting with "nosmp" on the command > > line; a couple of shell scripts print out a periodic "Ping" message > > whilst another triggers a crash by writing to /proc/sysrq-trigger: > > > > | sysrq: Trigger a crash > > | Kernel panic - not syncing: sysrq triggered crash > > | CPU: 0 PID: 1 Comm: init Not tainted 5.2.15 #1 > > | Hardware name: linux,dummy-virt (DT) > > | Call trace: > > | dump_backtrace+0x0/0x148 > > | show_stack+0x14/0x20 > > | dump_stack+0xa0/0xc4 > > | panic+0x140/0x32c > > | sysrq_handle_reboot+0x0/0x20 > > | __handle_sysrq+0x124/0x190 > > | write_sysrq_trigger+0x64/0x88 > > | proc_reg_write+0x60/0xa8 > > | __vfs_write+0x18/0x40 > > | vfs_write+0xa4/0x1b8 > > | ksys_write+0x64/0xf0 > > | __arm64_sys_write+0x14/0x20 > > | el0_svc_common.constprop.0+0xb0/0x168 > > | el0_svc_handler+0x28/0x78 > > | el0_svc+0x8/0xc > > | Kernel Offset: disabled > > | CPU features: 0x0002,24002004 > > | Memory Limit: none > > | ---[ end Kernel panic - not syncing: sysrq triggered crash ]--- > > | Ping 2! > > | Ping 1! > > | Ping 1! > > | Ping 2! > > > > The issue can also be triggered on x86 kernels if CONFIG_SMP=n, otherwise > > local interrupts are disabled in 'smp_send_stop()'. > > > > Disable preemption in 'panic()' before re-enabling interrupts. > > Is this perhaps the correct solution for what commit c39ea0b9dd24 ("panic: > avoid the extra noise dmesg") was trying to fix? Hmm, maybe, although that looks like it's focussed more on irq handling than preemption. I've deliberately left the irq part alone, since I think having magic sysrq work via the keyboard interrupt is desirable from the panic loop. > Reviewed-by: Kees Cook <keescook@chromium.org> Thanks! Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-03 20:56 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-02 12:35 [PATCH] panic: Ensure preemption is disabled during panic() Will Deacon 2019-10-02 12:35 ` Will Deacon 2019-10-02 20:58 ` Kees Cook 2019-10-02 20:58 ` Kees Cook 2019-10-03 20:56 ` Will Deacon [this message] 2019-10-03 20:56 ` Will Deacon 2019-10-04 9:11 ` Petr Mladek 2019-10-04 9:11 ` Petr Mladek 2019-10-04 9:29 ` Russell King - ARM Linux admin 2019-10-04 9:29 ` Russell King - ARM Linux admin 2019-10-04 10:49 ` Will Deacon 2019-10-04 10:49 ` Will Deacon 2019-10-04 11:15 ` Petr Mladek 2019-10-04 11:15 ` Petr Mladek 2019-10-04 13:51 ` Feng Tang 2019-10-04 13:51 ` Feng Tang 2019-10-07 8:02 ` Jiri Kosina 2019-10-07 8:02 ` Jiri Kosina 2019-10-02 21:45 ` Andrew Morton 2019-10-02 21:45 ` Andrew Morton 2019-10-03 20:53 ` Will Deacon 2019-10-03 20:53 ` Will Deacon
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=20191003205633.w26geqhq67u4ysit@willie-the-truck \ --to=will@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=contact@xogium.me \ --cc=feng.tang@intel.com \ --cc=gregkh@linuxfoundation.org \ --cc=keescook@chromium.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=mingo@redhat.com \ --cc=pmladek@suse.com \ --cc=rostedt@goodmis.org \ --cc=sergey.senozhatsky@gmail.com \ --cc=stable@vger.kernel.org \ /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: linkBe 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.