On 04/17/2013 03:52 PM, Suzuki K. Poulose wrote: > From: Suzuki K. Poulose <suzuki at in.ibm.com> > > Teach uImage_probe_xxx() to return the information about > a corrupted image. This is required to prevent the loading > of a corrupted ramdisk, where we don't have strict checking > for the other formats, unlike the kernel. So, we should abort > the operation than causing a problem with the new kernel. > > Without this patch, a corrupted uImage ramdisk is treated as > a plain ramdisk where there is no format check involved. > > # kexec -l uImage --initrd romfs-initrd.corrupt > The data CRC does not match. Computed: 867e73f7 expected 8f097cc0 > # echo $? > 0 > # kexec -e > Starting new kernel > Bye! > Reserving 55MB of memory at 70MB for crashkernel (System RAM: 256MB) > Using Xilinx Virtex440 machine description > Linux version 3.6.0-rc3 (root at suzukikp) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (GCC) ) #66 Tue Apr 16 06:36:56 UTC 2013 > Found initrd at 0xcf5f8000:0xcfff8040 > ... > > NET: Registered protocol family 17 > RAMDISK: Couldn't find valid RAM disk image starting at 0. > List of all partitions: > No filesystem could mount root, tried: ext2 cramfs > Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) > > > With this patch : > > # kexec -l uImage --initrd romfs-initrd.corrupt > uImage: The data CRC does not match. Computed: 867e73f7 expected 8f097cc0 > uImage: Corrupted ramdisk file romfs-initrd > > With a corrupted kernel image(the behaviour remains the same) : > # kexec -l uImage.corrupt --initrd romfs-initrd > uImage: The data CRC does not match. Computed: 285787b7 expected e37f65ad > Cannot determine the file type of uImage.corrupt > > Signed-off-by: Suzuki K. Poulose <suzuki at in.ibm.com> Simon, Looks like there are no concerns about the approach in this patch. Could you please pull this in ? Thanks Suzuki
