* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-01 16:08 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-01 16:08 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-kernel, penberg, geert, rppt, Giancarlo Ferrari, akpm,
linux-arm-kernel, giancarlo.ferrari
On Mon, Feb 01, 2021 at 01:57:14PM +0000, Mark Rutland wrote:
> We could simplify this slightly if we moved the kexec_& variables into a
> struct (using asm-offset KEXEC_VAR_* offsets and a KEXEC_VAR_SIZE region
> reserved in the asm), then here we could do something like:
>
> static struct kexec_vars *kexec_buffer_vars(void *buffer)
> {
> unsigned long code = ((unisigned long)relocate_new_kernel) & ~1;
> unsigned long vars - (unsigned long)relocate_vars;
> unsigned long offset = vars - code;
>
> return buffer + offset;
> }
>
> ... and in machine_kexec() do:
>
> struct kexec_vars *kv = kexec_buffer_vars(reboot_code_buffer);
>
> kv->start_address = image->start;
> kv->indirection_page = page_list;
> kv->mach_type = machine-arch_type;
> kv->boot_atags = arch.kernel_r2;
>
> ... if that looks any better to you?
Something like this?
diff --git a/arch/arm/include/asm/kexec-internal.h b/arch/arm/include/asm/kexec-internal.h
new file mode 100644
index 000000000000..ecc2322db7aa
--- /dev/null
+++ b/arch/arm/include/asm/kexec-internal.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ARM_KEXEC_INTERNAL_H
+#define _ARM_KEXEC_INTERNAL_H
+
+struct kexec_relocate_data {
+ unsigned long kexec_start_address;
+ unsigned long kexec_indirection_page;
+ unsigned long kexec_mach_type;
+ unsigned long kexec_r2;
+};
+
+#endif
diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
index a1570c8bab25..be8050b0c3df 100644
--- a/arch/arm/kernel/asm-offsets.c
+++ b/arch/arm/kernel/asm-offsets.c
@@ -12,6 +12,7 @@
#include <linux/mm.h>
#include <linux/dma-mapping.h>
#include <asm/cacheflush.h>
+#include <asm/kexec-internal.h>
#include <asm/glue-df.h>
#include <asm/glue-pf.h>
#include <asm/mach/arch.h>
@@ -170,5 +171,9 @@ int main(void)
DEFINE(MPU_RGN_PRBAR, offsetof(struct mpu_rgn, prbar));
DEFINE(MPU_RGN_PRLAR, offsetof(struct mpu_rgn, prlar));
#endif
+ DEFINE(KEXEC_START_ADDR, offsetof(struct kexec_relocate_data, kexec_start_address));
+ DEFINE(KEXEC_INDIR_PAGE, offsetof(struct kexec_relocate_data, kexec_indirection_page));
+ DEFINE(KEXEC_MACH_TYPE, offsetof(struct kexec_relocate_data, kexec_mach_type));
+ DEFINE(KEXEC_R2, offsetof(struct kexec_relocate_data, kexec_r2));
return 0;
}
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 5d84ad333f05..2b09dad7935e 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -13,6 +13,7 @@
#include <linux/of_fdt.h>
#include <asm/mmu_context.h>
#include <asm/cacheflush.h>
+#include <asm/kexec-internal.h>
#include <asm/fncpy.h>
#include <asm/mach-types.h>
#include <asm/smp_plat.h>
@@ -22,11 +23,6 @@
extern void relocate_new_kernel(void);
extern const unsigned int relocate_new_kernel_size;
-extern unsigned long kexec_start_address;
-extern unsigned long kexec_indirection_page;
-extern unsigned long kexec_mach_type;
-extern unsigned long kexec_boot_atags;
-
static atomic_t waiting_for_crash_ipi;
/*
@@ -159,6 +155,7 @@ void (*kexec_reinit)(void);
void machine_kexec(struct kimage *image)
{
unsigned long page_list, reboot_entry_phys;
+ struct kexec_relocate_data *data;
void (*reboot_entry)(void);
void *reboot_code_buffer;
@@ -174,18 +171,17 @@ void machine_kexec(struct kimage *image)
reboot_code_buffer = page_address(image->control_code_page);
- /* Prepare parameters for reboot_code_buffer*/
- set_kernel_text_rw();
- kexec_start_address = image->start;
- kexec_indirection_page = page_list;
- kexec_mach_type = machine_arch_type;
- kexec_boot_atags = image->arch.kernel_r2;
-
/* copy our kernel relocation code to the control code page */
reboot_entry = fncpy(reboot_code_buffer,
&relocate_new_kernel,
relocate_new_kernel_size);
+ data = reboot_code_buffer + relocate_new_kernel_size;
+ data->kexec_start_address = image->start;
+ data->kexec_indirection_page = page_list;
+ data->kexec_mach_type = machine_arch_type;
+ data->kexec_r2 = image->arch.kernel_r2;
+
/* get the identity mapping physical address for the reboot code */
reboot_entry_phys = virt_to_idmap(reboot_entry);
diff --git a/arch/arm/kernel/relocate_kernel.S b/arch/arm/kernel/relocate_kernel.S
index 72a08786e16e..218d524360fc 100644
--- a/arch/arm/kernel/relocate_kernel.S
+++ b/arch/arm/kernel/relocate_kernel.S
@@ -5,14 +5,16 @@
#include <linux/linkage.h>
#include <asm/assembler.h>
+#include <asm/asm-offsets.h>
#include <asm/kexec.h>
.align 3 /* not needed for this code, but keeps fncpy() happy */
ENTRY(relocate_new_kernel)
- ldr r0,kexec_indirection_page
- ldr r1,kexec_start_address
+ adr r7, relocate_new_kernel_end
+ ldr r0, [r7, #KEXEC_INDIR_PAGE]
+ ldr r1, [r7, #KEXEC_START_ADDR]
/*
* If there is no indirection page (we are doing crashdumps)
@@ -57,34 +59,16 @@ ENTRY(relocate_new_kernel)
2:
/* Jump to relocated kernel */
- mov lr,r1
- mov r0,#0
- ldr r1,kexec_mach_type
- ldr r2,kexec_boot_atags
- ARM( ret lr )
- THUMB( bx lr )
-
- .align
-
- .globl kexec_start_address
-kexec_start_address:
- .long 0x0
-
- .globl kexec_indirection_page
-kexec_indirection_page:
- .long 0x0
-
- .globl kexec_mach_type
-kexec_mach_type:
- .long 0x0
-
- /* phy addr of the atags for the new kernel */
- .globl kexec_boot_atags
-kexec_boot_atags:
- .long 0x0
+ mov lr, r1
+ mov r0, #0
+ ldr r1, [r7, #KEXEC_MACH_TYPE]
+ ldr r2, [r7, #KEXEC_R2]
+ ARM( ret lr )
+ THUMB( bx lr )
ENDPROC(relocate_new_kernel)
+ .align 3
relocate_new_kernel_end:
.globl relocate_new_kernel_size
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-01 16:08 ` Russell King - ARM Linux admin
@ 2021-02-01 16:32 ` Mark Rutland
-1 siblings, 0 replies; 44+ messages in thread
From: Mark Rutland @ 2021-02-01 16:32 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Giancarlo Ferrari, linux-kernel, penberg, geert,
linux-arm-kernel, akpm, rppt, giancarlo.ferrari
On Mon, Feb 01, 2021 at 04:08:38PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 01:57:14PM +0000, Mark Rutland wrote:
> > We could simplify this slightly if we moved the kexec_& variables into a
> > struct (using asm-offset KEXEC_VAR_* offsets and a KEXEC_VAR_SIZE region
> > reserved in the asm), then here we could do something like:
> >
> > static struct kexec_vars *kexec_buffer_vars(void *buffer)
> > {
> > unsigned long code = ((unisigned long)relocate_new_kernel) & ~1;
> > unsigned long vars - (unsigned long)relocate_vars;
> > unsigned long offset = vars - code;
> >
> > return buffer + offset;
> > }
> >
> > ... and in machine_kexec() do:
> >
> > struct kexec_vars *kv = kexec_buffer_vars(reboot_code_buffer);
> >
> > kv->start_address = image->start;
> > kv->indirection_page = page_list;
> > kv->mach_type = machine-arch_type;
> > kv->boot_atags = arch.kernel_r2;
> >
> > ... if that looks any better to you?
>
> Something like this?
Nice!
That looks about right to me, modulo a bit of cache maintenance noted
below.
> diff --git a/arch/arm/include/asm/kexec-internal.h b/arch/arm/include/asm/kexec-internal.h
> new file mode 100644
> index 000000000000..ecc2322db7aa
> --- /dev/null
> +++ b/arch/arm/include/asm/kexec-internal.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ARM_KEXEC_INTERNAL_H
> +#define _ARM_KEXEC_INTERNAL_H
> +
> +struct kexec_relocate_data {
> + unsigned long kexec_start_address;
> + unsigned long kexec_indirection_page;
> + unsigned long kexec_mach_type;
> + unsigned long kexec_r2;
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index a1570c8bab25..be8050b0c3df 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -12,6 +12,7 @@
> #include <linux/mm.h>
> #include <linux/dma-mapping.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/glue-df.h>
> #include <asm/glue-pf.h>
> #include <asm/mach/arch.h>
> @@ -170,5 +171,9 @@ int main(void)
> DEFINE(MPU_RGN_PRBAR, offsetof(struct mpu_rgn, prbar));
> DEFINE(MPU_RGN_PRLAR, offsetof(struct mpu_rgn, prlar));
> #endif
> + DEFINE(KEXEC_START_ADDR, offsetof(struct kexec_relocate_data, kexec_start_address));
> + DEFINE(KEXEC_INDIR_PAGE, offsetof(struct kexec_relocate_data, kexec_indirection_page));
> + DEFINE(KEXEC_MACH_TYPE, offsetof(struct kexec_relocate_data, kexec_mach_type));
> + DEFINE(KEXEC_R2, offsetof(struct kexec_relocate_data, kexec_r2));
> return 0;
> }
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 5d84ad333f05..2b09dad7935e 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -13,6 +13,7 @@
> #include <linux/of_fdt.h>
> #include <asm/mmu_context.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/fncpy.h>
> #include <asm/mach-types.h>
> #include <asm/smp_plat.h>
> @@ -22,11 +23,6 @@
> extern void relocate_new_kernel(void);
> extern const unsigned int relocate_new_kernel_size;
>
> -extern unsigned long kexec_start_address;
> -extern unsigned long kexec_indirection_page;
> -extern unsigned long kexec_mach_type;
> -extern unsigned long kexec_boot_atags;
> -
> static atomic_t waiting_for_crash_ipi;
>
> /*
> @@ -159,6 +155,7 @@ void (*kexec_reinit)(void);
> void machine_kexec(struct kimage *image)
> {
> unsigned long page_list, reboot_entry_phys;
> + struct kexec_relocate_data *data;
> void (*reboot_entry)(void);
> void *reboot_code_buffer;
>
> @@ -174,18 +171,17 @@ void machine_kexec(struct kimage *image)
>
> reboot_code_buffer = page_address(image->control_code_page);
>
> - /* Prepare parameters for reboot_code_buffer*/
> - set_kernel_text_rw();
> - kexec_start_address = image->start;
> - kexec_indirection_page = page_list;
> - kexec_mach_type = machine_arch_type;
> - kexec_boot_atags = image->arch.kernel_r2;
> -
> /* copy our kernel relocation code to the control code page */
> reboot_entry = fncpy(reboot_code_buffer,
> &relocate_new_kernel,
> relocate_new_kernel_size);
>
> + data = reboot_code_buffer + relocate_new_kernel_size;
> + data->kexec_start_address = image->start;
> + data->kexec_indirection_page = page_list;
> + data->kexec_mach_type = machine_arch_type;
> + data->kexec_r2 = image->arch.kernel_r2;
I reckon here we need:
__cpuc_flush_dcache_area(reboot_code_buffer,
relocate_new_kernel_size + sizeof(*data));
... to make sure both the instructions and data are visible with the MMU
off (since fncpy() only cleans to the PoU, not the PoC).
Otherwise this all looks good to me.
Mark.
> +
> /* get the identity mapping physical address for the reboot code */
> reboot_entry_phys = virt_to_idmap(reboot_entry);
>
> diff --git a/arch/arm/kernel/relocate_kernel.S b/arch/arm/kernel/relocate_kernel.S
> index 72a08786e16e..218d524360fc 100644
> --- a/arch/arm/kernel/relocate_kernel.S
> +++ b/arch/arm/kernel/relocate_kernel.S
> @@ -5,14 +5,16 @@
>
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/asm-offsets.h>
> #include <asm/kexec.h>
>
> .align 3 /* not needed for this code, but keeps fncpy() happy */
>
> ENTRY(relocate_new_kernel)
>
> - ldr r0,kexec_indirection_page
> - ldr r1,kexec_start_address
> + adr r7, relocate_new_kernel_end
> + ldr r0, [r7, #KEXEC_INDIR_PAGE]
> + ldr r1, [r7, #KEXEC_START_ADDR]
>
> /*
> * If there is no indirection page (we are doing crashdumps)
> @@ -57,34 +59,16 @@ ENTRY(relocate_new_kernel)
>
> 2:
> /* Jump to relocated kernel */
> - mov lr,r1
> - mov r0,#0
> - ldr r1,kexec_mach_type
> - ldr r2,kexec_boot_atags
> - ARM( ret lr )
> - THUMB( bx lr )
> -
> - .align
> -
> - .globl kexec_start_address
> -kexec_start_address:
> - .long 0x0
> -
> - .globl kexec_indirection_page
> -kexec_indirection_page:
> - .long 0x0
> -
> - .globl kexec_mach_type
> -kexec_mach_type:
> - .long 0x0
> -
> - /* phy addr of the atags for the new kernel */
> - .globl kexec_boot_atags
> -kexec_boot_atags:
> - .long 0x0
> + mov lr, r1
> + mov r0, #0
> + ldr r1, [r7, #KEXEC_MACH_TYPE]
> + ldr r2, [r7, #KEXEC_R2]
> + ARM( ret lr )
> + THUMB( bx lr )
>
> ENDPROC(relocate_new_kernel)
>
> + .align 3
> relocate_new_kernel_end:
>
> .globl relocate_new_kernel_size
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-01 16:32 ` Mark Rutland
0 siblings, 0 replies; 44+ messages in thread
From: Mark Rutland @ 2021-02-01 16:32 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-kernel, penberg, geert, rppt, Giancarlo Ferrari, akpm,
linux-arm-kernel, giancarlo.ferrari
On Mon, Feb 01, 2021 at 04:08:38PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 01:57:14PM +0000, Mark Rutland wrote:
> > We could simplify this slightly if we moved the kexec_& variables into a
> > struct (using asm-offset KEXEC_VAR_* offsets and a KEXEC_VAR_SIZE region
> > reserved in the asm), then here we could do something like:
> >
> > static struct kexec_vars *kexec_buffer_vars(void *buffer)
> > {
> > unsigned long code = ((unisigned long)relocate_new_kernel) & ~1;
> > unsigned long vars - (unsigned long)relocate_vars;
> > unsigned long offset = vars - code;
> >
> > return buffer + offset;
> > }
> >
> > ... and in machine_kexec() do:
> >
> > struct kexec_vars *kv = kexec_buffer_vars(reboot_code_buffer);
> >
> > kv->start_address = image->start;
> > kv->indirection_page = page_list;
> > kv->mach_type = machine-arch_type;
> > kv->boot_atags = arch.kernel_r2;
> >
> > ... if that looks any better to you?
>
> Something like this?
Nice!
That looks about right to me, modulo a bit of cache maintenance noted
below.
> diff --git a/arch/arm/include/asm/kexec-internal.h b/arch/arm/include/asm/kexec-internal.h
> new file mode 100644
> index 000000000000..ecc2322db7aa
> --- /dev/null
> +++ b/arch/arm/include/asm/kexec-internal.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ARM_KEXEC_INTERNAL_H
> +#define _ARM_KEXEC_INTERNAL_H
> +
> +struct kexec_relocate_data {
> + unsigned long kexec_start_address;
> + unsigned long kexec_indirection_page;
> + unsigned long kexec_mach_type;
> + unsigned long kexec_r2;
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index a1570c8bab25..be8050b0c3df 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -12,6 +12,7 @@
> #include <linux/mm.h>
> #include <linux/dma-mapping.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/glue-df.h>
> #include <asm/glue-pf.h>
> #include <asm/mach/arch.h>
> @@ -170,5 +171,9 @@ int main(void)
> DEFINE(MPU_RGN_PRBAR, offsetof(struct mpu_rgn, prbar));
> DEFINE(MPU_RGN_PRLAR, offsetof(struct mpu_rgn, prlar));
> #endif
> + DEFINE(KEXEC_START_ADDR, offsetof(struct kexec_relocate_data, kexec_start_address));
> + DEFINE(KEXEC_INDIR_PAGE, offsetof(struct kexec_relocate_data, kexec_indirection_page));
> + DEFINE(KEXEC_MACH_TYPE, offsetof(struct kexec_relocate_data, kexec_mach_type));
> + DEFINE(KEXEC_R2, offsetof(struct kexec_relocate_data, kexec_r2));
> return 0;
> }
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 5d84ad333f05..2b09dad7935e 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -13,6 +13,7 @@
> #include <linux/of_fdt.h>
> #include <asm/mmu_context.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/fncpy.h>
> #include <asm/mach-types.h>
> #include <asm/smp_plat.h>
> @@ -22,11 +23,6 @@
> extern void relocate_new_kernel(void);
> extern const unsigned int relocate_new_kernel_size;
>
> -extern unsigned long kexec_start_address;
> -extern unsigned long kexec_indirection_page;
> -extern unsigned long kexec_mach_type;
> -extern unsigned long kexec_boot_atags;
> -
> static atomic_t waiting_for_crash_ipi;
>
> /*
> @@ -159,6 +155,7 @@ void (*kexec_reinit)(void);
> void machine_kexec(struct kimage *image)
> {
> unsigned long page_list, reboot_entry_phys;
> + struct kexec_relocate_data *data;
> void (*reboot_entry)(void);
> void *reboot_code_buffer;
>
> @@ -174,18 +171,17 @@ void machine_kexec(struct kimage *image)
>
> reboot_code_buffer = page_address(image->control_code_page);
>
> - /* Prepare parameters for reboot_code_buffer*/
> - set_kernel_text_rw();
> - kexec_start_address = image->start;
> - kexec_indirection_page = page_list;
> - kexec_mach_type = machine_arch_type;
> - kexec_boot_atags = image->arch.kernel_r2;
> -
> /* copy our kernel relocation code to the control code page */
> reboot_entry = fncpy(reboot_code_buffer,
> &relocate_new_kernel,
> relocate_new_kernel_size);
>
> + data = reboot_code_buffer + relocate_new_kernel_size;
> + data->kexec_start_address = image->start;
> + data->kexec_indirection_page = page_list;
> + data->kexec_mach_type = machine_arch_type;
> + data->kexec_r2 = image->arch.kernel_r2;
I reckon here we need:
__cpuc_flush_dcache_area(reboot_code_buffer,
relocate_new_kernel_size + sizeof(*data));
... to make sure both the instructions and data are visible with the MMU
off (since fncpy() only cleans to the PoU, not the PoC).
Otherwise this all looks good to me.
Mark.
> +
> /* get the identity mapping physical address for the reboot code */
> reboot_entry_phys = virt_to_idmap(reboot_entry);
>
> diff --git a/arch/arm/kernel/relocate_kernel.S b/arch/arm/kernel/relocate_kernel.S
> index 72a08786e16e..218d524360fc 100644
> --- a/arch/arm/kernel/relocate_kernel.S
> +++ b/arch/arm/kernel/relocate_kernel.S
> @@ -5,14 +5,16 @@
>
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/asm-offsets.h>
> #include <asm/kexec.h>
>
> .align 3 /* not needed for this code, but keeps fncpy() happy */
>
> ENTRY(relocate_new_kernel)
>
> - ldr r0,kexec_indirection_page
> - ldr r1,kexec_start_address
> + adr r7, relocate_new_kernel_end
> + ldr r0, [r7, #KEXEC_INDIR_PAGE]
> + ldr r1, [r7, #KEXEC_START_ADDR]
>
> /*
> * If there is no indirection page (we are doing crashdumps)
> @@ -57,34 +59,16 @@ ENTRY(relocate_new_kernel)
>
> 2:
> /* Jump to relocated kernel */
> - mov lr,r1
> - mov r0,#0
> - ldr r1,kexec_mach_type
> - ldr r2,kexec_boot_atags
> - ARM( ret lr )
> - THUMB( bx lr )
> -
> - .align
> -
> - .globl kexec_start_address
> -kexec_start_address:
> - .long 0x0
> -
> - .globl kexec_indirection_page
> -kexec_indirection_page:
> - .long 0x0
> -
> - .globl kexec_mach_type
> -kexec_mach_type:
> - .long 0x0
> -
> - /* phy addr of the atags for the new kernel */
> - .globl kexec_boot_atags
> -kexec_boot_atags:
> - .long 0x0
> + mov lr, r1
> + mov r0, #0
> + ldr r1, [r7, #KEXEC_MACH_TYPE]
> + ldr r2, [r7, #KEXEC_R2]
> + ARM( ret lr )
> + THUMB( bx lr )
>
> ENDPROC(relocate_new_kernel)
>
> + .align 3
> relocate_new_kernel_end:
>
> .globl relocate_new_kernel_size
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-01 16:32 ` Mark Rutland
@ 2021-02-01 16:37 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-01 16:37 UTC (permalink / raw)
To: Mark Rutland
Cc: Giancarlo Ferrari, linux-kernel, penberg, geert,
linux-arm-kernel, akpm, rppt, giancarlo.ferrari
On Mon, Feb 01, 2021 at 04:32:40PM +0000, Mark Rutland wrote:
> I reckon here we need:
>
> __cpuc_flush_dcache_area(reboot_code_buffer,
> relocate_new_kernel_size + sizeof(*data));
>
> ... to make sure both the instructions and data are visible with the MMU
> off (since fncpy() only cleans to the PoU, not the PoC).
We don't. When soft_restart() turns the MMU off, and it calls
flush_cache_all() before and afterwards to ensure that all dirty lines
are pushed out.
The flushing to PoU in fncpy() is to cover other cases.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-01 16:37 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-01 16:37 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-kernel, penberg, geert, rppt, Giancarlo Ferrari, akpm,
linux-arm-kernel, giancarlo.ferrari
On Mon, Feb 01, 2021 at 04:32:40PM +0000, Mark Rutland wrote:
> I reckon here we need:
>
> __cpuc_flush_dcache_area(reboot_code_buffer,
> relocate_new_kernel_size + sizeof(*data));
>
> ... to make sure both the instructions and data are visible with the MMU
> off (since fncpy() only cleans to the PoU, not the PoC).
We don't. When soft_restart() turns the MMU off, and it calls
flush_cache_all() before and afterwards to ensure that all dirty lines
are pushed out.
The flushing to PoU in fncpy() is to cover other cases.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-01 16:08 ` Russell King - ARM Linux admin
@ 2021-02-01 20:07 ` Giancarlo Ferrari
-1 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-01 20:07 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
Hi,
On Mon, Feb 01, 2021 at 04:08:38PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 01:57:14PM +0000, Mark Rutland wrote:
> > We could simplify this slightly if we moved the kexec_& variables into a
> > struct (using asm-offset KEXEC_VAR_* offsets and a KEXEC_VAR_SIZE region
> > reserved in the asm), then here we could do something like:
> >
> > static struct kexec_vars *kexec_buffer_vars(void *buffer)
> > {
> > unsigned long code = ((unisigned long)relocate_new_kernel) & ~1;
> > unsigned long vars - (unsigned long)relocate_vars;
> > unsigned long offset = vars - code;
> >
> > return buffer + offset;
> > }
> >
> > ... and in machine_kexec() do:
> >
> > struct kexec_vars *kv = kexec_buffer_vars(reboot_code_buffer);
> >
> > kv->start_address = image->start;
> > kv->indirection_page = page_list;
> > kv->mach_type = machine-arch_type;
> > kv->boot_atags = arch.kernel_r2;
> >
> > ... if that looks any better to you?
>
> Something like this?
>
> diff --git a/arch/arm/include/asm/kexec-internal.h b/arch/arm/include/asm/kexec-internal.h
> new file mode 100644
> index 000000000000..ecc2322db7aa
> --- /dev/null
> +++ b/arch/arm/include/asm/kexec-internal.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ARM_KEXEC_INTERNAL_H
> +#define _ARM_KEXEC_INTERNAL_H
> +
> +struct kexec_relocate_data {
> + unsigned long kexec_start_address;
> + unsigned long kexec_indirection_page;
> + unsigned long kexec_mach_type;
> + unsigned long kexec_r2;
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index a1570c8bab25..be8050b0c3df 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -12,6 +12,7 @@
> #include <linux/mm.h>
> #include <linux/dma-mapping.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/glue-df.h>
> #include <asm/glue-pf.h>
> #include <asm/mach/arch.h>
> @@ -170,5 +171,9 @@ int main(void)
> DEFINE(MPU_RGN_PRBAR, offsetof(struct mpu_rgn, prbar));
> DEFINE(MPU_RGN_PRLAR, offsetof(struct mpu_rgn, prlar));
> #endif
> + DEFINE(KEXEC_START_ADDR, offsetof(struct kexec_relocate_data, kexec_start_address));
> + DEFINE(KEXEC_INDIR_PAGE, offsetof(struct kexec_relocate_data, kexec_indirection_page));
> + DEFINE(KEXEC_MACH_TYPE, offsetof(struct kexec_relocate_data, kexec_mach_type));
> + DEFINE(KEXEC_R2, offsetof(struct kexec_relocate_data, kexec_r2));
> return 0;
> }
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 5d84ad333f05..2b09dad7935e 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -13,6 +13,7 @@
> #include <linux/of_fdt.h>
> #include <asm/mmu_context.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/fncpy.h>
> #include <asm/mach-types.h>
> #include <asm/smp_plat.h>
> @@ -22,11 +23,6 @@
> extern void relocate_new_kernel(void);
> extern const unsigned int relocate_new_kernel_size;
>
> -extern unsigned long kexec_start_address;
> -extern unsigned long kexec_indirection_page;
> -extern unsigned long kexec_mach_type;
> -extern unsigned long kexec_boot_atags;
> -
> static atomic_t waiting_for_crash_ipi;
>
> /*
> @@ -159,6 +155,7 @@ void (*kexec_reinit)(void);
> void machine_kexec(struct kimage *image)
> {
> unsigned long page_list, reboot_entry_phys;
> + struct kexec_relocate_data *data;
> void (*reboot_entry)(void);
> void *reboot_code_buffer;
>
> @@ -174,18 +171,17 @@ void machine_kexec(struct kimage *image)
>
> reboot_code_buffer = page_address(image->control_code_page);
>
> - /* Prepare parameters for reboot_code_buffer*/
> - set_kernel_text_rw();
> - kexec_start_address = image->start;
> - kexec_indirection_page = page_list;
> - kexec_mach_type = machine_arch_type;
> - kexec_boot_atags = image->arch.kernel_r2;
> -
> /* copy our kernel relocation code to the control code page */
> reboot_entry = fncpy(reboot_code_buffer,
> &relocate_new_kernel,
> relocate_new_kernel_size);
>
> + data = reboot_code_buffer + relocate_new_kernel_size;
> + data->kexec_start_address = image->start;
> + data->kexec_indirection_page = page_list;
> + data->kexec_mach_type = machine_arch_type;
> + data->kexec_r2 = image->arch.kernel_r2;
> +
> /* get the identity mapping physical address for the reboot code */
> reboot_entry_phys = virt_to_idmap(reboot_entry);
>
> diff --git a/arch/arm/kernel/relocate_kernel.S b/arch/arm/kernel/relocate_kernel.S
> index 72a08786e16e..218d524360fc 100644
> --- a/arch/arm/kernel/relocate_kernel.S
> +++ b/arch/arm/kernel/relocate_kernel.S
> @@ -5,14 +5,16 @@
>
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/asm-offsets.h>
> #include <asm/kexec.h>
>
> .align 3 /* not needed for this code, but keeps fncpy() happy */
>
> ENTRY(relocate_new_kernel)
>
> - ldr r0,kexec_indirection_page
> - ldr r1,kexec_start_address
> + adr r7, relocate_new_kernel_end
> + ldr r0, [r7, #KEXEC_INDIR_PAGE]
> + ldr r1, [r7, #KEXEC_START_ADDR]
>
> /*
> * If there is no indirection page (we are doing crashdumps)
> @@ -57,34 +59,16 @@ ENTRY(relocate_new_kernel)
>
> 2:
> /* Jump to relocated kernel */
> - mov lr,r1
> - mov r0,#0
> - ldr r1,kexec_mach_type
> - ldr r2,kexec_boot_atags
> - ARM( ret lr )
> - THUMB( bx lr )
> -
> - .align
> -
> - .globl kexec_start_address
> -kexec_start_address:
> - .long 0x0
> -
> - .globl kexec_indirection_page
> -kexec_indirection_page:
> - .long 0x0
> -
> - .globl kexec_mach_type
> -kexec_mach_type:
> - .long 0x0
> -
> - /* phy addr of the atags for the new kernel */
> - .globl kexec_boot_atags
> -kexec_boot_atags:
> - .long 0x0
> + mov lr, r1
> + mov r0, #0
> + ldr r1, [r7, #KEXEC_MACH_TYPE]
> + ldr r2, [r7, #KEXEC_R2]
> + ARM( ret lr )
> + THUMB( bx lr )
>
> ENDPROC(relocate_new_kernel)
>
> + .align 3
Nice.
Why we should align 3 ? For the fncpy I suppose.
> relocate_new_kernel_end:
>
> .globl relocate_new_kernel_size
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
I don't know now how to proceed now, as you (Mark and you) do completely
the patch.
You see is my first kernel patch submission :) .
Thanks,
GF
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-01 20:07 ` Giancarlo Ferrari
0 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-01 20:07 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
Hi,
On Mon, Feb 01, 2021 at 04:08:38PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 01:57:14PM +0000, Mark Rutland wrote:
> > We could simplify this slightly if we moved the kexec_& variables into a
> > struct (using asm-offset KEXEC_VAR_* offsets and a KEXEC_VAR_SIZE region
> > reserved in the asm), then here we could do something like:
> >
> > static struct kexec_vars *kexec_buffer_vars(void *buffer)
> > {
> > unsigned long code = ((unisigned long)relocate_new_kernel) & ~1;
> > unsigned long vars - (unsigned long)relocate_vars;
> > unsigned long offset = vars - code;
> >
> > return buffer + offset;
> > }
> >
> > ... and in machine_kexec() do:
> >
> > struct kexec_vars *kv = kexec_buffer_vars(reboot_code_buffer);
> >
> > kv->start_address = image->start;
> > kv->indirection_page = page_list;
> > kv->mach_type = machine-arch_type;
> > kv->boot_atags = arch.kernel_r2;
> >
> > ... if that looks any better to you?
>
> Something like this?
>
> diff --git a/arch/arm/include/asm/kexec-internal.h b/arch/arm/include/asm/kexec-internal.h
> new file mode 100644
> index 000000000000..ecc2322db7aa
> --- /dev/null
> +++ b/arch/arm/include/asm/kexec-internal.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ARM_KEXEC_INTERNAL_H
> +#define _ARM_KEXEC_INTERNAL_H
> +
> +struct kexec_relocate_data {
> + unsigned long kexec_start_address;
> + unsigned long kexec_indirection_page;
> + unsigned long kexec_mach_type;
> + unsigned long kexec_r2;
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index a1570c8bab25..be8050b0c3df 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -12,6 +12,7 @@
> #include <linux/mm.h>
> #include <linux/dma-mapping.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/glue-df.h>
> #include <asm/glue-pf.h>
> #include <asm/mach/arch.h>
> @@ -170,5 +171,9 @@ int main(void)
> DEFINE(MPU_RGN_PRBAR, offsetof(struct mpu_rgn, prbar));
> DEFINE(MPU_RGN_PRLAR, offsetof(struct mpu_rgn, prlar));
> #endif
> + DEFINE(KEXEC_START_ADDR, offsetof(struct kexec_relocate_data, kexec_start_address));
> + DEFINE(KEXEC_INDIR_PAGE, offsetof(struct kexec_relocate_data, kexec_indirection_page));
> + DEFINE(KEXEC_MACH_TYPE, offsetof(struct kexec_relocate_data, kexec_mach_type));
> + DEFINE(KEXEC_R2, offsetof(struct kexec_relocate_data, kexec_r2));
> return 0;
> }
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index 5d84ad333f05..2b09dad7935e 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -13,6 +13,7 @@
> #include <linux/of_fdt.h>
> #include <asm/mmu_context.h>
> #include <asm/cacheflush.h>
> +#include <asm/kexec-internal.h>
> #include <asm/fncpy.h>
> #include <asm/mach-types.h>
> #include <asm/smp_plat.h>
> @@ -22,11 +23,6 @@
> extern void relocate_new_kernel(void);
> extern const unsigned int relocate_new_kernel_size;
>
> -extern unsigned long kexec_start_address;
> -extern unsigned long kexec_indirection_page;
> -extern unsigned long kexec_mach_type;
> -extern unsigned long kexec_boot_atags;
> -
> static atomic_t waiting_for_crash_ipi;
>
> /*
> @@ -159,6 +155,7 @@ void (*kexec_reinit)(void);
> void machine_kexec(struct kimage *image)
> {
> unsigned long page_list, reboot_entry_phys;
> + struct kexec_relocate_data *data;
> void (*reboot_entry)(void);
> void *reboot_code_buffer;
>
> @@ -174,18 +171,17 @@ void machine_kexec(struct kimage *image)
>
> reboot_code_buffer = page_address(image->control_code_page);
>
> - /* Prepare parameters for reboot_code_buffer*/
> - set_kernel_text_rw();
> - kexec_start_address = image->start;
> - kexec_indirection_page = page_list;
> - kexec_mach_type = machine_arch_type;
> - kexec_boot_atags = image->arch.kernel_r2;
> -
> /* copy our kernel relocation code to the control code page */
> reboot_entry = fncpy(reboot_code_buffer,
> &relocate_new_kernel,
> relocate_new_kernel_size);
>
> + data = reboot_code_buffer + relocate_new_kernel_size;
> + data->kexec_start_address = image->start;
> + data->kexec_indirection_page = page_list;
> + data->kexec_mach_type = machine_arch_type;
> + data->kexec_r2 = image->arch.kernel_r2;
> +
> /* get the identity mapping physical address for the reboot code */
> reboot_entry_phys = virt_to_idmap(reboot_entry);
>
> diff --git a/arch/arm/kernel/relocate_kernel.S b/arch/arm/kernel/relocate_kernel.S
> index 72a08786e16e..218d524360fc 100644
> --- a/arch/arm/kernel/relocate_kernel.S
> +++ b/arch/arm/kernel/relocate_kernel.S
> @@ -5,14 +5,16 @@
>
> #include <linux/linkage.h>
> #include <asm/assembler.h>
> +#include <asm/asm-offsets.h>
> #include <asm/kexec.h>
>
> .align 3 /* not needed for this code, but keeps fncpy() happy */
>
> ENTRY(relocate_new_kernel)
>
> - ldr r0,kexec_indirection_page
> - ldr r1,kexec_start_address
> + adr r7, relocate_new_kernel_end
> + ldr r0, [r7, #KEXEC_INDIR_PAGE]
> + ldr r1, [r7, #KEXEC_START_ADDR]
>
> /*
> * If there is no indirection page (we are doing crashdumps)
> @@ -57,34 +59,16 @@ ENTRY(relocate_new_kernel)
>
> 2:
> /* Jump to relocated kernel */
> - mov lr,r1
> - mov r0,#0
> - ldr r1,kexec_mach_type
> - ldr r2,kexec_boot_atags
> - ARM( ret lr )
> - THUMB( bx lr )
> -
> - .align
> -
> - .globl kexec_start_address
> -kexec_start_address:
> - .long 0x0
> -
> - .globl kexec_indirection_page
> -kexec_indirection_page:
> - .long 0x0
> -
> - .globl kexec_mach_type
> -kexec_mach_type:
> - .long 0x0
> -
> - /* phy addr of the atags for the new kernel */
> - .globl kexec_boot_atags
> -kexec_boot_atags:
> - .long 0x0
> + mov lr, r1
> + mov r0, #0
> + ldr r1, [r7, #KEXEC_MACH_TYPE]
> + ldr r2, [r7, #KEXEC_R2]
> + ARM( ret lr )
> + THUMB( bx lr )
>
> ENDPROC(relocate_new_kernel)
>
> + .align 3
Nice.
Why we should align 3 ? For the fncpy I suppose.
> relocate_new_kernel_end:
>
> .globl relocate_new_kernel_size
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
I don't know now how to proceed now, as you (Mark and you) do completely
the patch.
You see is my first kernel patch submission :) .
Thanks,
GF
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-01 20:07 ` Giancarlo Ferrari
@ 2021-02-01 20:16 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-01 20:16 UTC (permalink / raw)
To: Giancarlo Ferrari
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
On Mon, Feb 01, 2021 at 08:07:37PM +0000, Giancarlo Ferrari wrote:
> Hi,
Hi,
> Why we should align 3 ? For the fncpy I suppose.
Slightly arbitary really - it gives a nice 8-byte alignment to the data.
.align 2 would also be sufficient.
> I don't know now how to proceed now, as you (Mark and you) do completely
> the patch.
Please can you test my patch and let us know if it solves your problem
(or even if it works! I haven't tested it beyond build-testing.)
> You see is my first kernel patch submission :) .
Yay. Sorry for giving you a different patch - Mark is quite right that
there's a better solution to this problem, which is eliminating the
set_kernel_text_rw() call. The only reason I cooked up the patch was
doing that would be more in-depth (as you can see from the increased
size of the patch.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-01 20:16 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-01 20:16 UTC (permalink / raw)
To: Giancarlo Ferrari
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
On Mon, Feb 01, 2021 at 08:07:37PM +0000, Giancarlo Ferrari wrote:
> Hi,
Hi,
> Why we should align 3 ? For the fncpy I suppose.
Slightly arbitary really - it gives a nice 8-byte alignment to the data.
.align 2 would also be sufficient.
> I don't know now how to proceed now, as you (Mark and you) do completely
> the patch.
Please can you test my patch and let us know if it solves your problem
(or even if it works! I haven't tested it beyond build-testing.)
> You see is my first kernel patch submission :) .
Yay. Sorry for giving you a different patch - Mark is quite right that
there's a better solution to this problem, which is eliminating the
set_kernel_text_rw() call. The only reason I cooked up the patch was
doing that would be more in-depth (as you can see from the increased
size of the patch.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-01 20:16 ` Russell King - ARM Linux admin
@ 2021-02-01 22:18 ` Giancarlo Ferrari
-1 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-01 22:18 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
Russell,
On Mon, Feb 01, 2021 at 08:16:33PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 08:07:37PM +0000, Giancarlo Ferrari wrote:
> > Hi,
>
> Hi,
>
> > Why we should align 3 ? For the fncpy I suppose.
>
> Slightly arbitary really - it gives a nice 8-byte alignment to the data.
> .align 2 would also be sufficient.
>
> > I don't know now how to proceed now, as you (Mark and you) do completely
> > the patch.
>
> Please can you test my patch and let us know if it solves your problem
> (or even if it works! I haven't tested it beyond build-testing.)
>
sure, unfortunately due to restriction, I hope to test it by the end of the
week. I hope there will be no rush. Otherwise, please let me know.
> > You see is my first kernel patch submission :) .
>
> Yay. Sorry for giving you a different patch - Mark is quite right that
> there's a better solution to this problem, which is eliminating the
> set_kernel_text_rw() call. The only reason I cooked up the patch was
> doing that would be more in-depth (as you can see from the increased
> size of the patch.)
>
I definitely agree with you.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Thanks again,
GF
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-01 22:18 ` Giancarlo Ferrari
0 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-01 22:18 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
Russell,
On Mon, Feb 01, 2021 at 08:16:33PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 01, 2021 at 08:07:37PM +0000, Giancarlo Ferrari wrote:
> > Hi,
>
> Hi,
>
> > Why we should align 3 ? For the fncpy I suppose.
>
> Slightly arbitary really - it gives a nice 8-byte alignment to the data.
> .align 2 would also be sufficient.
>
> > I don't know now how to proceed now, as you (Mark and you) do completely
> > the patch.
>
> Please can you test my patch and let us know if it solves your problem
> (or even if it works! I haven't tested it beyond build-testing.)
>
sure, unfortunately due to restriction, I hope to test it by the end of the
week. I hope there will be no rush. Otherwise, please let me know.
> > You see is my first kernel patch submission :) .
>
> Yay. Sorry for giving you a different patch - Mark is quite right that
> there's a better solution to this problem, which is eliminating the
> set_kernel_text_rw() call. The only reason I cooked up the patch was
> doing that would be more in-depth (as you can see from the increased
> size of the patch.)
>
I definitely agree with you.
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Thanks again,
GF
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-01 22:18 ` Giancarlo Ferrari
@ 2021-02-04 23:48 ` Giancarlo Ferrari
-1 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-04 23:48 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
Hi all,
On Mon, Feb 01, 2021 at 10:18:26PM +0000, Giancarlo Ferrari wrote:
> Russell,
>
> On Mon, Feb 01, 2021 at 08:16:33PM +0000, Russell King - ARM Linux admin wrote:
> > On Mon, Feb 01, 2021 at 08:07:37PM +0000, Giancarlo Ferrari wrote:
> > > Hi,
> >
> > Hi,
> >
> > > Why we should align 3 ? For the fncpy I suppose.
> >
> > Slightly arbitary really - it gives a nice 8-byte alignment to the data.
> > .align 2 would also be sufficient.
> >
> > > I don't know now how to proceed now, as you (Mark and you) do completely
> > > the patch.
> >
> > Please can you test my patch and let us know if it solves your problem
> > (or even if it works! I haven't tested it beyond build-testing.)
> >
I have tested your patch and it works. I have tested using kexec -l/kexec -e.
Considering that .text var are no more written, I assume the issue is gone.
>
> sure, unfortunately due to restriction, I hope to test it by the end of the
> week. I hope there will be no rush. Otherwise, please let me know.
>
> > > You see is my first kernel patch submission :) .
> >
> > Yay. Sorry for giving you a different patch - Mark is quite right that
> > there's a better solution to this problem, which is eliminating the
> > set_kernel_text_rw() call. The only reason I cooked up the patch was
> > doing that would be more in-depth (as you can see from the increased
> > size of the patch.)
> >
>
> I definitely agree with you.
>
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
> Thanks again,
>
>
> GF
Can I ask about having it integrated ?
Thanks in advance,
GF
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-04 23:48 ` Giancarlo Ferrari
0 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-04 23:48 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
Hi all,
On Mon, Feb 01, 2021 at 10:18:26PM +0000, Giancarlo Ferrari wrote:
> Russell,
>
> On Mon, Feb 01, 2021 at 08:16:33PM +0000, Russell King - ARM Linux admin wrote:
> > On Mon, Feb 01, 2021 at 08:07:37PM +0000, Giancarlo Ferrari wrote:
> > > Hi,
> >
> > Hi,
> >
> > > Why we should align 3 ? For the fncpy I suppose.
> >
> > Slightly arbitary really - it gives a nice 8-byte alignment to the data.
> > .align 2 would also be sufficient.
> >
> > > I don't know now how to proceed now, as you (Mark and you) do completely
> > > the patch.
> >
> > Please can you test my patch and let us know if it solves your problem
> > (or even if it works! I haven't tested it beyond build-testing.)
> >
I have tested your patch and it works. I have tested using kexec -l/kexec -e.
Considering that .text var are no more written, I assume the issue is gone.
>
> sure, unfortunately due to restriction, I hope to test it by the end of the
> week. I hope there will be no rush. Otherwise, please let me know.
>
> > > You see is my first kernel patch submission :) .
> >
> > Yay. Sorry for giving you a different patch - Mark is quite right that
> > there's a better solution to this problem, which is eliminating the
> > set_kernel_text_rw() call. The only reason I cooked up the patch was
> > doing that would be more in-depth (as you can see from the increased
> > size of the patch.)
> >
>
> I definitely agree with you.
>
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
> Thanks again,
>
>
> GF
Can I ask about having it integrated ?
Thanks in advance,
GF
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-04 23:48 ` Giancarlo Ferrari
@ 2021-02-05 0:18 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-05 0:18 UTC (permalink / raw)
To: Giancarlo Ferrari
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> Can I ask about having it integrated ?
Thanks for testing. Are you willing for me to add:
Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
to the commit log?
I can move it into the fixes branch which I want to send to Linus by
Saturday at the very latest.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-05 0:18 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-05 0:18 UTC (permalink / raw)
To: Giancarlo Ferrari
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> Can I ask about having it integrated ?
Thanks for testing. Are you willing for me to add:
Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
to the commit log?
I can move it into the fixes branch which I want to send to Linus by
Saturday at the very latest.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-05 0:18 ` Russell King - ARM Linux admin
@ 2021-02-05 0:40 ` Giancarlo Ferrari
-1 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-05 0:40 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
Russell,
On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > Can I ask about having it integrated ?
>
> Thanks for testing. Are you willing for me to add:
>
> Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
>
> to the commit log?
>
Sure.
I have a question regarding the patch. I saw that the structure start at
the end of the relocation code:
data = reboot_code_buffer + relocate_new_kernel_size;
which means it overlap with the global symbol relocate_new_kernel_size.
I think is minor comment as the variable is only used in the fncpy()
then thrown away. Something like:
data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
adr r7, relocate_new_kernel_end
> I can move it into the fixes branch which I want to send to Linus by
> Saturday at the very latest.
>
I am not used with all the merging process. However it sounds great !
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Thanks in advance,
GF
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-05 0:40 ` Giancarlo Ferrari
0 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-05 0:40 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
Russell,
On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > Can I ask about having it integrated ?
>
> Thanks for testing. Are you willing for me to add:
>
> Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
>
> to the commit log?
>
Sure.
I have a question regarding the patch. I saw that the structure start at
the end of the relocation code:
data = reboot_code_buffer + relocate_new_kernel_size;
which means it overlap with the global symbol relocate_new_kernel_size.
I think is minor comment as the variable is only used in the fncpy()
then thrown away. Something like:
data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
adr r7, relocate_new_kernel_end
> I can move it into the fixes branch which I want to send to Linus by
> Saturday at the very latest.
>
I am not used with all the merging process. However it sounds great !
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Thanks in advance,
GF
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-05 0:40 ` Giancarlo Ferrari
@ 2021-02-05 0:45 ` Giancarlo Ferrari
-1 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-05 0:45 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
Sorry for polluting,
On Fri, Feb 05, 2021 at 12:40:54AM +0000, Giancarlo Ferrari wrote:
> Russell,
>
> On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > > Can I ask about having it integrated ?
> >
> > Thanks for testing. Are you willing for me to add:
> >
> > Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
> >
> > to the commit log?
> >
>
> Sure.
>
> I have a question regarding the patch. I saw that the structure start at
> the end of the relocation code:
>
> data = reboot_code_buffer + relocate_new_kernel_size;
>
> which means it overlap with the global symbol relocate_new_kernel_size.
> I think is minor comment as the variable is only used in the fncpy()
> then thrown away. Something like:
>
> data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
>
> and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
>
> adr r7, relocate_new_kernel_end
>
my fault. Do as I didn't talk... one is in virtual memory the other in the
initial code.
> > I can move it into the fixes branch which I want to send to Linus by
> > Saturday at the very latest.
> >
>
> I am not used with all the merging process. However it sounds great !
>
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
> Thanks in advance,
>
>
> GF
Thanks,
GF
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-05 0:45 ` Giancarlo Ferrari
0 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-05 0:45 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
Sorry for polluting,
On Fri, Feb 05, 2021 at 12:40:54AM +0000, Giancarlo Ferrari wrote:
> Russell,
>
> On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > > Can I ask about having it integrated ?
> >
> > Thanks for testing. Are you willing for me to add:
> >
> > Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
> >
> > to the commit log?
> >
>
> Sure.
>
> I have a question regarding the patch. I saw that the structure start at
> the end of the relocation code:
>
> data = reboot_code_buffer + relocate_new_kernel_size;
>
> which means it overlap with the global symbol relocate_new_kernel_size.
> I think is minor comment as the variable is only used in the fncpy()
> then thrown away. Something like:
>
> data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
>
> and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
>
> adr r7, relocate_new_kernel_end
>
my fault. Do as I didn't talk... one is in virtual memory the other in the
initial code.
> > I can move it into the fixes branch which I want to send to Linus by
> > Saturday at the very latest.
> >
>
> I am not used with all the merging process. However it sounds great !
>
> > --
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
> Thanks in advance,
>
>
> GF
Thanks,
GF
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-05 0:40 ` Giancarlo Ferrari
@ 2021-02-05 9:44 ` Russell King - ARM Linux admin
-1 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-05 9:44 UTC (permalink / raw)
To: Giancarlo Ferrari
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
On Fri, Feb 05, 2021 at 12:40:54AM +0000, Giancarlo Ferrari wrote:
> Russell,
>
> On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > > Can I ask about having it integrated ?
> >
> > Thanks for testing. Are you willing for me to add:
> >
> > Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
> >
> > to the commit log?
> >
>
> Sure.
>
> I have a question regarding the patch. I saw that the structure start at
> the end of the relocation code:
>
> data = reboot_code_buffer + relocate_new_kernel_size;
>
> which means it overlap with the global symbol relocate_new_kernel_size.
> I think is minor comment as the variable is only used in the fncpy()
> then thrown away.
The same is true of the rest of the kernel image if that's how you'd
like to look at it.
relocate_new_kernel_size is just there to tell the C code the size of
the function, nothing more nothing less. It isn't there to be copied.
The copied code doesn't use it.
> Something like:
>
> data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
No. That will place the structure after the size variable, which we
don't want, and...
> and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
>
> adr r7, relocate_new_kernel_end
... we will then need to follow this with:
add r7, r7, #4
or replace it with:
adr r7, relocate_new_kernel_end + 4
so that r7 points at "data".
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-05 9:44 ` Russell King - ARM Linux admin
0 siblings, 0 replies; 44+ messages in thread
From: Russell King - ARM Linux admin @ 2021-02-05 9:44 UTC (permalink / raw)
To: Giancarlo Ferrari
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
On Fri, Feb 05, 2021 at 12:40:54AM +0000, Giancarlo Ferrari wrote:
> Russell,
>
> On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > > Can I ask about having it integrated ?
> >
> > Thanks for testing. Are you willing for me to add:
> >
> > Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
> >
> > to the commit log?
> >
>
> Sure.
>
> I have a question regarding the patch. I saw that the structure start at
> the end of the relocation code:
>
> data = reboot_code_buffer + relocate_new_kernel_size;
>
> which means it overlap with the global symbol relocate_new_kernel_size.
> I think is minor comment as the variable is only used in the fncpy()
> then thrown away.
The same is true of the rest of the kernel image if that's how you'd
like to look at it.
relocate_new_kernel_size is just there to tell the C code the size of
the function, nothing more nothing less. It isn't there to be copied.
The copied code doesn't use it.
> Something like:
>
> data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
No. That will place the structure after the size variable, which we
don't want, and...
> and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
>
> adr r7, relocate_new_kernel_end
... we will then need to follow this with:
add r7, r7, #4
or replace it with:
adr r7, relocate_new_kernel_end + 4
so that r7 points at "data".
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
2021-02-05 9:44 ` Russell King - ARM Linux admin
@ 2021-02-05 14:36 ` Giancarlo Ferrari
-1 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-05 14:36 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, linux-arm-kernel,
akpm, rppt, giancarlo.ferrari
On Fri, Feb 05, 2021 at 09:44:59AM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Feb 05, 2021 at 12:40:54AM +0000, Giancarlo Ferrari wrote:
> > Russell,
> >
> > On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> > > On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > > > Can I ask about having it integrated ?
> > >
> > > Thanks for testing. Are you willing for me to add:
> > >
> > > Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
> > >
> > > to the commit log?
> > >
> >
> > Sure.
> >
> > I have a question regarding the patch. I saw that the structure start at
> > the end of the relocation code:
> >
> > data = reboot_code_buffer + relocate_new_kernel_size;
> >
> > which means it overlap with the global symbol relocate_new_kernel_size.
> > I think is minor comment as the variable is only used in the fncpy()
> > then thrown away.
>
> The same is true of the rest of the kernel image if that's how you'd
> like to look at it.
>
> relocate_new_kernel_size is just there to tell the C code the size of
> the function, nothing more nothing less. It isn't there to be copied.
> The copied code doesn't use it.
>
Yes, clear.
> > Something like:
> >
> > data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
>
> No. That will place the structure after the size variable, which we
> don't want, and...
>
> > and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
> >
> > adr r7, relocate_new_kernel_end
>
> ... we will then need to follow this with:
> add r7, r7, #4
>
> or replace it with:
> adr r7, relocate_new_kernel_end + 4
>
> so that r7 points at "data".
>
It was what I meant with "accordingly".
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Regards,
GF
^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [PATCH] ARM: kexec: Fix panic after TLB are invalidated
@ 2021-02-05 14:36 ` Giancarlo Ferrari
0 siblings, 0 replies; 44+ messages in thread
From: Giancarlo Ferrari @ 2021-02-05 14:36 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, linux-kernel, penberg, geert, rppt, akpm,
linux-arm-kernel, giancarlo.ferrari
On Fri, Feb 05, 2021 at 09:44:59AM +0000, Russell King - ARM Linux admin wrote:
> On Fri, Feb 05, 2021 at 12:40:54AM +0000, Giancarlo Ferrari wrote:
> > Russell,
> >
> > On Fri, Feb 05, 2021 at 12:18:33AM +0000, Russell King - ARM Linux admin wrote:
> > > On Thu, Feb 04, 2021 at 11:48:42PM +0000, Giancarlo Ferrari wrote:
> > > > Can I ask about having it integrated ?
> > >
> > > Thanks for testing. Are you willing for me to add:
> > >
> > > Tested-by: Giancarlo Ferrari <giancarlo.ferrari89@gmail.com>
> > >
> > > to the commit log?
> > >
> >
> > Sure.
> >
> > I have a question regarding the patch. I saw that the structure start at
> > the end of the relocation code:
> >
> > data = reboot_code_buffer + relocate_new_kernel_size;
> >
> > which means it overlap with the global symbol relocate_new_kernel_size.
> > I think is minor comment as the variable is only used in the fncpy()
> > then thrown away.
>
> The same is true of the rest of the kernel image if that's how you'd
> like to look at it.
>
> relocate_new_kernel_size is just there to tell the C code the size of
> the function, nothing more nothing less. It isn't there to be copied.
> The copied code doesn't use it.
>
Yes, clear.
> > Something like:
> >
> > data = reboot_code_buffer + relocate_new_kernel_size + sizeof(long);
>
> No. That will place the structure after the size variable, which we
> don't want, and...
>
> > and accordingly in the instruction (arch/arm/kernel/relocate_kernel.S):
> >
> > adr r7, relocate_new_kernel_end
>
> ... we will then need to follow this with:
> add r7, r7, #4
>
> or replace it with:
> adr r7, relocate_new_kernel_end + 4
>
> so that r7 points at "data".
>
It was what I meant with "accordingly".
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Regards,
GF
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 44+ messages in thread