initramfs: handle trailing junk after valid image

Commit Message

Ben Peddell Aug. 6, 2012, 9:32 a.m. UTC

The initramfs handling since commit df37bd15 has been rejecting
valid images that have garbage after them.  For example, on an
architecture where the initramfs address and size are specified
as a kernel parameter (specifically unicore32 and arm), specifying
e.g. initrd=0x01000000,4M will not work unless the image is padded
with nulls to 4MiB.  This is unlikely to occur if the user is using
this parameter to work around a bug in the bootloader.

---
 init/initramfs.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Comments

Sergei Shtylyov Aug. 6, 2012, 7:05 p.m. UTC | #1

Hello.

On 08/06/2012 01:32 PM, Ben Peddell wrote:

> The initramfs handling since commit df37bd15 has been rejecting

   Please also specify the summary of that commit in parens.

> valid images that have garbage after them.  For example, on an
> architecture where the initramfs address and size are specified
> as a kernel parameter (specifically unicore32 and arm), specifying
> e.g. initrd=0x01000000,4M will not work unless the image is padded
> with nulls to 4MiB.  This is unlikely to occur if the user is using
> this parameter to work around a bug in the bootloader.

   You didn't sign off the patchs, so it can't br applied.

WBR, Sergei

Patch

diff --git a/init/initramfs.c b/init/initramfs.c
index 84c6bf1..26c2cb1 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -467,6 +467,9 @@  static char * __init unpack_to_rootfs(char *buf, unsigned len)
 					 compress_name);
 				message = msg_buf;
 			}
+		} else if (state == Reset) {
+			my_inptr = len;
+			pr_warn("%s: junk at end of compressed archive\n", __func__);
 		} else
 			error("junk in compressed archive");
 		if (state != Reset)