Messages in this thread | | | From | Joel Fernandes <> | Date | Thu, 17 Nov 2022 16:07:39 +0000 | Subject | Re: [PATCH RFC] kexec: Freeze processes before kexec |
| |
On Thu, Nov 17, 2022 at 3:46 PM Philipp Rudo <prudo@redhat.com> wrote:
> On Wed, 16 Nov 2022 15:16:10 -0500 > Steven Rostedt <rostedt@goodmis.org> wrote: > > > On Wed, 16 Nov 2022 19:56:24 +0000 > > "Joel Fernandes (Google)" <joel@joelfernandes.org> 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) { > > > + error = -EBUSY; > > > + goto Unlock; > > > + } > > > > If this is the path of a kernel panic, do we really want to check the > > return error of freeze_processes()? We are panicing, there's not much more > > we can do. > > kernel_kexec isn't called during panic. We don't need to worry about it > here.
Indeed, sorry for my hasty comment and for misleading Steve. This is seen to happen when doing manual kexec from the reboot(2) system call. During a regular panic, machine_shutdown() is not called so this would not happen. However, for testing, the crash is a hurdle.
> Having that said I think this is a problem in the device driver _not_ > in kexec. In my opinion it's the job of the driver to prevent such > races during shutdown.
Thanks a lot for your input. Rob, what do you think?
thanks,
- Joel
| |