* [PATCH 0/2] Simple fix to the ARM kexec tools implementation @ 2016-06-17 19:44 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-17 19:44 UTC (permalink / raw) To: linux-arm-kernel This is the "simple" fix for the ARM kexec tools code, which makes the code actually do what the comments describe. There are two problems: 1. When placing the initrd, we do not take account of the 32k offset that is required for the kernel image. 2. The code claims to allow the zImage decompressor to expand by a factor of 4, but only allows space for a factor of 3, since the decompressor itself has to fit in this memory space as well. Changing the code to follow the comments allows Keystone II to kexec with DEBUG_RODATA enabled, at least with the kernel I've been testing with. This is a stop-gap solution until a better solution can be implemented. kexec/arch/arm/kexec-zImage-arm.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 0/2] Simple fix to the ARM kexec tools implementation @ 2016-06-17 19:44 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-17 19:44 UTC (permalink / raw) To: Kees Cook, Simon Horman, Baoquan He, Pratyush Anand Cc: kexec, linux-arm-kernel This is the "simple" fix for the ARM kexec tools code, which makes the code actually do what the comments describe. There are two problems: 1. When placing the initrd, we do not take account of the 32k offset that is required for the kernel image. 2. The code claims to allow the zImage decompressor to expand by a factor of 4, but only allows space for a factor of 3, since the decompressor itself has to fit in this memory space as well. Changing the code to follow the comments allows Keystone II to kexec with DEBUG_RODATA enabled, at least with the kernel I've been testing with. This is a stop-gap solution until a better solution can be implemented. kexec/arch/arm/kexec-zImage-arm.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 1/2] arm: take account of TEXT_OFFSET for subsequent images 2016-06-17 19:44 ` Russell King - ARM Linux @ 2016-06-17 19:44 ` Russell King -1 siblings, 0 replies; 43+ messages in thread From: Russell King @ 2016-06-17 19:44 UTC (permalink / raw) To: linux-arm-kernel The ARM kexec code was not taking account of the 32k text offset when applying the size(s) of the kernel image. We need to take account of this so when we decide to place the initrd at 4x the compressed image length, it is appropriately placed. Signed-off-by: Russell King <rmk@armlinux.org.uk> --- kexec/arch/arm/kexec-zImage-arm.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c index aab0c861..297b7fd8 100644 --- a/kexec/arch/arm/kexec-zImage-arm.c +++ b/kexec/arch/arm/kexec-zImage-arm.c @@ -340,7 +340,7 @@ static int setup_dtb_prop(char **bufp, off_t *sizep, int parentoffset, int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, struct kexec_info *info) { - unsigned long base; + unsigned long base, kernel_base; unsigned int atag_offset = 0x1000; /* 4k offset from memory start */ unsigned int extra_size = 0x8000; /* TEXT_OFFSET */ const char *command_line; @@ -517,15 +517,17 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, if (base == ULONG_MAX) return -1; + kernel_base = base + extra_size; + if (kexec_arm_image_size) { /* If the image size was passed as command line argument, * use that value for determining the address for initrd, * atags and dtb images. page-align the given length.*/ - initrd_base = base + _ALIGN(kexec_arm_image_size, getpagesize()); + initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, getpagesize()); } else { /* Otherwise, assume the maximum kernel compression ratio * is 4, and just to be safe, place ramdisk after that */ - initrd_base = base + _ALIGN(len * 4, getpagesize()); + initrd_base = kernel_base + _ALIGN(len * 4, getpagesize()); } if (use_atags) { @@ -617,9 +619,9 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, dtb_offset, dtb_length); } - add_segment(info, buf, len, base + extra_size, len); + add_segment(info, buf, len, kernel_base, len); - info->entry = (void*)base + extra_size; + info->entry = (void*)kernel_base; return 0; } -- 1.9.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 1/2] arm: take account of TEXT_OFFSET for subsequent images @ 2016-06-17 19:44 ` Russell King 0 siblings, 0 replies; 43+ messages in thread From: Russell King @ 2016-06-17 19:44 UTC (permalink / raw) To: Kees Cook, Simon Horman, Baoquan He, Pratyush Anand Cc: kexec, linux-arm-kernel The ARM kexec code was not taking account of the 32k text offset when applying the size(s) of the kernel image. We need to take account of this so when we decide to place the initrd at 4x the compressed image length, it is appropriately placed. Signed-off-by: Russell King <rmk@armlinux.org.uk> --- kexec/arch/arm/kexec-zImage-arm.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c index aab0c861..297b7fd8 100644 --- a/kexec/arch/arm/kexec-zImage-arm.c +++ b/kexec/arch/arm/kexec-zImage-arm.c @@ -340,7 +340,7 @@ static int setup_dtb_prop(char **bufp, off_t *sizep, int parentoffset, int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, struct kexec_info *info) { - unsigned long base; + unsigned long base, kernel_base; unsigned int atag_offset = 0x1000; /* 4k offset from memory start */ unsigned int extra_size = 0x8000; /* TEXT_OFFSET */ const char *command_line; @@ -517,15 +517,17 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, if (base == ULONG_MAX) return -1; + kernel_base = base + extra_size; + if (kexec_arm_image_size) { /* If the image size was passed as command line argument, * use that value for determining the address for initrd, * atags and dtb images. page-align the given length.*/ - initrd_base = base + _ALIGN(kexec_arm_image_size, getpagesize()); + initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, getpagesize()); } else { /* Otherwise, assume the maximum kernel compression ratio * is 4, and just to be safe, place ramdisk after that */ - initrd_base = base + _ALIGN(len * 4, getpagesize()); + initrd_base = kernel_base + _ALIGN(len * 4, getpagesize()); } if (use_atags) { @@ -617,9 +619,9 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, dtb_offset, dtb_length); } - add_segment(info, buf, len, base + extra_size, len); + add_segment(info, buf, len, kernel_base, len); - info->entry = (void*)base + extra_size; + info->entry = (void*)kernel_base; return 0; } -- 1.9.1 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size 2016-06-17 19:44 ` Russell King - ARM Linux @ 2016-06-17 19:44 ` Russell King -1 siblings, 0 replies; 43+ messages in thread From: Russell King @ 2016-06-17 19:44 UTC (permalink / raw) To: linux-arm-kernel If we want to assume that the compressed image will expand by a maximum of 4x, we actually need to reserve 5x the space, since we need to keep a copy of the compessed image around while decompressing. Signed-off-by: Russell King <rmk@armlinux.org.uk> --- kexec/arch/arm/kexec-zImage-arm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c index 297b7fd8..9400d1f4 100644 --- a/kexec/arch/arm/kexec-zImage-arm.c +++ b/kexec/arch/arm/kexec-zImage-arm.c @@ -526,8 +526,10 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, getpagesize()); } else { /* Otherwise, assume the maximum kernel compression ratio - * is 4, and just to be safe, place ramdisk after that */ - initrd_base = kernel_base + _ALIGN(len * 4, getpagesize()); + * is 4, and just to be safe, place ramdisk after that. + * Note that we must include space for the compressed + * image here as well. */ + initrd_base = kernel_base + _ALIGN(len * 5, getpagesize()); } if (use_atags) { -- 1.9.1 ^ permalink raw reply related [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-17 19:44 ` Russell King 0 siblings, 0 replies; 43+ messages in thread From: Russell King @ 2016-06-17 19:44 UTC (permalink / raw) To: Kees Cook, Simon Horman, Baoquan He, Pratyush Anand Cc: kexec, linux-arm-kernel If we want to assume that the compressed image will expand by a maximum of 4x, we actually need to reserve 5x the space, since we need to keep a copy of the compessed image around while decompressing. Signed-off-by: Russell King <rmk@armlinux.org.uk> --- kexec/arch/arm/kexec-zImage-arm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c index 297b7fd8..9400d1f4 100644 --- a/kexec/arch/arm/kexec-zImage-arm.c +++ b/kexec/arch/arm/kexec-zImage-arm.c @@ -526,8 +526,10 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, initrd_base = kernel_base + _ALIGN(kexec_arm_image_size, getpagesize()); } else { /* Otherwise, assume the maximum kernel compression ratio - * is 4, and just to be safe, place ramdisk after that */ - initrd_base = kernel_base + _ALIGN(len * 4, getpagesize()); + * is 4, and just to be safe, place ramdisk after that. + * Note that we must include space for the compressed + * image here as well. */ + initrd_base = kernel_base + _ALIGN(len * 5, getpagesize()); } if (use_atags) { -- 1.9.1 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 43+ messages in thread
[parent not found: <E1bDzh4-0006a4-7p-yeZebKftTXNiEPTqdM/vLBqCBvEC6TWiNEsB0oqw8pBaa/9Udqfwiw@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-17 19:44 ` Russell King (?) @ 2016-06-21 7:43 ` Tony Lindgren -1 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 7:43 UTC (permalink / raw) To: Russell King Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Hi, * Russell King <rmk-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160617 12:52]: > If we want to assume that the compressed image will expand by a maximum > of 4x, we actually need to reserve 5x the space, since we need to keep > a copy of the compessed image around while decompressing. Looks like 5x is not enough with omap2plus_defconfig at least.. This one needs to be set to 6x for that. Maybe we should just make it go all the way to 11 :) Otherwise we get this without initrd: kernel: 0xb6c2d008 kernel_size: 0x3a4418 MEMORY RANGES 0000000080000000-00000000bfdfffff (0) kexec_load: entry = 0x80008000 flags = 0x280000 nr_segments = 2 segment[0].buf = 0xb6c2d008 segment[0].bufsz = 0x3a4418 segment[0].mem = 0x80008000 segment[0].memsz = 0x3a5000 segment[1].buf = 0xadf80 segment[1].bufsz = 0xe000 segment[1].mem = 0x8123f000 segment[1].memsz = 0xe000 [ 32.886077] kexec_core: Starting new kernel [ 32.890502] Disabling non-boot CPUs ... [ 32.926696] CPU1: shutdown [ 32.991882] Bye! Warning: Neither atags nor dtb found And we get this with initrd: kernel: 0xb6bf4008 kernel_size: 0x3a4418 MEMORY RANGES 0000000080000000-00000000fedfffff (0) kexec_load: entry = 0x80008000 flags = 0x280000 nr_segments = 3 segment[0].buf = 0xb6bf4008 segment[0].bufsz = 0x3a4418 segment[0].mem = 0x80008000 segment[0].memsz = 0x3a5000 segment[1].buf = 0xb6686008 segment[1].bufsz = 0x56dba2 segment[1].mem = 0x8123e000 segment[1].memsz = 0x56e000 segment[2].buf = 0xadf80 segment[2].bufsz = 0xd080 segment[2].mem = 0x817ac000 segment[2].memsz = 0xe000 ... INITRD: 0x8123e000+0x0056dba2 overlaps in-use memory region - disabling initrd Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 7:43 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 7:43 UTC (permalink / raw) To: Russell King Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel Hi, * Russell King <rmk@armlinux.org.uk> [160617 12:52]: > If we want to assume that the compressed image will expand by a maximum > of 4x, we actually need to reserve 5x the space, since we need to keep > a copy of the compessed image around while decompressing. Looks like 5x is not enough with omap2plus_defconfig at least.. This one needs to be set to 6x for that. Maybe we should just make it go all the way to 11 :) Otherwise we get this without initrd: kernel: 0xb6c2d008 kernel_size: 0x3a4418 MEMORY RANGES 0000000080000000-00000000bfdfffff (0) kexec_load: entry = 0x80008000 flags = 0x280000 nr_segments = 2 segment[0].buf = 0xb6c2d008 segment[0].bufsz = 0x3a4418 segment[0].mem = 0x80008000 segment[0].memsz = 0x3a5000 segment[1].buf = 0xadf80 segment[1].bufsz = 0xe000 segment[1].mem = 0x8123f000 segment[1].memsz = 0xe000 [ 32.886077] kexec_core: Starting new kernel [ 32.890502] Disabling non-boot CPUs ... [ 32.926696] CPU1: shutdown [ 32.991882] Bye! Warning: Neither atags nor dtb found And we get this with initrd: kernel: 0xb6bf4008 kernel_size: 0x3a4418 MEMORY RANGES 0000000080000000-00000000fedfffff (0) kexec_load: entry = 0x80008000 flags = 0x280000 nr_segments = 3 segment[0].buf = 0xb6bf4008 segment[0].bufsz = 0x3a4418 segment[0].mem = 0x80008000 segment[0].memsz = 0x3a5000 segment[1].buf = 0xb6686008 segment[1].bufsz = 0x56dba2 segment[1].mem = 0x8123e000 segment[1].memsz = 0x56e000 segment[2].buf = 0xadf80 segment[2].bufsz = 0xd080 segment[2].mem = 0x817ac000 segment[2].memsz = 0xe000 ... INITRD: 0x8123e000+0x0056dba2 overlaps in-use memory region - disabling initrd Regards, Tony _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 7:43 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 7:43 UTC (permalink / raw) To: linux-arm-kernel Hi, * Russell King <rmk@armlinux.org.uk> [160617 12:52]: > If we want to assume that the compressed image will expand by a maximum > of 4x, we actually need to reserve 5x the space, since we need to keep > a copy of the compessed image around while decompressing. Looks like 5x is not enough with omap2plus_defconfig at least.. This one needs to be set to 6x for that. Maybe we should just make it go all the way to 11 :) Otherwise we get this without initrd: kernel: 0xb6c2d008 kernel_size: 0x3a4418 MEMORY RANGES 0000000080000000-00000000bfdfffff (0) kexec_load: entry = 0x80008000 flags = 0x280000 nr_segments = 2 segment[0].buf = 0xb6c2d008 segment[0].bufsz = 0x3a4418 segment[0].mem = 0x80008000 segment[0].memsz = 0x3a5000 segment[1].buf = 0xadf80 segment[1].bufsz = 0xe000 segment[1].mem = 0x8123f000 segment[1].memsz = 0xe000 [ 32.886077] kexec_core: Starting new kernel [ 32.890502] Disabling non-boot CPUs ... [ 32.926696] CPU1: shutdown [ 32.991882] Bye! Warning: Neither atags nor dtb found And we get this with initrd: kernel: 0xb6bf4008 kernel_size: 0x3a4418 MEMORY RANGES 0000000080000000-00000000fedfffff (0) kexec_load: entry = 0x80008000 flags = 0x280000 nr_segments = 3 segment[0].buf = 0xb6bf4008 segment[0].bufsz = 0x3a4418 segment[0].mem = 0x80008000 segment[0].memsz = 0x3a5000 segment[1].buf = 0xb6686008 segment[1].bufsz = 0x56dba2 segment[1].mem = 0x8123e000 segment[1].memsz = 0x56e000 segment[2].buf = 0xadf80 segment[2].bufsz = 0xd080 segment[2].mem = 0x817ac000 segment[2].memsz = 0xe000 ... INITRD: 0x8123e000+0x0056dba2 overlaps in-use memory region - disabling initrd Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160621074319.GH22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-21 7:43 ` Tony Lindgren (?) @ 2016-06-21 9:47 ` Russell King - ARM Linux -1 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 9:47 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote: > Hi, > > * Russell King <rmk-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160617 12:52]: > > If we want to assume that the compressed image will expand by a maximum > > of 4x, we actually need to reserve 5x the space, since we need to keep > > a copy of the compessed image around while decompressing. > > Looks like 5x is not enough with omap2plus_defconfig at least.. > This one needs to be set to 6x for that. Maybe we should just make > it go all the way to 11 :) That's not really what this commit is about - it's about making the code consistent with the comments in the file. I could have instead changed the comment saying "4x" to "3x" instead. There isn't really an answer which will always work for this problem, as I've already detailed in a previous thread discussing the issue. Adding a zImage header don't fix the problem. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 9:47 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 9:47 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote: > Hi, > > * Russell King <rmk@armlinux.org.uk> [160617 12:52]: > > If we want to assume that the compressed image will expand by a maximum > > of 4x, we actually need to reserve 5x the space, since we need to keep > > a copy of the compessed image around while decompressing. > > Looks like 5x is not enough with omap2plus_defconfig at least.. > This one needs to be set to 6x for that. Maybe we should just make > it go all the way to 11 :) That's not really what this commit is about - it's about making the code consistent with the comments in the file. I could have instead changed the comment saying "4x" to "3x" instead. There isn't really an answer which will always work for this problem, as I've already detailed in a previous thread discussing the issue. Adding a zImage header don't fix the problem. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 9:47 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 9:47 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote: > Hi, > > * Russell King <rmk@armlinux.org.uk> [160617 12:52]: > > If we want to assume that the compressed image will expand by a maximum > > of 4x, we actually need to reserve 5x the space, since we need to keep > > a copy of the compessed image around while decompressing. > > Looks like 5x is not enough with omap2plus_defconfig at least.. > This one needs to be set to 6x for that. Maybe we should just make > it go all the way to 11 :) That's not really what this commit is about - it's about making the code consistent with the comments in the file. I could have instead changed the comment saying "4x" to "3x" instead. There isn't really an answer which will always work for this problem, as I've already detailed in a previous thread discussing the issue. Adding a zImage header don't fix the problem. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160621094737.GA5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-21 9:47 ` Russell King - ARM Linux (?) @ 2016-06-21 10:38 ` Tony Lindgren -1 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 10:38 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 02:50]: > On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Russell King <rmk-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160617 12:52]: > > > If we want to assume that the compressed image will expand by a maximum > > > of 4x, we actually need to reserve 5x the space, since we need to keep > > > a copy of the compessed image around while decompressing. > > > > Looks like 5x is not enough with omap2plus_defconfig at least.. > > This one needs to be set to 6x for that. Maybe we should just make > > it go all the way to 11 :) > > That's not really what this commit is about - it's about making the > code consistent with the comments in the file. I could have instead > changed the comment saying "4x" to "3x" instead. > > There isn't really an answer which will always work for this problem, > as I've already detailed in a previous thread discussing the issue. > Adding a zImage header don't fix the problem. Well how about we change both comments and code to use a value that works? Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 10:38 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 10:38 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 02:50]: > On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Russell King <rmk@armlinux.org.uk> [160617 12:52]: > > > If we want to assume that the compressed image will expand by a maximum > > > of 4x, we actually need to reserve 5x the space, since we need to keep > > > a copy of the compessed image around while decompressing. > > > > Looks like 5x is not enough with omap2plus_defconfig at least.. > > This one needs to be set to 6x for that. Maybe we should just make > > it go all the way to 11 :) > > That's not really what this commit is about - it's about making the > code consistent with the comments in the file. I could have instead > changed the comment saying "4x" to "3x" instead. > > There isn't really an answer which will always work for this problem, > as I've already detailed in a previous thread discussing the issue. > Adding a zImage header don't fix the problem. Well how about we change both comments and code to use a value that works? Tony _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 10:38 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 10:38 UTC (permalink / raw) To: linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 02:50]: > On Tue, Jun 21, 2016 at 12:43:21AM -0700, Tony Lindgren wrote: > > Hi, > > > > * Russell King <rmk@armlinux.org.uk> [160617 12:52]: > > > If we want to assume that the compressed image will expand by a maximum > > > of 4x, we actually need to reserve 5x the space, since we need to keep > > > a copy of the compessed image around while decompressing. > > > > Looks like 5x is not enough with omap2plus_defconfig at least.. > > This one needs to be set to 6x for that. Maybe we should just make > > it go all the way to 11 :) > > That's not really what this commit is about - it's about making the > code consistent with the comments in the file. I could have instead > changed the comment saying "4x" to "3x" instead. > > There isn't really an answer which will always work for this problem, > as I've already detailed in a previous thread discussing the issue. > Adding a zImage header don't fix the problem. Well how about we change both comments and code to use a value that works? Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160621103810.GI22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-21 10:38 ` Tony Lindgren (?) @ 2016-06-21 10:57 ` Tony Lindgren -1 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 10:57 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160621 03:41]: > * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 02:50]: > > > > There isn't really an answer which will always work for this problem, > > as I've already detailed in a previous thread discussing the issue. > > Adding a zImage header don't fix the problem. > > Well how about we change both comments and code to use a value > that works? Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we think is sufficient to kick the can until we have a better solution. Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 10:57 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 10:57 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel * Tony Lindgren <tony@atomide.com> [160621 03:41]: > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 02:50]: > > > > There isn't really an answer which will always work for this problem, > > as I've already detailed in a previous thread discussing the issue. > > Adding a zImage header don't fix the problem. > > Well how about we change both comments and code to use a value > that works? Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we think is sufficient to kick the can until we have a better solution. Regards, Tony _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 10:57 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 10:57 UTC (permalink / raw) To: linux-arm-kernel * Tony Lindgren <tony@atomide.com> [160621 03:41]: > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 02:50]: > > > > There isn't really an answer which will always work for this problem, > > as I've already detailed in a previous thread discussing the issue. > > Adding a zImage header don't fix the problem. > > Well how about we change both comments and code to use a value > that works? Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we think is sufficient to kick the can until we have a better solution. Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160621105720.GK22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-21 10:57 ` Tony Lindgren (?) @ 2016-06-21 15:44 ` Russell King - ARM Linux -1 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 15:44 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160621 03:41]: > > * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 02:50]: > > > > > > There isn't really an answer which will always work for this problem, > > > as I've already detailed in a previous thread discussing the issue. > > > Adding a zImage header don't fix the problem. > > > > Well how about we change both comments and code to use a value > > that works? > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > think is sufficient to kick the can until we have a better > solution. Maybe if you give some details about your failing case - you omitted any details about the uncompressed image size... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 15:44 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 15:44 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [160621 03:41]: > > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 02:50]: > > > > > > There isn't really an answer which will always work for this problem, > > > as I've already detailed in a previous thread discussing the issue. > > > Adding a zImage header don't fix the problem. > > > > Well how about we change both comments and code to use a value > > that works? > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > think is sufficient to kick the can until we have a better > solution. Maybe if you give some details about your failing case - you omitted any details about the uncompressed image size... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 15:44 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 15:44 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [160621 03:41]: > > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 02:50]: > > > > > > There isn't really an answer which will always work for this problem, > > > as I've already detailed in a previous thread discussing the issue. > > > Adding a zImage header don't fix the problem. > > > > Well how about we change both comments and code to use a value > > that works? > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > think is sufficient to kick the can until we have a better > solution. Maybe if you give some details about your failing case - you omitted any details about the uncompressed image size... -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160621154407.GB5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-21 15:44 ` Russell King - ARM Linux (?) @ 2016-06-21 16:55 ` Tony Lindgren -1 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 16:55 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 08:46]: > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > > > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > > think is sufficient to kick the can until we have a better > > solution. > > Maybe if you give some details about your failing case - you omitted any > details about the uncompressed image size... Looks like we currently have this: Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata, 2312K rodata, 1024K init, 8117K bss, 45628K reserved, 16384K cma-reserved, 1292284K highmem) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .text : 0xc0008000 - 0xc0a762a4 (10681 kB) .init : 0xc0b00000 - 0xc0c00000 (1024 kB) .data : 0xc0c00000 - 0xc0cc411c ( 785 kB) .bss : 0xc0cc6000 - 0xc14b37f8 (8118 kB) Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 16:55 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 16:55 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 08:46]: > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > > > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > > think is sufficient to kick the can until we have a better > > solution. > > Maybe if you give some details about your failing case - you omitted any > details about the uncompressed image size... Looks like we currently have this: Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata, 2312K rodata, 1024K init, 8117K bss, 45628K reserved, 16384K cma-reserved, 1292284K highmem) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .text : 0xc0008000 - 0xc0a762a4 (10681 kB) .init : 0xc0b00000 - 0xc0c00000 (1024 kB) .data : 0xc0c00000 - 0xc0cc411c ( 785 kB) .bss : 0xc0cc6000 - 0xc14b37f8 (8118 kB) Regards, Tony _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 16:55 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-21 16:55 UTC (permalink / raw) To: linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 08:46]: > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > > > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > > think is sufficient to kick the can until we have a better > > solution. > > Maybe if you give some details about your failing case - you omitted any > details about the uncompressed image size... Looks like we currently have this: Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata, 2312K rodata, 1024K init, 8117K bss, 45628K reserved, 16384K cma-reserved, 1292284K highmem) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .text : 0xc0008000 - 0xc0a762a4 (10681 kB) .init : 0xc0b00000 - 0xc0c00000 (1024 kB) .data : 0xc0c00000 - 0xc0cc411c ( 785 kB) .bss : 0xc0cc6000 - 0xc14b37f8 (8118 kB) Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160621165523.GY22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-21 16:55 ` Tony Lindgren (?) @ 2016-06-21 21:51 ` Russell King - ARM Linux -1 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 21:51 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Tue, Jun 21, 2016 at 09:55:25AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 08:46]: > > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > > > > > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > > > > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > > > think is sufficient to kick the can until we have a better > > > solution. > > > > Maybe if you give some details about your failing case - you omitted any > > details about the uncompressed image size... > > Looks like we currently have this: > > Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata, > 2312K rodata, 1024K init, 8117K bss, 45628K reserved, > 16384K cma-reserved, 1292284K highmem) > Virtual kernel memory layout: > vector : 0xffff0000 - 0xffff1000 ( 4 kB) > fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) > lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) > pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > .text : 0xc0008000 - 0xc0a762a4 (10681 kB) > .init : 0xc0b00000 - 0xc0c00000 (1024 kB) > .data : 0xc0c00000 - 0xc0cc411c ( 785 kB) > .bss : 0xc0cc6000 - 0xc14b37f8 (8118 kB) So that's 20.7MB, and the zImage was 3.6MB. You're getting an expansion ratio of 5.7x. To fix that, we'd need to up it to 7x, but the problem with upping it in this way is that it increases the requirements for the crashdump region too. We can play with this number, but there will always be cases where it doesn't work - either because the ratio is too big or too small. By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" doesn't even work for this case, since you need about 25MB. Your calculation comes out at 22MB, which is 3MB short. Not only that, but it introduces (from what I can see) an irrelevant fudge factor of "MAX_RODATA_SZ" which has no basis in what's really going on here, and I'm left wondering what "MAX_RODATA_SZ" is actually referring to. So... I'm of the opinion that we shouldn't play with it - but instead try to come up with a solution which *doesn't* involve teaching kexec a whole load of internals about how the ARM kernel booting happens. What's more worrying to me at the moment, though, is that the kexec code only tries to find memory for the actual "kernel" size, not the actual space required to decompress the kernel. It could find a chunk of memory large enough to fit the kernel image to be loaded, but is not big enough to allow its decompression. kexec is really quite a mess on ARM. :( -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 21:51 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 21:51 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel On Tue, Jun 21, 2016 at 09:55:25AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 08:46]: > > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > > > > > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > > > > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > > > think is sufficient to kick the can until we have a better > > > solution. > > > > Maybe if you give some details about your failing case - you omitted any > > details about the uncompressed image size... > > Looks like we currently have this: > > Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata, > 2312K rodata, 1024K init, 8117K bss, 45628K reserved, > 16384K cma-reserved, 1292284K highmem) > Virtual kernel memory layout: > vector : 0xffff0000 - 0xffff1000 ( 4 kB) > fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) > lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) > pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > .text : 0xc0008000 - 0xc0a762a4 (10681 kB) > .init : 0xc0b00000 - 0xc0c00000 (1024 kB) > .data : 0xc0c00000 - 0xc0cc411c ( 785 kB) > .bss : 0xc0cc6000 - 0xc14b37f8 (8118 kB) So that's 20.7MB, and the zImage was 3.6MB. You're getting an expansion ratio of 5.7x. To fix that, we'd need to up it to 7x, but the problem with upping it in this way is that it increases the requirements for the crashdump region too. We can play with this number, but there will always be cases where it doesn't work - either because the ratio is too big or too small. By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" doesn't even work for this case, since you need about 25MB. Your calculation comes out at 22MB, which is 3MB short. Not only that, but it introduces (from what I can see) an irrelevant fudge factor of "MAX_RODATA_SZ" which has no basis in what's really going on here, and I'm left wondering what "MAX_RODATA_SZ" is actually referring to. So... I'm of the opinion that we shouldn't play with it - but instead try to come up with a solution which *doesn't* involve teaching kexec a whole load of internals about how the ARM kernel booting happens. What's more worrying to me at the moment, though, is that the kexec code only tries to find memory for the actual "kernel" size, not the actual space required to decompress the kernel. It could find a chunk of memory large enough to fit the kernel image to be loaded, but is not big enough to allow its decompression. kexec is really quite a mess on ARM. :( -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-21 21:51 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 21:51 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 21, 2016 at 09:55:25AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 08:46]: > > On Tue, Jun 21, 2016 at 03:57:20AM -0700, Tony Lindgren wrote: > > > > > > Maybe zImage size + MAX_RODATA_SZ + 4x zImage size? > > > > > > Then the MAX_RODATA_SZ could be 2 or 4 MB or whatever we > > > think is sufficient to kick the can until we have a better > > > solution. > > > > Maybe if you give some details about your failing case - you omitted any > > details about the uncompressed image size... > > Looks like we currently have this: > > Memory: 2033088K/2095100K available (7376K kernel code, 784K rwdata, > 2312K rodata, 1024K init, 8117K bss, 45628K reserved, > 16384K cma-reserved, 1292284K highmem) > Virtual kernel memory layout: > vector : 0xffff0000 - 0xffff1000 ( 4 kB) > fixmap : 0xffc00000 - 0xfff00000 (3072 kB) > vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) > lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) > pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) > modules : 0xbf000000 - 0xbfe00000 ( 14 MB) > .text : 0xc0008000 - 0xc0a762a4 (10681 kB) > .init : 0xc0b00000 - 0xc0c00000 (1024 kB) > .data : 0xc0c00000 - 0xc0cc411c ( 785 kB) > .bss : 0xc0cc6000 - 0xc14b37f8 (8118 kB) So that's 20.7MB, and the zImage was 3.6MB. You're getting an expansion ratio of 5.7x. To fix that, we'd need to up it to 7x, but the problem with upping it in this way is that it increases the requirements for the crashdump region too. We can play with this number, but there will always be cases where it doesn't work - either because the ratio is too big or too small. By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" doesn't even work for this case, since you need about 25MB. Your calculation comes out at 22MB, which is 3MB short. Not only that, but it introduces (from what I can see) an irrelevant fudge factor of "MAX_RODATA_SZ" which has no basis in what's really going on here, and I'm left wondering what "MAX_RODATA_SZ" is actually referring to. So... I'm of the opinion that we shouldn't play with it - but instead try to come up with a solution which *doesn't* involve teaching kexec a whole load of internals about how the ARM kernel booting happens. What's more worrying to me at the moment, though, is that the kexec code only tries to find memory for the actual "kernel" size, not the actual space required to decompress the kernel. It could find a chunk of memory large enough to fit the kernel image to be loaded, but is not big enough to allow its decompression. kexec is really quite a mess on ARM. :( -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160621215141.GC5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-21 21:51 ` Russell King - ARM Linux (?) @ 2016-06-22 7:36 ` Tony Lindgren -1 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-22 7:36 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 14:54]: > So that's 20.7MB, and the zImage was 3.6MB. You're getting an > expansion ratio of 5.7x. > > To fix that, we'd need to up it to 7x, but the problem with upping > it in this way is that it increases the requirements for the > crashdump region too. We can play with this number, but there will > always be cases where it doesn't work - either because the ratio is > too big or too small. OK > By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" > doesn't even work for this case, since you need about 25MB. Your > calculation comes out at 22MB, which is 3MB short. Not only that, but > it introduces (from what I can see) an irrelevant fudge factor of > "MAX_RODATA_SZ" which has no basis in what's really going on here, and > I'm left wondering what "MAX_RODATA_SZ" is actually referring to. Well I thinking the section alignment split might give us some known size for rodata, but looking at it more it's only with DEBUG_ALIGN_RODATA. If we can't make any assumptions about the size of the rodata, then no point adding it. > So... I'm of the opinion that we shouldn't play with it - but instead > try to come up with a solution which *doesn't* involve teaching kexec > a whole load of internals about how the ARM kernel booting happens. > > What's more worrying to me at the moment, though, is that the kexec code > only tries to find memory for the actual "kernel" size, not the actual > space required to decompress the kernel. It could find a chunk of > memory large enough to fit the kernel image to be loaded, but is not big > enough to allow its decompression. kexec is really quite a mess on > ARM. :( How about we check the size of RAM available, and if there is plenty of RAM we use a safe compression ratio of 8. If RAM is a problem, we could make the compression ratio smaller and warn about it. And we could also allow passing the compression ratio to kexec as an option. I forgot if we still have some 128MB limits too.. Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-22 7:36 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-22 7:36 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 14:54]: > So that's 20.7MB, and the zImage was 3.6MB. You're getting an > expansion ratio of 5.7x. > > To fix that, we'd need to up it to 7x, but the problem with upping > it in this way is that it increases the requirements for the > crashdump region too. We can play with this number, but there will > always be cases where it doesn't work - either because the ratio is > too big or too small. OK > By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" > doesn't even work for this case, since you need about 25MB. Your > calculation comes out at 22MB, which is 3MB short. Not only that, but > it introduces (from what I can see) an irrelevant fudge factor of > "MAX_RODATA_SZ" which has no basis in what's really going on here, and > I'm left wondering what "MAX_RODATA_SZ" is actually referring to. Well I thinking the section alignment split might give us some known size for rodata, but looking at it more it's only with DEBUG_ALIGN_RODATA. If we can't make any assumptions about the size of the rodata, then no point adding it. > So... I'm of the opinion that we shouldn't play with it - but instead > try to come up with a solution which *doesn't* involve teaching kexec > a whole load of internals about how the ARM kernel booting happens. > > What's more worrying to me at the moment, though, is that the kexec code > only tries to find memory for the actual "kernel" size, not the actual > space required to decompress the kernel. It could find a chunk of > memory large enough to fit the kernel image to be loaded, but is not big > enough to allow its decompression. kexec is really quite a mess on > ARM. :( How about we check the size of RAM available, and if there is plenty of RAM we use a safe compression ratio of 8. If RAM is a problem, we could make the compression ratio smaller and warn about it. And we could also allow passing the compression ratio to kexec as an option. I forgot if we still have some 128MB limits too.. Regards, Tony _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-22 7:36 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-22 7:36 UTC (permalink / raw) To: linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 14:54]: > So that's 20.7MB, and the zImage was 3.6MB. You're getting an > expansion ratio of 5.7x. > > To fix that, we'd need to up it to 7x, but the problem with upping > it in this way is that it increases the requirements for the > crashdump region too. We can play with this number, but there will > always be cases where it doesn't work - either because the ratio is > too big or too small. OK > By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" > doesn't even work for this case, since you need about 25MB. Your > calculation comes out at 22MB, which is 3MB short. Not only that, but > it introduces (from what I can see) an irrelevant fudge factor of > "MAX_RODATA_SZ" which has no basis in what's really going on here, and > I'm left wondering what "MAX_RODATA_SZ" is actually referring to. Well I thinking the section alignment split might give us some known size for rodata, but looking at it more it's only with DEBUG_ALIGN_RODATA. If we can't make any assumptions about the size of the rodata, then no point adding it. > So... I'm of the opinion that we shouldn't play with it - but instead > try to come up with a solution which *doesn't* involve teaching kexec > a whole load of internals about how the ARM kernel booting happens. > > What's more worrying to me at the moment, though, is that the kexec code > only tries to find memory for the actual "kernel" size, not the actual > space required to decompress the kernel. It could find a chunk of > memory large enough to fit the kernel image to be loaded, but is not big > enough to allow its decompression. kexec is really quite a mess on > ARM. :( How about we check the size of RAM available, and if there is plenty of RAM we use a safe compression ratio of 8. If RAM is a problem, we could make the compression ratio smaller and warn about it. And we could also allow passing the compression ratio to kexec as an option. I forgot if we still have some 128MB limits too.. Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160622073614.GZ22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-22 7:36 ` Tony Lindgren (?) @ 2016-06-22 8:29 ` Russell King - ARM Linux -1 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-22 8:29 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r On Wed, Jun 22, 2016 at 12:36:16AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160621 14:54]: > > So that's 20.7MB, and the zImage was 3.6MB. You're getting an > > expansion ratio of 5.7x. > > > > To fix that, we'd need to up it to 7x, but the problem with upping > > it in this way is that it increases the requirements for the > > crashdump region too. We can play with this number, but there will > > always be cases where it doesn't work - either because the ratio is > > too big or too small. > > OK > > > By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" > > doesn't even work for this case, since you need about 25MB. Your > > calculation comes out at 22MB, which is 3MB short. Not only that, but > > it introduces (from what I can see) an irrelevant fudge factor of > > "MAX_RODATA_SZ" which has no basis in what's really going on here, and > > I'm left wondering what "MAX_RODATA_SZ" is actually referring to. > > Well I thinking the section alignment split might give us some > known size for rodata, but looking at it more it's only with > DEBUG_ALIGN_RODATA. If we can't make any assumptions about the > size of the rodata, then no point adding it. I think you're just getting completely confused about what the problem is, due to the naming of the config option. It's got nothing to do with the size of the read-only data. Really. When CONFIG_DEBUG_RODATA is enabled, we align the text, read-only data, data, and so on to 1MB boundaries so that we can change the permissions of the sections to enforce the properties of the various ELF segments. This padding massively inflates the size of the run-time kernel image, and can result in megabytes of wastage (if we're as little as one byte into 1MB, we have to round up to the next megabyte.) The padding, being a string of zeros, is very compressable, and this increases the compression ratio. The BSS is not included in the compressed image, but needs to be taken account of when avoiding overwriting the DTB. > How about we check the size of RAM available, and if there is plenty > of RAM we use a safe compression ratio of 8. If RAM is a problem, > we could make the compression ratio smaller and warn about it. And > we could also allow passing the compression ratio to kexec as an > option. You do know that you can already pass the "size" of the kernel to be reserved to kexec. --image-size. It's not documented in --help, but it is there (which is another annoying thing about ARM kexec...) > I forgot if we still have some 128MB limits too.. We do. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-22 8:29 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-22 8:29 UTC (permalink / raw) To: Tony Lindgren Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel On Wed, Jun 22, 2016 at 12:36:16AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 14:54]: > > So that's 20.7MB, and the zImage was 3.6MB. You're getting an > > expansion ratio of 5.7x. > > > > To fix that, we'd need to up it to 7x, but the problem with upping > > it in this way is that it increases the requirements for the > > crashdump region too. We can play with this number, but there will > > always be cases where it doesn't work - either because the ratio is > > too big or too small. > > OK > > > By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" > > doesn't even work for this case, since you need about 25MB. Your > > calculation comes out at 22MB, which is 3MB short. Not only that, but > > it introduces (from what I can see) an irrelevant fudge factor of > > "MAX_RODATA_SZ" which has no basis in what's really going on here, and > > I'm left wondering what "MAX_RODATA_SZ" is actually referring to. > > Well I thinking the section alignment split might give us some > known size for rodata, but looking at it more it's only with > DEBUG_ALIGN_RODATA. If we can't make any assumptions about the > size of the rodata, then no point adding it. I think you're just getting completely confused about what the problem is, due to the naming of the config option. It's got nothing to do with the size of the read-only data. Really. When CONFIG_DEBUG_RODATA is enabled, we align the text, read-only data, data, and so on to 1MB boundaries so that we can change the permissions of the sections to enforce the properties of the various ELF segments. This padding massively inflates the size of the run-time kernel image, and can result in megabytes of wastage (if we're as little as one byte into 1MB, we have to round up to the next megabyte.) The padding, being a string of zeros, is very compressable, and this increases the compression ratio. The BSS is not included in the compressed image, but needs to be taken account of when avoiding overwriting the DTB. > How about we check the size of RAM available, and if there is plenty > of RAM we use a safe compression ratio of 8. If RAM is a problem, > we could make the compression ratio smaller and warn about it. And > we could also allow passing the compression ratio to kexec as an > option. You do know that you can already pass the "size" of the kernel to be reserved to kexec. --image-size. It's not documented in --help, but it is there (which is another annoying thing about ARM kexec...) > I forgot if we still have some 128MB limits too.. We do. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-22 8:29 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-22 8:29 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 22, 2016 at 12:36:16AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@armlinux.org.uk> [160621 14:54]: > > So that's 20.7MB, and the zImage was 3.6MB. You're getting an > > expansion ratio of 5.7x. > > > > To fix that, we'd need to up it to 7x, but the problem with upping > > it in this way is that it increases the requirements for the > > crashdump region too. We can play with this number, but there will > > always be cases where it doesn't work - either because the ratio is > > too big or too small. > > OK > > > By way of illustration, "zImage size + MAX_RODATA_SZ + 4x zImage size" > > doesn't even work for this case, since you need about 25MB. Your > > calculation comes out at 22MB, which is 3MB short. Not only that, but > > it introduces (from what I can see) an irrelevant fudge factor of > > "MAX_RODATA_SZ" which has no basis in what's really going on here, and > > I'm left wondering what "MAX_RODATA_SZ" is actually referring to. > > Well I thinking the section alignment split might give us some > known size for rodata, but looking at it more it's only with > DEBUG_ALIGN_RODATA. If we can't make any assumptions about the > size of the rodata, then no point adding it. I think you're just getting completely confused about what the problem is, due to the naming of the config option. It's got nothing to do with the size of the read-only data. Really. When CONFIG_DEBUG_RODATA is enabled, we align the text, read-only data, data, and so on to 1MB boundaries so that we can change the permissions of the sections to enforce the properties of the various ELF segments. This padding massively inflates the size of the run-time kernel image, and can result in megabytes of wastage (if we're as little as one byte into 1MB, we have to round up to the next megabyte.) The padding, being a string of zeros, is very compressable, and this increases the compression ratio. The BSS is not included in the compressed image, but needs to be taken account of when avoiding overwriting the DTB. > How about we check the size of RAM available, and if there is plenty > of RAM we use a safe compression ratio of 8. If RAM is a problem, > we could make the compression ratio smaller and warn about it. And > we could also allow passing the compression ratio to kexec as an > option. You do know that you can already pass the "size" of the kernel to be reserved to kexec. --image-size. It's not documented in --help, but it is there (which is another annoying thing about ARM kexec...) > I forgot if we still have some 128MB limits too.. We do. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
[parent not found: <20160622082958.GD5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: [PATCH 2/2] arm: fix kernel image size 2016-06-22 8:29 ` Russell King - ARM Linux (?) @ 2016-06-22 8:51 ` Tony Lindgren -1 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-22 8:51 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Horman, Kees Cook, linux-omap-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r * Russell King - ARM Linux <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> [160622 01:32]: > When CONFIG_DEBUG_RODATA is enabled, we align the text, read-only data, > data, and so on to 1MB boundaries so that we can change the permissions > of the sections to enforce the properties of the various ELF segments. > This padding massively inflates the size of the run-time kernel image, > and can result in megabytes of wastage (if we're as little as one byte > into 1MB, we have to round up to the next megabyte.) Yes understood, and looks like we cannot make any assumptions about what the alignment might be. > The padding, being a string of zeros, is very compressable, and this > increases the compression ratio. > > The BSS is not included in the compressed image, but needs to be taken > account of when avoiding overwriting the DTB. > > > How about we check the size of RAM available, and if there is plenty > > of RAM we use a safe compression ratio of 8. If RAM is a problem, > > we could make the compression ratio smaller and warn about it. And > > we could also allow passing the compression ratio to kexec as an > > option. > > You do know that you can already pass the "size" of the kernel to be > reserved to kexec. --image-size. It's not documented in --help, but > it is there (which is another annoying thing about ARM kexec...) Oh ok that's nice. Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 2/2] arm: fix kernel image size @ 2016-06-22 8:51 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-22 8:51 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, Baoquan He, kexec, Simon Horman, Kees Cook, linux-omap, linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160622 01:32]: > When CONFIG_DEBUG_RODATA is enabled, we align the text, read-only data, > data, and so on to 1MB boundaries so that we can change the permissions > of the sections to enforce the properties of the various ELF segments. > This padding massively inflates the size of the run-time kernel image, > and can result in megabytes of wastage (if we're as little as one byte > into 1MB, we have to round up to the next megabyte.) Yes understood, and looks like we cannot make any assumptions about what the alignment might be. > The padding, being a string of zeros, is very compressable, and this > increases the compression ratio. > > The BSS is not included in the compressed image, but needs to be taken > account of when avoiding overwriting the DTB. > > > How about we check the size of RAM available, and if there is plenty > > of RAM we use a safe compression ratio of 8. If RAM is a problem, > > we could make the compression ratio smaller and warn about it. And > > we could also allow passing the compression ratio to kexec as an > > option. > > You do know that you can already pass the "size" of the kernel to be > reserved to kexec. --image-size. It's not documented in --help, but > it is there (which is another annoying thing about ARM kexec...) Oh ok that's nice. Regards, Tony _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size @ 2016-06-22 8:51 ` Tony Lindgren 0 siblings, 0 replies; 43+ messages in thread From: Tony Lindgren @ 2016-06-22 8:51 UTC (permalink / raw) To: linux-arm-kernel * Russell King - ARM Linux <linux@armlinux.org.uk> [160622 01:32]: > When CONFIG_DEBUG_RODATA is enabled, we align the text, read-only data, > data, and so on to 1MB boundaries so that we can change the permissions > of the sections to enforce the properties of the various ELF segments. > This padding massively inflates the size of the run-time kernel image, > and can result in megabytes of wastage (if we're as little as one byte > into 1MB, we have to round up to the next megabyte.) Yes understood, and looks like we cannot make any assumptions about what the alignment might be. > The padding, being a string of zeros, is very compressable, and this > increases the compression ratio. > > The BSS is not included in the compressed image, but needs to be taken > account of when avoiding overwriting the DTB. > > > How about we check the size of RAM available, and if there is plenty > > of RAM we use a safe compression ratio of 8. If RAM is a problem, > > we could make the compression ratio smaller and warn about it. And > > we could also allow passing the compression ratio to kexec as an > > option. > > You do know that you can already pass the "size" of the kernel to be > reserved to kexec. --image-size. It's not documented in --help, but > it is there (which is another annoying thing about ARM kexec...) Oh ok that's nice. Regards, Tony ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 2/2] arm: fix kernel image size 2016-06-17 19:44 ` Russell King (?) (?) @ 2016-06-21 11:02 ` Mason -1 siblings, 0 replies; 43+ messages in thread From: Mason @ 2016-06-21 11:02 UTC (permalink / raw) To: linux-arm-kernel On 17/06/2016 21:44, Russell King wrote: > If we want to assume that the compressed image will expand by a maximum > of 4x, we actually need to reserve 5x the space, since we need to keep > a copy of the compessed image around while decompressing. ^^^^^^^^^ compressed ;-) ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 0/2] Simple fix to the ARM kexec tools implementation 2016-06-17 19:44 ` Russell King - ARM Linux @ 2016-06-21 6:11 ` Pratyush Anand -1 siblings, 0 replies; 43+ messages in thread From: Pratyush Anand @ 2016-06-21 6:11 UTC (permalink / raw) To: linux-arm-kernel On 17/06/2016:08:44:05 PM, Russell King - ARM Linux wrote: > This is the "simple" fix for the ARM kexec tools code, which makes > the code actually do what the comments describe. > > There are two problems: > > 1. When placing the initrd, we do not take account of the 32k offset > that is required for the kernel image. > > 2. The code claims to allow the zImage decompressor to expand by a > factor of 4, but only allows space for a factor of 3, since the > decompressor itself has to fit in this memory space as well. > > Changing the code to follow the comments allows Keystone II to kexec > with DEBUG_RODATA enabled, at least with the kernel I've been testing > with. > > This is a stop-gap solution until a better solution can be implemented. Yes, so until we have proper header for zImage, these patches looks fine to me. For both of the patches: Reviewed-by: Pratyush Anand <panand@redhat.com> > > kexec/arch/arm/kexec-zImage-arm.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 0/2] Simple fix to the ARM kexec tools implementation @ 2016-06-21 6:11 ` Pratyush Anand 0 siblings, 0 replies; 43+ messages in thread From: Pratyush Anand @ 2016-06-21 6:11 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Simon Horman, kexec, linux-arm-kernel, Baoquan He, Kees Cook On 17/06/2016:08:44:05 PM, Russell King - ARM Linux wrote: > This is the "simple" fix for the ARM kexec tools code, which makes > the code actually do what the comments describe. > > There are two problems: > > 1. When placing the initrd, we do not take account of the 32k offset > that is required for the kernel image. > > 2. The code claims to allow the zImage decompressor to expand by a > factor of 4, but only allows space for a factor of 3, since the > decompressor itself has to fit in this memory space as well. > > Changing the code to follow the comments allows Keystone II to kexec > with DEBUG_RODATA enabled, at least with the kernel I've been testing > with. > > This is a stop-gap solution until a better solution can be implemented. Yes, so until we have proper header for zImage, these patches looks fine to me. For both of the patches: Reviewed-by: Pratyush Anand <panand@redhat.com> > > kexec/arch/arm/kexec-zImage-arm.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 0/2] Simple fix to the ARM kexec tools implementation 2016-06-21 6:11 ` Pratyush Anand @ 2016-06-21 8:20 ` Russell King - ARM Linux -1 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 8:20 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 21, 2016 at 11:41:28AM +0530, Pratyush Anand wrote: > Yes, so until we have proper header for zImage, these patches looks > fine to me. If you read my last email in the "kexec failures with DEBUG_RODATA" thread, you'll see that I'm unhappy with this idea, because adding a "proper header" still results in some kind of assumption about how the zImage decompressor works being needed by the boot environment. > For both of the patches: > > Reviewed-by: Pratyush Anand <panand@redhat.com> Thanks. Simon, do you need me to resend with the r-b tag, or will you pick these two up and the documentation fix patch you asked for? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 0/2] Simple fix to the ARM kexec tools implementation @ 2016-06-21 8:20 ` Russell King - ARM Linux 0 siblings, 0 replies; 43+ messages in thread From: Russell King - ARM Linux @ 2016-06-21 8:20 UTC (permalink / raw) To: Pratyush Anand, Simon Horman Cc: kexec, Baoquan He, linux-arm-kernel, Kees Cook On Tue, Jun 21, 2016 at 11:41:28AM +0530, Pratyush Anand wrote: > Yes, so until we have proper header for zImage, these patches looks > fine to me. If you read my last email in the "kexec failures with DEBUG_RODATA" thread, you'll see that I'm unhappy with this idea, because adding a "proper header" still results in some kind of assumption about how the zImage decompressor works being needed by the boot environment. > For both of the patches: > > Reviewed-by: Pratyush Anand <panand@redhat.com> Thanks. Simon, do you need me to resend with the r-b tag, or will you pick these two up and the documentation fix patch you asked for? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH 0/2] Simple fix to the ARM kexec tools implementation 2016-06-21 8:20 ` Russell King - ARM Linux @ 2016-06-23 0:41 ` Simon Horman -1 siblings, 0 replies; 43+ messages in thread From: Simon Horman @ 2016-06-23 0:41 UTC (permalink / raw) To: linux-arm-kernel On Tue, Jun 21, 2016 at 09:20:33AM +0100, Russell King - ARM Linux wrote: > On Tue, Jun 21, 2016 at 11:41:28AM +0530, Pratyush Anand wrote: > > Yes, so until we have proper header for zImage, these patches looks > > fine to me. > > If you read my last email in the "kexec failures with DEBUG_RODATA" > thread, you'll see that I'm unhappy with this idea, because adding a > "proper header" still results in some kind of assumption about how > the zImage decompressor works being needed by the boot environment. > > > For both of the patches: > > > > Reviewed-by: Pratyush Anand <panand@redhat.com> > > Thanks. > > Simon, do you need me to resend with the r-b tag, or will you pick > these two up and the documentation fix patch you asked for? Thanks for reminding me about this, I have applied this patch and the other one you mention. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH 0/2] Simple fix to the ARM kexec tools implementation @ 2016-06-23 0:41 ` Simon Horman 0 siblings, 0 replies; 43+ messages in thread From: Simon Horman @ 2016-06-23 0:41 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Pratyush Anand, kexec, Baoquan He, linux-arm-kernel, Kees Cook On Tue, Jun 21, 2016 at 09:20:33AM +0100, Russell King - ARM Linux wrote: > On Tue, Jun 21, 2016 at 11:41:28AM +0530, Pratyush Anand wrote: > > Yes, so until we have proper header for zImage, these patches looks > > fine to me. > > If you read my last email in the "kexec failures with DEBUG_RODATA" > thread, you'll see that I'm unhappy with this idea, because adding a > "proper header" still results in some kind of assumption about how > the zImage decompressor works being needed by the boot environment. > > > For both of the patches: > > > > Reviewed-by: Pratyush Anand <panand@redhat.com> > > Thanks. > > Simon, do you need me to resend with the r-b tag, or will you pick > these two up and the documentation fix patch you asked for? Thanks for reminding me about this, I have applied this patch and the other one you mention. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2016-06-23 0:41 UTC | newest] Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-17 19:44 [PATCH 0/2] Simple fix to the ARM kexec tools implementation Russell King - ARM Linux 2016-06-17 19:44 ` Russell King - ARM Linux 2016-06-17 19:44 ` [PATCH 1/2] arm: take account of TEXT_OFFSET for subsequent images Russell King 2016-06-17 19:44 ` Russell King 2016-06-17 19:44 ` [PATCH 2/2] arm: fix kernel image size Russell King 2016-06-17 19:44 ` Russell King [not found] ` <E1bDzh4-0006a4-7p-yeZebKftTXNiEPTqdM/vLBqCBvEC6TWiNEsB0oqw8pBaa/9Udqfwiw@public.gmane.org> 2016-06-21 7:43 ` Tony Lindgren 2016-06-21 7:43 ` Tony Lindgren 2016-06-21 7:43 ` Tony Lindgren [not found] ` <20160621074319.GH22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> 2016-06-21 9:47 ` Russell King - ARM Linux 2016-06-21 9:47 ` Russell King - ARM Linux 2016-06-21 9:47 ` Russell King - ARM Linux [not found] ` <20160621094737.GA5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2016-06-21 10:38 ` Tony Lindgren 2016-06-21 10:38 ` Tony Lindgren 2016-06-21 10:38 ` Tony Lindgren [not found] ` <20160621103810.GI22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> 2016-06-21 10:57 ` Tony Lindgren 2016-06-21 10:57 ` Tony Lindgren 2016-06-21 10:57 ` Tony Lindgren [not found] ` <20160621105720.GK22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> 2016-06-21 15:44 ` Russell King - ARM Linux 2016-06-21 15:44 ` Russell King - ARM Linux 2016-06-21 15:44 ` Russell King - ARM Linux [not found] ` <20160621154407.GB5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2016-06-21 16:55 ` Tony Lindgren 2016-06-21 16:55 ` Tony Lindgren 2016-06-21 16:55 ` Tony Lindgren [not found] ` <20160621165523.GY22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> 2016-06-21 21:51 ` Russell King - ARM Linux 2016-06-21 21:51 ` Russell King - ARM Linux 2016-06-21 21:51 ` Russell King - ARM Linux [not found] ` <20160621215141.GC5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2016-06-22 7:36 ` Tony Lindgren 2016-06-22 7:36 ` Tony Lindgren 2016-06-22 7:36 ` Tony Lindgren [not found] ` <20160622073614.GZ22406-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> 2016-06-22 8:29 ` Russell King - ARM Linux 2016-06-22 8:29 ` Russell King - ARM Linux 2016-06-22 8:29 ` Russell King - ARM Linux [not found] ` <20160622082958.GD5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2016-06-22 8:51 ` Tony Lindgren 2016-06-22 8:51 ` Tony Lindgren 2016-06-22 8:51 ` Tony Lindgren 2016-06-21 11:02 ` Mason 2016-06-21 6:11 ` [PATCH 0/2] Simple fix to the ARM kexec tools implementation Pratyush Anand 2016-06-21 6:11 ` Pratyush Anand 2016-06-21 8:20 ` Russell King - ARM Linux 2016-06-21 8:20 ` Russell King - ARM Linux 2016-06-23 0:41 ` Simon Horman 2016-06-23 0:41 ` Simon Horman
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.