| Message ID | 20210122074214.26583-1-bhe@redhat.com |
|---|---|
| State | Accepted |
| Commit | 56c91a18432b631ca18438841fd1831ef756cabf |
| Headers | show |
| Series | kernel/kexec: remove the lock operation of system_transition_mutex | expand |
On Fri, Jan 22, 2021 at 3:42 PM Baoquan He <bhe@redhat.com> wrote: > > Function kernel_kexec() is called with lock system_transition_mutex held > in reboot system call. While inside kernel_kexec(), it will acquire > system_transition_mutex agin. This will lead to dead lock. > > The dead lock should be easily triggered, it hasn't caused any failure > report just because the feature 'kexec jump' is almost not used by anyone > as far as I know. An inquiry can be made about who is using 'kexec jump' > and where it's used. Before that, let's simply remove the lock operation > inside CONFIG_KEXEC_JUMP ifdeffery scope. > > Signed-off-by: Baoquan He <bhe@redhat.com> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com> > Reviewed-by: Pingfan Liu <kernelfans@gmail.com> > --- > kernel/kexec_core.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index 80905e5aa8ae..a0b6780740c8 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -1134,7 +1134,6 @@ int kernel_kexec(void) > > #ifdef CONFIG_KEXEC_JUMP > if (kexec_image->preserve_context) { > - lock_system_sleep(); > pm_prepare_console(); > error = freeze_processes(); > if (error) { > @@ -1197,7 +1196,6 @@ int kernel_kexec(void) > thaw_processes(); > Restore_console: > pm_restore_console(); > - unlock_system_sleep(); > } > #endif > > -- > 2.17.2 > Reviewed-by: Pingfan Liu <kernelfans@gmail.com>
On Mon, Jan 25, 2021 at 10:05 AM Pingfan Liu <kernelfans@gmail.com> wrote: > > On Fri, Jan 22, 2021 at 3:42 PM Baoquan He <bhe@redhat.com> wrote: > > > > Function kernel_kexec() is called with lock system_transition_mutex held > > in reboot system call. While inside kernel_kexec(), it will acquire > > system_transition_mutex agin. This will lead to dead lock. > > > > The dead lock should be easily triggered, it hasn't caused any failure > > report just because the feature 'kexec jump' is almost not used by anyone > > as far as I know. An inquiry can be made about who is using 'kexec jump' > > and where it's used. Before that, let's simply remove the lock operation > > inside CONFIG_KEXEC_JUMP ifdeffery scope. > > > > Signed-off-by: Baoquan He <bhe@redhat.com> > > Reported-by: Dan Carpenter <dan.carpenter@oracle.com> > > Reviewed-by: Pingfan Liu <kernelfans@gmail.com> > > --- > > kernel/kexec_core.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > > index 80905e5aa8ae..a0b6780740c8 100644 > > --- a/kernel/kexec_core.c > > +++ b/kernel/kexec_core.c > > @@ -1134,7 +1134,6 @@ int kernel_kexec(void) > > > > #ifdef CONFIG_KEXEC_JUMP > > if (kexec_image->preserve_context) { > > - lock_system_sleep(); > > pm_prepare_console(); > > error = freeze_processes(); > > if (error) { > > @@ -1197,7 +1196,6 @@ int kernel_kexec(void) > > thaw_processes(); > > Restore_console: > > pm_restore_console(); > > - unlock_system_sleep(); > > } > > #endif > > > > -- > > 2.17.2 > > > Reviewed-by: Pingfan Liu <kernelfans@gmail.com> Applied as 5.11-rc material, thanks!
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 80905e5aa8ae..a0b6780740c8 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -1134,7 +1134,6 @@ int kernel_kexec(void) #ifdef CONFIG_KEXEC_JUMP if (kexec_image->preserve_context) { - lock_system_sleep(); pm_prepare_console(); error = freeze_processes(); if (error) { @@ -1197,7 +1196,6 @@ int kernel_kexec(void) thaw_processes(); Restore_console: pm_restore_console(); - unlock_system_sleep(); } #endif