Add free_initrd= option to control freeing of initrd memory after
extraction. By default, free memory as previously.
Signed-off-by: Michael Neuling <[email protected]>
---
Useful for kexec when you want to reuse the same initrd. Testing on
POWERPC with CPIOs
init/initramfs.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/init/initramfs.c
===================================================================
--- linux-2.6-ozlabs.orig/init/initramfs.c
+++ linux-2.6-ozlabs/init/initramfs.c
@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
return message;
}
+static int do_free_initrd = 1;
+
+int __init free_initrd_param(char *p)
+{
+ if (p && strncmp(p, "0", 1) == 0)
+ do_free_initrd = 0;
+
+ return 0;
+}
+early_param("free_initrd", free_initrd_param);
+
extern char __initramfs_start[], __initramfs_end[];
#ifdef CONFIG_BLK_DEV_INITRD
#include <linux/initrd.h>
@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
static void __init free_initrd(void)
{
-#ifdef CONFIG_KEXEC
unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
+ if (!do_free_initrd)
+ goto skip;
+
+#ifdef CONFIG_KEXEC
/*
* If the initrd region is overlapped with crashkernel reserved region,
* free only memory that is not part of crashkernel region.
@@ -515,7 +529,7 @@ static void __init free_initrd(void)
} else
#endif
free_initrd_mem(initrd_start, initrd_end);
-
+skip:
initrd_start = 0;
initrd_end = 0;
}
On Thu, 07 Dec 2006 11:18:43 +1100 Michael Neuling wrote:
> Add free_initrd= option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
Please add doc. for this in Documentation/kernel-parameters.txt.
> Signed-off-by: Michael Neuling <[email protected]>
> ---
> Useful for kexec when you want to reuse the same initrd. Testing on
> POWERPC with CPIOs
>
> init/initramfs.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> Index: linux-2.6-ozlabs/init/initramfs.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
> return message;
> }
>
> +static int do_free_initrd = 1;
> +
> +int __init free_initrd_param(char *p)
> +{
> + if (p && strncmp(p, "0", 1) == 0)
> + do_free_initrd = 0;
> +
> + return 0;
> +}
> +early_param("free_initrd", free_initrd_param);
> +
> extern char __initramfs_start[], __initramfs_end[];
> #ifdef CONFIG_BLK_DEV_INITRD
> #include <linux/initrd.h>
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>
> static void __init free_initrd(void)
> {
> -#ifdef CONFIG_KEXEC
> unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
>
> + if (!do_free_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
> /*
> * If the initrd region is overlapped with crashkernel reserved region,
> * free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
> } else
> #endif
> free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
> initrd_start = 0;
> initrd_end = 0;
> }
> -
---
~Randy
On Thu, 07 Dec 2006 11:18:43 +1100
Michael Neuling <[email protected]> wrote:
> Add free_initrd= option to control freeing of initrd memory after
> extraction. By default, free memory as previously.
>
> Signed-off-by: Michael Neuling <[email protected]>
> ---
> Useful for kexec when you want to reuse the same initrd. Testing on
> POWERPC with CPIOs
>
> --- linux-2.6-ozlabs.orig/init/initramfs.c
> +++ linux-2.6-ozlabs/init/initramfs.c
> @@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
> return message;
> }
>
> +static int do_free_initrd = 1;
> +
> +int __init free_initrd_param(char *p)
> +{
> + if (p && strncmp(p, "0", 1) == 0)
> + do_free_initrd = 0;
> +
> + return 0;
> +}
> +early_param("free_initrd", free_initrd_param);
> +
> extern char __initramfs_start[], __initramfs_end[];
> #ifdef CONFIG_BLK_DEV_INITRD
> #include <linux/initrd.h>
> @@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>
> static void __init free_initrd(void)
> {
> -#ifdef CONFIG_KEXEC
> unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
>
> + if (!do_free_initrd)
> + goto skip;
> +
> +#ifdef CONFIG_KEXEC
> /*
> * If the initrd region is overlapped with crashkernel reserved region,
> * free only memory that is not part of crashkernel region.
> @@ -515,7 +529,7 @@ static void __init free_initrd(void)
> } else
> #endif
> free_initrd_mem(initrd_start, initrd_end);
> -
> +skip:
> initrd_start = 0;
> initrd_end = 0;
> }
I'd have thought that an option `retain_initrd' would make more sense.
Please always update Documentation/kernel-parameters.txt when adding boot
options.
Andrew Morton wrote:
>
> I'd have thought that an option `retain_initrd' would make more sense.
>
> Please always update Documentation/kernel-parameters.txt when adding boot
> options.
>
I would have to agree with this; it also seems a bit odd to me to have
this at all (kexec provides a new kernel image, surely it also provides
a new initrd image???)
-hpa
> I would have to agree with this; it also seems a bit odd to me to have
> this at all (kexec provides a new kernel image, surely it also
> provides a new initrd image???)
The first boot will need to hold a copy of the in memory fs for the
second boot. This image can be large (much larger than the kernel),
hence we can save time when the memory loader is slow. Also, it reduces
the memory footprint while extracting the first boot since you don't
need another copy of the fs.
New patch on it's way.
Mikey
Michael Neuling wrote:
>Add free_initrd= option to control freeing of initrd memory after
>extraction. By default, free memory as previously.
>
>Signed-off-by: Michael Neuling <[email protected]>
>---
>Useful for kexec when you want to reuse the same initrd. Testing on
>POWERPC with CPIOs
>
>
This option (free_initrd) will not work if the user loads the kdump
kernel and does the normal kexec boot later on powerpc. The reason is
initrd will be loaded by yaboot at 36MB and kdump image at 32M (Right
now it is fixed). It could be possible that we will end up overwriting
initrd.
> init/initramfs.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
>Index: linux-2.6-ozlabs/init/initramfs.c
>===================================================================
>--- linux-2.6-ozlabs.orig/init/initramfs.c
>+++ linux-2.6-ozlabs/init/initramfs.c
>@@ -487,6 +487,17 @@ static char * __init unpack_to_rootfs(ch
> return message;
> }
>
>+static int do_free_initrd = 1;
>+
>+int __init free_initrd_param(char *p)
>+{
>+ if (p && strncmp(p, "0", 1) == 0)
>+ do_free_initrd = 0;
>+
>+ return 0;
>+}
>+early_param("free_initrd", free_initrd_param);
>+
> extern char __initramfs_start[], __initramfs_end[];
> #ifdef CONFIG_BLK_DEV_INITRD
> #include <linux/initrd.h>
>@@ -494,10 +505,13 @@ extern char __initramfs_start[], __initr
>
> static void __init free_initrd(void)
> {
>-#ifdef CONFIG_KEXEC
> unsigned long crashk_start = (unsigned long)__va(crashk_res.start);
> unsigned long crashk_end = (unsigned long)__va(crashk_res.end);
>
>+ if (!do_free_initrd)
>+ goto skip;
>+
>+#ifdef CONFIG_KEXEC
> /*
> * If the initrd region is overlapped with crashkernel reserved region,
> * free only memory that is not part of crashkernel region.
>@@ -515,7 +529,7 @@ static void __init free_initrd(void)
> } else
> #endif
> free_initrd_mem(initrd_start, initrd_end);
>-
>+skip:
> initrd_start = 0;
> initrd_end = 0;
> }
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
Vivek Goyal wrote:
>On Thu, Dec 07, 2006 at 02:36:18PM +1100, Michael Neuling wrote:
>
>
>>>I would have to agree with this; it also seems a bit odd to me to have
>>>this at all (kexec provides a new kernel image, surely it also
>>>provides a new initrd image???)
>>>
>>>
>
>Yes, kexec provides the option --initrd, so that a user can supply an
>initrd image to be loaded along with kernel.
>
>
>
>>The first boot will need to hold a copy of the in memory fs for the
>>second boot. This image can be large (much larger than the kernel),
>>hence we can save time when the memory loader is slow. Also, it reduces
>>the memory footprint while extracting the first boot since you don't
>>need another copy of the fs.
>>
>>
>>
>
>Is there a kexec-tools patch too? How does second kernel know about
>the location of the first kernel's initrd to be reused?
>
>
kexec-tools has to be modified to pass the first kernel initrd. On
powerpc, initrd locations are exported using device-tree. At present,
kexec-tool ignores the first kernel initrd property values and creates
new initrd properties if the user passes '--initrd' option to the kexec
command. So, will be an issue unless first kernel device-tree is passed
as buffer.
>In general kexec can overwrite all the previous kernel's memory. It
>just knows about the segments the user has passed to it and it will
>place these segments to their destination locations. There are no
>gurantees that in this process some data from first kernel will not
>be overwritten. So it might not be a very safe scheme.
>
>
Initrd memory can be excluded like other segments such as RTAS and TCE
on powerpc. However it is not implemented yet even on powerpc and is an
issue on other archs.
Thanks
Haren
>Thanks
>Vivek
>_______________________________________________
>fastboot mailing list
>[email protected]
>https://lists.osdl.org/mailman/listinfo/fastboot
>
>
On Thu, Dec 07, 2006 at 02:36:18PM +1100, Michael Neuling wrote:
> > I would have to agree with this; it also seems a bit odd to me to have
> > this at all (kexec provides a new kernel image, surely it also
> > provides a new initrd image???)
>
Yes, kexec provides the option --initrd, so that a user can supply an
initrd image to be loaded along with kernel.
> The first boot will need to hold a copy of the in memory fs for the
> second boot. This image can be large (much larger than the kernel),
> hence we can save time when the memory loader is slow. Also, it reduces
> the memory footprint while extracting the first boot since you don't
> need another copy of the fs.
>
Is there a kexec-tools patch too? How does second kernel know about
the location of the first kernel's initrd to be reused?
In general kexec can overwrite all the previous kernel's memory. It
just knows about the segments the user has passed to it and it will
place these segments to their destination locations. There are no
gurantees that in this process some data from first kernel will not
be overwritten. So it might not be a very safe scheme.
Thanks
Vivek
> >Is there a kexec-tools patch too? How does second kernel know about
> >the location of the first kernel's initrd to be reused?
> >
> >
> kexec-tools has to be modified to pass the first kernel initrd. On
> powerpc, initrd locations are exported using device-tree. At present,
> kexec-tool ignores the first kernel initrd property values and creates
> new initrd properties if the user passes '--initrd' option to the kexec
> command. So, will be an issue unless first kernel device-tree is passed
> as buffer.
We've been using the --devicetreeblob kexec-tools option available for
POWERPC. This enables you to setup the device tree (and hence, the
initrd points) as you like.
I'm happy to put together a patch for kexec-tools. Unfortunately this
is arch specific. A quick look through the x86, ia64, s390 and ppc64
code shows the --initrd option for all these just reads the specified
initrd file, pushes it out to memory and uses the base and size pointers
to setup the next boot. We'd obviously just skip to the last stage.
So what's the kexec-tools option called? --initrd-location <base> <size>?
(BTW I'm offline soon, so I probably won't get to this for a few weeks)
> Initrd memory can be excluded like other segments such as RTAS and TCE
> on powerpc. However it is not implemented yet even on powerpc and is
> an issue on other archs.
The above should allow us to do these checks in kexec-tools.
Mikey
On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > >Is there a kexec-tools patch too? How does second kernel know about
> > >the location of the first kernel's initrd to be reused?
> > >
> > >
> > kexec-tools has to be modified to pass the first kernel initrd. On
> > powerpc, initrd locations are exported using device-tree. At present,
> > kexec-tool ignores the first kernel initrd property values and creates
> > new initrd properties if the user passes '--initrd' option to the kexec
> > command. So, will be an issue unless first kernel device-tree is passed
> > as buffer.
>
> We've been using the --devicetreeblob kexec-tools option available for
> POWERPC. This enables you to setup the device tree (and hence, the
> initrd points) as you like.
>
> I'm happy to put together a patch for kexec-tools.
Please do. And please cc me on a copy that applies against kexec-tools-testing.
> Unfortunately this
> is arch specific. A quick look through the x86, ia64, s390 and ppc64
> code shows the --initrd option for all these just reads the specified
> initrd file, pushes it out to memory and uses the base and size pointers
> to setup the next boot. We'd obviously just skip to the last stage.
>
> So what's the kexec-tools option called? --initrd-location <base> <size>?
That sounds fine to me. I think its ok to make it arch specific for
starters and then move it out to generic code later. That said, if
you're feeling particularly entergetic, feel free to do the generic
stuff now and just add null stubs for the other architectures (does
that makes sense?).
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote:
> On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > > >Is there a kexec-tools patch too? How does second kernel know about
> > > >the location of the first kernel's initrd to be reused?
> > > >
> > > >
> > > kexec-tools has to be modified to pass the first kernel initrd. On
> > > powerpc, initrd locations are exported using device-tree. At present,
> > > kexec-tool ignores the first kernel initrd property values and creates
> > > new initrd properties if the user passes '--initrd' option to the kexec
> > > command. So, will be an issue unless first kernel device-tree is passed
> > > as buffer.
> >
> > We've been using the --devicetreeblob kexec-tools option available for
> > POWERPC. This enables you to setup the device tree (and hence, the
> > initrd points) as you like.
> >
> > I'm happy to put together a patch for kexec-tools.
>
> Please do. And please cc me on a copy that applies against kexec-tools-testing.
>
> > Unfortunately this
> > is arch specific. A quick look through the x86, ia64, s390 and ppc64
> > code shows the --initrd option for all these just reads the specified
> > initrd file, pushes it out to memory and uses the base and size pointers
> > to setup the next boot. We'd obviously just skip to the last stage.
> >
> > So what's the kexec-tools option called? --initrd-location <base> <size>?
>
> That sounds fine to me. I think its ok to make it arch specific for
> starters and then move it out to generic code later. That said, if
> you're feeling particularly entergetic, feel free to do the generic
> stuff now and just add null stubs for the other architectures (does
> that makes sense?).
Did anything ever come of this?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
In message <[email protected]> you wrote:
> On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote:
> > On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > > > >Is there a kexec-tools patch too? How does second kernel know about
> > > > >the location of the first kernel's initrd to be reused?
> > > > >
> > > > >
> > > > kexec-tools has to be modified to pass the first kernel initrd. On
> > > > powerpc, initrd locations are exported using device-tree. At present,
> > > > kexec-tool ignores the first kernel initrd property values and creates
> > > > new initrd properties if the user passes '--initrd' option to the kexec
> > > > command. So, will be an issue unless first kernel device-tree is passed
> > > > as buffer.
> > >
> > > We've been using the --devicetreeblob kexec-tools option available for
> > > POWERPC. This enables you to setup the device tree (and hence, the
> > > initrd points) as you like.
> > >
> > > I'm happy to put together a patch for kexec-tools.
> >
> > Please do. And please cc me on a copy that applies against kexec-tools-test
ing.
> >
> > > Unfortunately this
> > > is arch specific. A quick look through the x86, ia64, s390 and ppc64
> > > code shows the --initrd option for all these just reads the specified
> > > initrd file, pushes it out to memory and uses the base and size pointers
> > > to setup the next boot. We'd obviously just skip to the last stage.
> > >
> > > So what's the kexec-tools option called? --initrd-location <base> <size>
?
> >
> > That sounds fine to me. I think its ok to make it arch specific for
> > starters and then move it out to generic code later. That said, if
> > you're feeling particularly entergetic, feel free to do the generic
> > stuff now and just add null stubs for the other architectures (does
> > that makes sense?).
>
> Did anything ever come of this?
Not yet, but it's on my todo list.
Mikey