On Thu, Nov 17, 2022 at 3:46 PM Philipp Rudo wrote:
> On Wed, 16 Nov 2022 15:16:10 -0500
> Steven Rostedt wrote:
>
> > On Wed, 16 Nov 2022 19:56:24 +
> > "Joel Fernandes (Google)" wrote:
> >
> > > --- a/kernel/kexec_core.c
> > > +++ b/kernel/kexec_core.c
> > > @@ -1175,6 +1175,12 @@ int
Hi Steve,
On Wed, 16 Nov 2022 15:16:10 -0500
Steven Rostedt wrote:
> On Wed, 16 Nov 2022 19:56:24 +
> "Joel Fernandes (Google)" wrote:
>
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -1175,6 +1175,12 @@ int kernel_kexec(void)
> > } else
> > #endif
> > {
> > +
Hey Steve,
On Wed, Nov 16, 2022 at 8:15 PM Steven Rostedt wrote:
>
> On Wed, 16 Nov 2022 19:56:24 +
> "Joel Fernandes (Google)" wrote:
>
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -1175,6 +1175,12 @@ int kernel_kexec(void)
> > } else
> > #endif
> > {
> >
On Wed, 16 Nov 2022 19:56:24 +
"Joel Fernandes (Google)" wrote:
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1175,6 +1175,12 @@ int kernel_kexec(void)
> } else
> #endif
> {
> + error = freeze_processes();
> + if (error) {
> +
During kexec, it is possible for userspace to race with
device_shutdown() causing accesses to GPU after pm_runtime suspend has
already happened. Fix by freezing userspace before device_shutdown().
Such freezing is already being done if kernel supports KEXEC_JUMP and
kexec_image->preserve_context
