[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bkdl55qm.fsf@email.froward.int.ebiederm.org>
Date: Fri, 29 Sep 2023 11:00:49 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: "Joel Fernandes (Google)" <joel@...lfernandes.org>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
Ricardo Ribalda <ribalda@...gle.com>,
Ross Zwisler <zwisler@...gle.com>,
Rob Clark <robdclark@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
kexec@...ts.infradead.org
Subject: Re: [PATCH] kexec: Fix reboot race during device_shutdown()
"Joel Fernandes (Google)" <joel@...lfernandes.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@...dmis.org>
> Cc: Ricardo Ribalda <ribalda@...gle.com>
> Cc: Ross Zwisler <zwisler@...gle.com>
> Cc: Rob Clark <robdclark@...il.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Tested-by: Ricardo Ribalda <ribalda@...gle.com>
> Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.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
Powered by blists - more mailing lists