* [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch @ 2014-05-03 13:44 ` Liu Hua 0 siblings, 0 replies; 8+ messages in thread From: Liu Hua @ 2014-05-03 13:44 UTC (permalink / raw) To: linux-arm-kernel Hi Will or Russell, With CONFIG_LPAE=y, memory in 32-bit ARM systems can exceed 4G. So if we use kdump in such systems. The capture kernel should parse 64-bit elf header(parse_crash_elf64_headers). And this process can not pass because ARM linux only provides zero vmcore_elf64_check_arch function by commit 4b3bf7aef. This patch adds check functions related to elf64 header. Thanks, Liu Hua Signed-off-by: Liu Hua <sdu.liu@huawei.com> --- arch/arm/include/asm/elf.h | 4 +++- arch/arm/kernel/elf.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h index f4b46d3..8651699 100644 --- a/arch/arm/include/asm/elf.h +++ b/arch/arm/include/asm/elf.h @@ -90,14 +90,16 @@ typedef struct user_fp elf_fpregset_t; extern char elf_platform[]; struct elf32_hdr; +struct elf64_hdr; /* * This is used to ensure we don't load something for the wrong architecture. */ extern int elf_check_arch(const struct elf32_hdr *); +extern int elf_check_arch_64(const struct elf64_hdr *); #define elf_check_arch elf_check_arch -#define vmcore_elf64_check_arch(x) (0) +#define vmcore_elf64_check_arch(x) (elf_check_arch_64(x)) extern int arm_elf_read_implies_exec(const struct elf32_hdr *, int); #define elf_read_implies_exec(ex,stk) arm_elf_read_implies_exec(&(ex), stk) diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c index d0d1e83..452086a 100644 --- a/arch/arm/kernel/elf.c +++ b/arch/arm/kernel/elf.c @@ -38,6 +38,39 @@ int elf_check_arch(const struct elf32_hdr *x) } EXPORT_SYMBOL(elf_check_arch); +int elf_check_arch_64(const struct elf64_hdr *x) +{ + unsigned int eflags; + + /* Make sure it's an ARM executable */ + if (x->e_machine != EM_ARM) + return 0; + + /* Make sure the entry address is reasonable */ + if (x->e_entry & 1) { + if (!(elf_hwcap & HWCAP_THUMB)) + return 0; + } else if (x->e_entry & 3) + return 0; + + eflags = x->e_flags; + if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN) { + unsigned int flt_fmt; + + /* APCS26 is only allowed if the CPU supports it */ + if ((eflags & EF_ARM_APCS_26) && !(elf_hwcap & HWCAP_26BIT)) + return 0; + + flt_fmt = eflags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT); + + /* VFP requires the supporting code */ + if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) + return 0; + } + return 1; +} +EXPORT_SYMBOL(elf_check_arch_64); + void elf_set_personality(const struct elf32_hdr *x) { unsigned int eflags = x->e_flags; -- 1.9.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch @ 2014-05-03 13:44 ` Liu Hua 0 siblings, 0 replies; 8+ messages in thread From: Liu Hua @ 2014-05-03 13:44 UTC (permalink / raw) To: will.deacon, linux Cc: mika.westerberg, alonid, catalin.marinas, linux-kernel, linux-arm-kernel, peifeiyue, wangnan0, Liu Hua Hi Will or Russell, With CONFIG_LPAE=y, memory in 32-bit ARM systems can exceed 4G. So if we use kdump in such systems. The capture kernel should parse 64-bit elf header(parse_crash_elf64_headers). And this process can not pass because ARM linux only provides zero vmcore_elf64_check_arch function by commit 4b3bf7aef. This patch adds check functions related to elf64 header. Thanks, Liu Hua Signed-off-by: Liu Hua <sdu.liu@huawei.com> --- arch/arm/include/asm/elf.h | 4 +++- arch/arm/kernel/elf.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h index f4b46d3..8651699 100644 --- a/arch/arm/include/asm/elf.h +++ b/arch/arm/include/asm/elf.h @@ -90,14 +90,16 @@ typedef struct user_fp elf_fpregset_t; extern char elf_platform[]; struct elf32_hdr; +struct elf64_hdr; /* * This is used to ensure we don't load something for the wrong architecture. */ extern int elf_check_arch(const struct elf32_hdr *); +extern int elf_check_arch_64(const struct elf64_hdr *); #define elf_check_arch elf_check_arch -#define vmcore_elf64_check_arch(x) (0) +#define vmcore_elf64_check_arch(x) (elf_check_arch_64(x)) extern int arm_elf_read_implies_exec(const struct elf32_hdr *, int); #define elf_read_implies_exec(ex,stk) arm_elf_read_implies_exec(&(ex), stk) diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c index d0d1e83..452086a 100644 --- a/arch/arm/kernel/elf.c +++ b/arch/arm/kernel/elf.c @@ -38,6 +38,39 @@ int elf_check_arch(const struct elf32_hdr *x) } EXPORT_SYMBOL(elf_check_arch); +int elf_check_arch_64(const struct elf64_hdr *x) +{ + unsigned int eflags; + + /* Make sure it's an ARM executable */ + if (x->e_machine != EM_ARM) + return 0; + + /* Make sure the entry address is reasonable */ + if (x->e_entry & 1) { + if (!(elf_hwcap & HWCAP_THUMB)) + return 0; + } else if (x->e_entry & 3) + return 0; + + eflags = x->e_flags; + if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN) { + unsigned int flt_fmt; + + /* APCS26 is only allowed if the CPU supports it */ + if ((eflags & EF_ARM_APCS_26) && !(elf_hwcap & HWCAP_26BIT)) + return 0; + + flt_fmt = eflags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT); + + /* VFP requires the supporting code */ + if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) + return 0; + } + return 1; +} +EXPORT_SYMBOL(elf_check_arch_64); + void elf_set_personality(const struct elf32_hdr *x) { unsigned int eflags = x->e_flags; -- 1.9.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch 2014-05-03 13:44 ` Liu Hua @ 2014-05-06 12:15 ` Will Deacon -1 siblings, 0 replies; 8+ messages in thread From: Will Deacon @ 2014-05-06 12:15 UTC (permalink / raw) To: linux-arm-kernel On Sat, May 03, 2014 at 02:44:46PM +0100, Liu Hua wrote: > Hi Will or Russell, Hello, > With CONFIG_LPAE=y, memory in 32-bit ARM systems can exceed > 4G. So if we use kdump in such systems. The capture kernel > should parse 64-bit elf header(parse_crash_elf64_headers). > > And this process can not pass because ARM linux only provides > zero vmcore_elf64_check_arch function by commit 4b3bf7aef. > > This patch adds check functions related to elf64 header. [...] > diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c > index d0d1e83..452086a 100644 > --- a/arch/arm/kernel/elf.c > +++ b/arch/arm/kernel/elf.c > @@ -38,6 +38,39 @@ int elf_check_arch(const struct elf32_hdr *x) > } > EXPORT_SYMBOL(elf_check_arch); > > +int elf_check_arch_64(const struct elf64_hdr *x) > +{ > + unsigned int eflags; > + > + /* Make sure it's an ARM executable */ > + if (x->e_machine != EM_ARM) > + return 0; > + > + /* Make sure the entry address is reasonable */ > + if (x->e_entry & 1) { > + if (!(elf_hwcap & HWCAP_THUMB)) > + return 0; > + } else if (x->e_entry & 3) > + return 0; > + > + eflags = x->e_flags; > + if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN) { > + unsigned int flt_fmt; > + > + /* APCS26 is only allowed if the CPU supports it */ > + if ((eflags & EF_ARM_APCS_26) && !(elf_hwcap & HWCAP_26BIT)) > + return 0; > + > + flt_fmt = eflags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT); > + > + /* VFP requires the supporting code */ > + if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) > + return 0; > + } > + return 1; > +} > +EXPORT_SYMBOL(elf_check_arch_64); This function looks identical to elf_check_arch. Why do we need to duplicate that code? You could use some pre-processor magic to make the core part of the functions agnostic to header type. In fact, if elf_check_arch could handle both header types then the generic definition of vmcore_elf64_check_arch in include/linux/crash_dump.h would work out of the box. Will ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch @ 2014-05-06 12:15 ` Will Deacon 0 siblings, 0 replies; 8+ messages in thread From: Will Deacon @ 2014-05-06 12:15 UTC (permalink / raw) To: Liu Hua Cc: linux@arm.linux.org.uk, wangnan0@huawei.com, peifeiyue@huawei.com, Catalin Marinas, mika.westerberg@iki.fi, linux-kernel@vger.kernel.org, alonid@stratoscale.com, linux-arm-kernel@lists.infradead.org On Sat, May 03, 2014 at 02:44:46PM +0100, Liu Hua wrote: > Hi Will or Russell, Hello, > With CONFIG_LPAE=y, memory in 32-bit ARM systems can exceed > 4G. So if we use kdump in such systems. The capture kernel > should parse 64-bit elf header(parse_crash_elf64_headers). > > And this process can not pass because ARM linux only provides > zero vmcore_elf64_check_arch function by commit 4b3bf7aef. > > This patch adds check functions related to elf64 header. [...] > diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c > index d0d1e83..452086a 100644 > --- a/arch/arm/kernel/elf.c > +++ b/arch/arm/kernel/elf.c > @@ -38,6 +38,39 @@ int elf_check_arch(const struct elf32_hdr *x) > } > EXPORT_SYMBOL(elf_check_arch); > > +int elf_check_arch_64(const struct elf64_hdr *x) > +{ > + unsigned int eflags; > + > + /* Make sure it's an ARM executable */ > + if (x->e_machine != EM_ARM) > + return 0; > + > + /* Make sure the entry address is reasonable */ > + if (x->e_entry & 1) { > + if (!(elf_hwcap & HWCAP_THUMB)) > + return 0; > + } else if (x->e_entry & 3) > + return 0; > + > + eflags = x->e_flags; > + if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN) { > + unsigned int flt_fmt; > + > + /* APCS26 is only allowed if the CPU supports it */ > + if ((eflags & EF_ARM_APCS_26) && !(elf_hwcap & HWCAP_26BIT)) > + return 0; > + > + flt_fmt = eflags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT); > + > + /* VFP requires the supporting code */ > + if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) > + return 0; > + } > + return 1; > +} > +EXPORT_SYMBOL(elf_check_arch_64); This function looks identical to elf_check_arch. Why do we need to duplicate that code? You could use some pre-processor magic to make the core part of the functions agnostic to header type. In fact, if elf_check_arch could handle both header types then the generic definition of vmcore_elf64_check_arch in include/linux/crash_dump.h would work out of the box. Will ^ permalink raw reply [flat|nested] 8+ messages in thread
* [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch 2014-05-06 12:15 ` Will Deacon @ 2014-06-09 13:21 ` Liu hua -1 siblings, 0 replies; 8+ messages in thread From: Liu hua @ 2014-06-09 13:21 UTC (permalink / raw) To: linux-arm-kernel ? 2014/5/6 20:15, Will Deacon ??: > On Sat, May 03, 2014 at 02:44:46PM +0100, Liu Hua wrote: >> Hi Will or Russell, > > Hello, > >> With CONFIG_LPAE=y, memory in 32-bit ARM systems can exceed >> 4G. So if we use kdump in such systems. The capture kernel >> should parse 64-bit elf header(parse_crash_elf64_headers). >> >> And this process can not pass because ARM linux only provides >> zero vmcore_elf64_check_arch function by commit 4b3bf7aef. >> >> This patch adds check functions related to elf64 header. > > [...] > >> diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c >> index d0d1e83..452086a 100644 >> --- a/arch/arm/kernel/elf.c >> +++ b/arch/arm/kernel/elf.c >> @@ -38,6 +38,39 @@ int elf_check_arch(const struct elf32_hdr *x) >> } >> EXPORT_SYMBOL(elf_check_arch); >> >> +int elf_check_arch_64(const struct elf64_hdr *x) >> +{ >> + unsigned int eflags; >> + >> + /* Make sure it's an ARM executable */ >> + if (x->e_machine != EM_ARM) >> + return 0; >> + >> + /* Make sure the entry address is reasonable */ >> + if (x->e_entry & 1) { >> + if (!(elf_hwcap & HWCAP_THUMB)) >> + return 0; >> + } else if (x->e_entry & 3) >> + return 0; >> + >> + eflags = x->e_flags; >> + if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN) { >> + unsigned int flt_fmt; >> + >> + /* APCS26 is only allowed if the CPU supports it */ >> + if ((eflags & EF_ARM_APCS_26) && !(elf_hwcap & HWCAP_26BIT)) >> + return 0; >> + >> + flt_fmt = eflags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT); >> + >> + /* VFP requires the supporting code */ >> + if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) >> + return 0; >> + } >> + return 1; >> +} >> +EXPORT_SYMBOL(elf_check_arch_64); > Hi Will, Sorry to reply you so late. These days I am working on kdump feature for LPAE enabled kernel. And now I think this patch is not good. > This function looks identical to elf_check_arch. Why do we need to duplicate > that code? You could use some pre-processor magic to make the core part of > the functions agnostic to header type. At the begging I think I should add elf_check_arch_64 just as elf_check_arch to do complicated check. But for ARM32, elf_check_arch_64 would not be used except for kdump. No programs with elf64 header can be loaded into 32bit ARM kernel. So I think I can just check the "e_machine", just as what other platform does. I think other checks is useless for kdump. > In fact, if elf_check_arch could handle both header types then the generic > definition of vmcore_elf64_check_arch in include/linux/crash_dump.h would > work out of the box. As I mentioned, I afraid this will make the code hard to understand.( Sorry for my former incorrect patch). How about this patch? diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h index f4b46d3..9424542 100644 --- a/arch/arm/include/asm/elf.h +++ b/arch/arm/include/asm/elf.h @@ -97,7 +97,7 @@ struct elf32_hdr; extern int elf_check_arch(const struct elf32_hdr *); #define elf_check_arch elf_check_arch -#define vmcore_elf64_check_arch(x) (0) +#define vmcore_elf64_check_arch(x) ((x)->e_machine == EM_ARM) extern int arm_elf_read_implies_exec(const struct elf32_hdr *, int); #define elf_read_implies_exec(ex,stk) arm_elf_read_implies_exec(&(ex), stk) Thanks, Liu Hua > Will > > . > ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch @ 2014-06-09 13:21 ` Liu hua 0 siblings, 0 replies; 8+ messages in thread From: Liu hua @ 2014-06-09 13:21 UTC (permalink / raw) To: Will Deacon Cc: linux@arm.linux.org.uk, wangnan0@huawei.com, peifeiyue@huawei.com, Catalin Marinas, mika.westerberg@iki.fi, linux-kernel@vger.kernel.org, alonid@stratoscale.com, linux-arm-kernel@lists.infradead.org 于 2014/5/6 20:15, Will Deacon 写道: > On Sat, May 03, 2014 at 02:44:46PM +0100, Liu Hua wrote: >> Hi Will or Russell, > > Hello, > >> With CONFIG_LPAE=y, memory in 32-bit ARM systems can exceed >> 4G. So if we use kdump in such systems. The capture kernel >> should parse 64-bit elf header(parse_crash_elf64_headers). >> >> And this process can not pass because ARM linux only provides >> zero vmcore_elf64_check_arch function by commit 4b3bf7aef. >> >> This patch adds check functions related to elf64 header. > > [...] > >> diff --git a/arch/arm/kernel/elf.c b/arch/arm/kernel/elf.c >> index d0d1e83..452086a 100644 >> --- a/arch/arm/kernel/elf.c >> +++ b/arch/arm/kernel/elf.c >> @@ -38,6 +38,39 @@ int elf_check_arch(const struct elf32_hdr *x) >> } >> EXPORT_SYMBOL(elf_check_arch); >> >> +int elf_check_arch_64(const struct elf64_hdr *x) >> +{ >> + unsigned int eflags; >> + >> + /* Make sure it's an ARM executable */ >> + if (x->e_machine != EM_ARM) >> + return 0; >> + >> + /* Make sure the entry address is reasonable */ >> + if (x->e_entry & 1) { >> + if (!(elf_hwcap & HWCAP_THUMB)) >> + return 0; >> + } else if (x->e_entry & 3) >> + return 0; >> + >> + eflags = x->e_flags; >> + if ((eflags & EF_ARM_EABI_MASK) == EF_ARM_EABI_UNKNOWN) { >> + unsigned int flt_fmt; >> + >> + /* APCS26 is only allowed if the CPU supports it */ >> + if ((eflags & EF_ARM_APCS_26) && !(elf_hwcap & HWCAP_26BIT)) >> + return 0; >> + >> + flt_fmt = eflags & (EF_ARM_VFP_FLOAT | EF_ARM_SOFT_FLOAT); >> + >> + /* VFP requires the supporting code */ >> + if (flt_fmt == EF_ARM_VFP_FLOAT && !(elf_hwcap & HWCAP_VFP)) >> + return 0; >> + } >> + return 1; >> +} >> +EXPORT_SYMBOL(elf_check_arch_64); > Hi Will, Sorry to reply you so late. These days I am working on kdump feature for LPAE enabled kernel. And now I think this patch is not good. > This function looks identical to elf_check_arch. Why do we need to duplicate > that code? You could use some pre-processor magic to make the core part of > the functions agnostic to header type. At the begging I think I should add elf_check_arch_64 just as elf_check_arch to do complicated check. But for ARM32, elf_check_arch_64 would not be used except for kdump. No programs with elf64 header can be loaded into 32bit ARM kernel. So I think I can just check the "e_machine", just as what other platform does. I think other checks is useless for kdump. > In fact, if elf_check_arch could handle both header types then the generic > definition of vmcore_elf64_check_arch in include/linux/crash_dump.h would > work out of the box. As I mentioned, I afraid this will make the code hard to understand.( Sorry for my former incorrect patch). How about this patch? diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h index f4b46d3..9424542 100644 --- a/arch/arm/include/asm/elf.h +++ b/arch/arm/include/asm/elf.h @@ -97,7 +97,7 @@ struct elf32_hdr; extern int elf_check_arch(const struct elf32_hdr *); #define elf_check_arch elf_check_arch -#define vmcore_elf64_check_arch(x) (0) +#define vmcore_elf64_check_arch(x) ((x)->e_machine == EM_ARM) extern int arm_elf_read_implies_exec(const struct elf32_hdr *, int); #define elf_read_implies_exec(ex,stk) arm_elf_read_implies_exec(&(ex), stk) Thanks, Liu Hua > Will > > . > ^ permalink raw reply related [flat|nested] 8+ messages in thread
* [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch 2014-06-09 13:21 ` Liu hua @ 2014-06-16 13:38 ` Will Deacon -1 siblings, 0 replies; 8+ messages in thread From: Will Deacon @ 2014-06-16 13:38 UTC (permalink / raw) To: linux-arm-kernel On Mon, Jun 09, 2014 at 02:21:20PM +0100, Liu hua wrote: > ? 2014/5/6 20:15, Will Deacon ??: > > On Sat, May 03, 2014 at 02:44:46PM +0100, Liu Hua wrote: > Sorry to reply you so late. These days I am working on kdump feature for LPAE enabled > kernel. And now I think this patch is not good. > > > This function looks identical to elf_check_arch. Why do we need to duplicate > > that code? You could use some pre-processor magic to make the core part of > > the functions agnostic to header type. > > At the begging I think I should add elf_check_arch_64 just as elf_check_arch to > do complicated check. > > But for ARM32, elf_check_arch_64 would not be used except for kdump. No programs > with elf64 header can be loaded into 32bit ARM kernel. So I think I can just check > the "e_machine", just as what other platform does. I think other checks is useless > for kdump. > > > In fact, if elf_check_arch could handle both header types then the generic > > definition of vmcore_elf64_check_arch in include/linux/crash_dump.h would > > work out of the box. > > As I mentioned, I afraid this will make the code hard to understand.( Sorry > for my former incorrect patch). > > How about this patch? > > diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h > index f4b46d3..9424542 100644 > --- a/arch/arm/include/asm/elf.h > +++ b/arch/arm/include/asm/elf.h > @@ -97,7 +97,7 @@ struct elf32_hdr; > extern int elf_check_arch(const struct elf32_hdr *); > #define elf_check_arch elf_check_arch > > -#define vmcore_elf64_check_arch(x) (0) > +#define vmcore_elf64_check_arch(x) ((x)->e_machine == EM_ARM) Is there no way we can get away with using the generic version here? What goes wrong if you let vmcore_elf64_check_arch fallback to elf_check_arch? Will ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch @ 2014-06-16 13:38 ` Will Deacon 0 siblings, 0 replies; 8+ messages in thread From: Will Deacon @ 2014-06-16 13:38 UTC (permalink / raw) To: Liu hua Cc: linux@arm.linux.org.uk, wangnan0@huawei.com, peifeiyue@huawei.com, Catalin Marinas, mika.westerberg@iki.fi, linux-kernel@vger.kernel.org, alonid@stratoscale.com, linux-arm-kernel@lists.infradead.org On Mon, Jun 09, 2014 at 02:21:20PM +0100, Liu hua wrote: > 于 2014/5/6 20:15, Will Deacon 写道: > > On Sat, May 03, 2014 at 02:44:46PM +0100, Liu Hua wrote: > Sorry to reply you so late. These days I am working on kdump feature for LPAE enabled > kernel. And now I think this patch is not good. > > > This function looks identical to elf_check_arch. Why do we need to duplicate > > that code? You could use some pre-processor magic to make the core part of > > the functions agnostic to header type. > > At the begging I think I should add elf_check_arch_64 just as elf_check_arch to > do complicated check. > > But for ARM32, elf_check_arch_64 would not be used except for kdump. No programs > with elf64 header can be loaded into 32bit ARM kernel. So I think I can just check > the "e_machine", just as what other platform does. I think other checks is useless > for kdump. > > > In fact, if elf_check_arch could handle both header types then the generic > > definition of vmcore_elf64_check_arch in include/linux/crash_dump.h would > > work out of the box. > > As I mentioned, I afraid this will make the code hard to understand.( Sorry > for my former incorrect patch). > > How about this patch? > > diff --git a/arch/arm/include/asm/elf.h b/arch/arm/include/asm/elf.h > index f4b46d3..9424542 100644 > --- a/arch/arm/include/asm/elf.h > +++ b/arch/arm/include/asm/elf.h > @@ -97,7 +97,7 @@ struct elf32_hdr; > extern int elf_check_arch(const struct elf32_hdr *); > #define elf_check_arch elf_check_arch > > -#define vmcore_elf64_check_arch(x) (0) > +#define vmcore_elf64_check_arch(x) ((x)->e_machine == EM_ARM) Is there no way we can get away with using the generic version here? What goes wrong if you let vmcore_elf64_check_arch fallback to elf_check_arch? Will ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-06-16 13:39 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-05-03 13:44 [RESEND PATCH] ARM: kdump: Add vmcore_elf64_check_arch Liu Hua 2014-05-03 13:44 ` Liu Hua 2014-05-06 12:15 ` Will Deacon 2014-05-06 12:15 ` Will Deacon 2014-06-09 13:21 ` Liu hua 2014-06-09 13:21 ` Liu hua 2014-06-16 13:38 ` Will Deacon 2014-06-16 13:38 ` Will Deacon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.