| Message ID | 152474292369.5697.4957552670306451723.stgit@jupiter.in.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | powerpc/fadump: Improvements and fixes for firmware-assisted dump. | expand |
On Thu, 26 Apr 2018 17:12:03 +0530 Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote: > From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> > > otherwise the fadump registration in new kexec-ed kernel complains that > fadump is already registered. This makes new kernel to continue using > fadump registered by previous kernel which may lead to invalid vmcore > generation. Hence this patch fixes this issue by un-registering fadump > in fadump_cleanup() which is called during kexec path so that new kernel > can register fadump with new valid values. I assume this series is for 4.17, but it might be good to get this one into the 4.16 fixes branch? Should it go to stable kernels? > > Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> > --- > arch/powerpc/kernel/fadump.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c > index 8ceabef40d3d..07e8396d472b 100644 > --- a/arch/powerpc/kernel/fadump.c > +++ b/arch/powerpc/kernel/fadump.c > @@ -1180,6 +1180,9 @@ void fadump_cleanup(void) > init_fadump_mem_struct(&fdm, > be64_to_cpu(fdm_active->cpu_state_data.destination_address)); > fadump_invalidate_dump(&fdm); > + } else if (fw_dump.dump_registered) { > + /* Un-register Firmware-assisted dump if it was registered. */ > + fadump_unregister_dump(&fdm); > } > } > >
On 04/26/2018 06:28 PM, Nicholas Piggin wrote: > On Thu, 26 Apr 2018 17:12:03 +0530 > Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote: > >> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> >> >> otherwise the fadump registration in new kexec-ed kernel complains that >> fadump is already registered. This makes new kernel to continue using >> fadump registered by previous kernel which may lead to invalid vmcore >> generation. Hence this patch fixes this issue by un-registering fadump >> in fadump_cleanup() which is called during kexec path so that new kernel >> can register fadump with new valid values. > > I assume this series is for 4.17, but it might be good to get this one > into the 4.16 fixes branch? Should it go to stable kernels? You are right. Should I send it out as separate patch ? > >> >> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> >> --- >> arch/powerpc/kernel/fadump.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c >> index 8ceabef40d3d..07e8396d472b 100644 >> --- a/arch/powerpc/kernel/fadump.c >> +++ b/arch/powerpc/kernel/fadump.c >> @@ -1180,6 +1180,9 @@ void fadump_cleanup(void) >> init_fadump_mem_struct(&fdm, >> be64_to_cpu(fdm_active->cpu_state_data.destination_address)); >> fadump_invalidate_dump(&fdm); >> + } else if (fw_dump.dump_registered) { >> + /* Un-register Firmware-assisted dump if it was registered. */ >> + fadump_unregister_dump(&fdm); >> } >> } >> >> >
On Thu, 26 Apr 2018 18:35:10 +0530 Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> wrote: > On 04/26/2018 06:28 PM, Nicholas Piggin wrote: > > On Thu, 26 Apr 2018 17:12:03 +0530 > > Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote: > > > >> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> > >> > >> otherwise the fadump registration in new kexec-ed kernel complains that > >> fadump is already registered. This makes new kernel to continue using > >> fadump registered by previous kernel which may lead to invalid vmcore > >> generation. Hence this patch fixes this issue by un-registering fadump > >> in fadump_cleanup() which is called during kexec path so that new kernel > >> can register fadump with new valid values. > > > > I assume this series is for 4.17, but it might be good to get this one > > into the 4.16 fixes branch? Should it go to stable kernels? > > You are right. Should I send it out as separate patch ? Yes I think so. Thanks, Nick
On 04/26/2018 07:10 PM, Nicholas Piggin wrote: > On Thu, 26 Apr 2018 18:35:10 +0530 > Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> wrote: > >> On 04/26/2018 06:28 PM, Nicholas Piggin wrote: >>> On Thu, 26 Apr 2018 17:12:03 +0530 >>> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote: >>> >>>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> >>>> >>>> otherwise the fadump registration in new kexec-ed kernel complains that >>>> fadump is already registered. This makes new kernel to continue using >>>> fadump registered by previous kernel which may lead to invalid vmcore >>>> generation. Hence this patch fixes this issue by un-registering fadump >>>> in fadump_cleanup() which is called during kexec path so that new kernel >>>> can register fadump with new valid values. >>> >>> I assume this series is for 4.17, but it might be good to get this one >>> into the 4.16 fixes branch? Should it go to stable kernels? >> >> You are right. Should I send it out as separate patch ? > > Yes I think so. Done posted it separately (http://patchwork.ozlabs.org/patch/905508/) Ignore this patch from this series. Thanks, -Mahesh.
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index 8ceabef40d3d..07e8396d472b 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -1180,6 +1180,9 @@ void fadump_cleanup(void) init_fadump_mem_struct(&fdm, be64_to_cpu(fdm_active->cpu_state_data.destination_address)); fadump_invalidate_dump(&fdm); + } else if (fw_dump.dump_registered) { + /* Un-register Firmware-assisted dump if it was registered. */ + fadump_unregister_dump(&fdm); } }