From: "Eric W. Biederman" <ebiederm@xmission.com>
To: "Joel Fernandes (Google)" <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
Ricardo Ribalda <ribalda@google.com>,
Ross Zwisler <zwisler@google.com>,
Rob Clark <robdclark@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
kexec@lists.infradead.org
Subject: Re: [PATCH] kexec: Fix reboot race during device_shutdown()
Date: Fri, 29 Sep 2023 11:00:49 -0500 [thread overview]
Message-ID: <87bkdl55qm.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20230929021213.2364883-1-joel@joelfernandes.org> (Joel Fernandes's message of "Fri, 29 Sep 2023 02:12:12 +0000")
"Joel Fernandes (Google)" <joel@joelfernandes.org> writes:
> During kexec reboot, it is possible for a race to occur between
> device_shutdown() and userspace. This causes accesses to GPU after pm_runtime
> suspend has already happened. Fix this by calling freeze_processes() before
> device_shutdown().
Is there any reason why this same race with between sys_kexec and the
adreno_ioctl can not happen during a normal reboot?
Is there any reason why there is not a .shutdown method to prevent the
race?
I would think the thing to do is to prevent this race in
kernel_restart_prepare or in the GPUs .shutdown method. As I don't see
anything that would prevent this during a normal reboot.
>
> Such freezing is already being done if kernel supports KEXEC_JUMP and
> kexec_image->preserve_context is true. However, doing it if either of these are
> not true prevents crashes/races.
The KEXEC_JUMP case is something else entirely. It is supposed to work
like suspend to RAM. Maybe reboot should as well, but I am
uncomfortable making a generic device fix kexec specific.
> This fixes the following crash during kexec reboot on an ARM64 device
> with adreno GPU:
>
> [ 292.534314] Kernel panic - not syncing: Asynchronous SError Interrupt
> [ 292.534323] Hardware name: Google Lazor (rev3 - 8) with LTE (DT)
> [ 292.534326] Call trace:
> [ 292.534328] dump_backtrace+0x0/0x1d4
> [ 292.534337] show_stack+0x20/0x2c
> [ 292.534342] dump_stack_lvl+0x60/0x78
> [ 292.534347] dump_stack+0x18/0x38
> [ 292.534352] panic+0x148/0x3b0
> [ 292.534357] nmi_panic+0x80/0x94
> [ 292.534364] arm64_serror_panic+0x70/0x7c
> [ 292.534369] do_serror+0x0/0x7c
> [ 292.534372] do_serror+0x54/0x7c
> [ 292.534377] el1h_64_error_handler+0x34/0x4c
> [ 292.534381] el1h_64_error+0x7c/0x80
> [ 292.534386] el1_interrupt+0x20/0x58
> [ 292.534389] el1h_64_irq_handler+0x18/0x24
> [ 292.534395] el1h_64_irq+0x7c/0x80
> [ 292.534399] local_daif_inherit+0x10/0x18
> [ 292.534405] el1h_64_sync_handler+0x48/0xb4
> [ 292.534410] el1h_64_sync+0x7c/0x80
> [ 292.534414] a6xx_gmu_set_oob+0xbc/0x1fc
> [ 292.534422] a6xx_get_timestamp+0x40/0xb4
> [ 292.534426] adreno_get_param+0x12c/0x1e0
> [ 292.534433] msm_ioctl_get_param+0x64/0x70
> [ 292.534440] drm_ioctl_kernel+0xe8/0x158
> [ 292.534448] drm_ioctl+0x208/0x320
> [ 292.534453] __arm64_sys_ioctl+0x98/0xd0
> [ 292.534461] invoke_syscall+0x4c/0x118
>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Ricardo Ribalda <ribalda@google.com>
> Cc: Ross Zwisler <zwisler@google.com>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Tested-by: Ricardo Ribalda <ribalda@google.com>
> Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
> ---
> kernel/kexec_core.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index e2f2574d8b74..6599f485e42d 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1299,6 +1299,12 @@ int kernel_kexec(void)
> } else
> #endif
> {
> + error = freeze_processes();
> + if (error) {
> + error = -EBUSY;
> + goto Unlock;
> + }
> +
> kexec_in_progress = true;
> kernel_restart_prepare("kexec reboot");
> migrate_to_reboot_cpu();
Eric
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2023-09-29 16:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-29 2:12 [PATCH] kexec: Fix reboot race during device_shutdown() Joel Fernandes (Google)
2023-09-29 16:00 ` Eric W. Biederman [this message]
2023-10-02 18:18 ` Joel Fernandes
2023-10-08 1:30 ` Joel Fernandes
2023-10-09 14:01 ` Steven Rostedt
2023-10-10 20:43 ` Joel Fernandes
2023-10-09 15:21 ` Eric W. Biederman
2023-10-10 20:37 ` Joel Fernandes
2023-10-10 21:07 ` Eric W. Biederman
2023-10-11 15:52 ` Joel Fernandes
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=87bkdl55qm.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=joel@joelfernandes.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ribalda@google.com \
--cc=robdclark@gmail.com \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=zwisler@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox