[PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 12, 2017 at 12:01:11PM +0000, Will Deacon wrote:
> On Thu, Jan 12, 2017 at 01:21:44PM +0900, AKASHI Takahiro wrote:
> > On Wed, Jan 11, 2017 at 10:54:05AM +0000, Will Deacon wrote:
> > > On Wed, Jan 11, 2017 at 03:36:28PM +0900, AKASHI Takahiro wrote:
> > > > On Tue, Jan 10, 2017 at 11:32:48AM +0000, Will Deacon wrote:
> > > > > On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote:
> > > > > > @@ -22,6 +25,7 @@
> > > > > >  extern const unsigned char arm64_relocate_new_kernel[];
> > > > > >  extern const unsigned long arm64_relocate_new_kernel_size;
> > > > > >  
> > > > > > +static bool in_crash_kexec;
> > > > > 
> > > > > Do you actually need this bool? Why not call kexec_crash_loaded() instead?
> > > > 
> > > > The two have different meanings:
> > > > "in_crash_kexec" indicates that kdump is taking place, while
> > > > kexec_crash_loaded() tells us only whether crash dump kernel has been
> > > > loaded or not.
> > > > 
> > > > It is crucial to distinguish them especially for machine_kexec()
> > > > which can be called on normal kexec even if kdump has been set up.
> > > 
> > > Ah, I see. So how about just doing:
> > > 
> > >   if (kimage == kexec_crash_image)
> > > 
> > > in machine_kexec?
> > 
> > Yeah, it should work.
> > Do you want to merge the following hunk,
> > or expect that I will re-send the whole patch series
> > (with other changes if any)?
> 
> Thanks, I'll fold it in and shout if I run into any problems. My plan is
> to queue this for 4.11.

Given the DT discussion with Mark, I assume you'll post a new version with
this rolled in.

Will



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux