Re: [PATCH 3/7] inflate pt1: clean up input logic

On Sat, Feb 25, 2006 at 09:58:50PM +0000, Russell King wrote:
On Sat, Feb 25, 2006 at 03:47:04PM -0600, Matt Mackall wrote:
On Sat, Feb 25, 2006 at 09:22:48PM +0000, Russell King wrote:
init/do_mounts_rd.c:#include "../lib/inflate.c"
init/initramfs.c:#include "../lib/inflate.c"

for these your arguments that halting is fine is _NOT_ correct nor is it
desirable.

If you have an argument for why we shouldn't halt on failed
init{rd,ramfs} decompression, I look forward to hearing it.

Did you read that post?

This? http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/1024.html

Yes, that.

"The firmware then calls the kernel decompressor, which dutifully
decompresses the image, and calls the kernel. This image ends up
getting corrupted at some point."

Is your argument that we shouldn't halt after encountering a corrupt
image?

You're getting very confused.

1. kernel is loaded.
2. firmware scans loaded kernel, finds gzip magic numbers (the compressed
kernel.)
3. firmware sets initrd pointeres to point at the compressed kernel.
4. firmware calls kernel decompressor.
5. kernel decompresses and self-relocates.
6. compressed kernel image is thereby partly corrupted.
7. kernel boots.
8. kernel tries to decompress the compressed kernel image.
9. decompressor gets confused and tries to gobble more data than is
available.
10. kernel sits there being a dumb ***.

Why are we attempting to decompress the kernel image again? Accident?

In my mind, being unable to decompress init* is every bit as fatal as
being unable to mount root.

It's very simple. With fix, the kernel successfully boots on these
machines. Without fix, the kernel hangs on these machines for _no_
good reason other than the firmware did something that was stupid.

And how does this work currently? We attempt to decompress the kernel
a second time, give up and move on?

Assuming we can write to the compressed image (and thereby corrupt
it), wouldn't it be better to just stomp on the gzip magic and spare
us the overhead of decompressing it twice?

I'm sorry, I just do not see why you're being soo bloody difficult
over this.

Because it's taken this long to get close to an explanation of what
the problem is.

--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/