ACK: [Utopic][SRU][PATCH] powerpc/kdump: Ignore failure in enabling big endian exception during crash

Brad Figg brad.figg at canonical.com
Thu Jan 15 19:14:56 UTC 2015


On Wed, Jan 14, 2015 at 04:57:07PM -0600, Chris J Arges wrote:
> From: Hari Bathini <hbathini at linux.vnet.ibm.com>
> 
> BugLink: http://bugs.launchpad.net/bugs/1410817
> 
> In LE kernel, we currently have a hack for kexec that resets the exception
> endian before starting a new kernel as the kernel that is loaded could be a
> big endian or a little endian kernel. In kdump case, resetting exception
> endian fails when one or more cpus is disabled. But we can ignore the failure
> and still go ahead, as in most cases crashkernel will be of same endianess
> as primary kernel and reseting endianess is not even needed in those cases.
> This patch adds a new inline function to say if this is kdump path. This
> function is used at places where such a check is needed.
> 
> Signed-off-by: Hari Bathini <hbathini at linux.vnet.ibm.com>
> [mpe: Rename to kdump_in_progress(), use bool, and edit comment]
> Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
> 
> (cherry picked from commit c1caae3de46a072d0855729aed6e793e536a4a55)
> Signed-off-by: Chris J Arges <chris.j.arges at canonical.com>
> ---
>  arch/powerpc/include/asm/kexec.h       | 10 ++++++++++
>  arch/powerpc/kernel/machine_kexec_64.c |  2 +-
>  arch/powerpc/platforms/pseries/lpar.c  |  8 +++++++-
>  3 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
> index 16d7e33..cd4570d 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -87,6 +87,11 @@ extern int overlaps_crashkernel(unsigned long start, unsigned long size);
>  extern void reserve_crashkernel(void);
>  extern void machine_kexec_mask_interrupts(void);
>  
> +static inline bool kdump_in_progress(void)
> +{
> +	return crashing_cpu >= 0;
> +}
> +
>  #else /* !CONFIG_KEXEC */
>  static inline void crash_kexec_secondary(struct pt_regs *regs) { }
>  
> @@ -107,6 +112,11 @@ static inline int crash_shutdown_unregister(crash_shutdown_t handler)
>  	return 0;
>  }
>  
> +static inline bool kdump_in_progress(void)
> +{
> +	return false;
> +}
> +
>  #endif /* CONFIG_KEXEC */
>  #endif /* ! __ASSEMBLY__ */
>  #endif /* __KERNEL__ */
> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
> index a670bf4..eedc904 100644
> --- a/arch/powerpc/kernel/machine_kexec_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_64.c
> @@ -264,7 +264,7 @@ void default_machine_kexec(struct kimage *image)
>          * using debugger IPI.
>          */
>  
> -	if (crashing_cpu == -1)
> +	if (!kdump_in_progress())
>  		kexec_prepare_cpus();
>  
>  	pr_debug("kexec: Starting switchover sequence.\n");
> diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
> index cd50be6..faa7f93 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -42,6 +42,7 @@
>  #include <asm/trace.h>
>  #include <asm/firmware.h>
>  #include <asm/plpar_wrappers.h>
> +#include <asm/kexec.h>
>  #include <asm/fadump.h>
>  
>  #include "pseries.h"
> @@ -268,8 +269,13 @@ static void pSeries_lpar_hptab_clear(void)
>  		 * out to the user, but at least this will stop us from
>  		 * continuing on further and creating an even more
>  		 * difficult to debug situation.
> +		 *
> +		 * There is a known problem when kdump'ing, if cpus are offline
> +		 * the above call will fail. Rather than panicking again, keep
> +		 * going and hope the kdump kernel is also little endian, which
> +		 * it usually is.
>  		 */
> -		if (rc)
> +		if (rc && !kdump_in_progress())
>  			panic("Could not enable big endian exceptions");
>  	}
>  #endif
> -- 
> 1.9.1
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

Looks reasonable

-- 
Brad Figg brad.figg at canonical.com http://www.canonical.com




More information about the kernel-team mailing list