public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: "Eric W. Biederman" <ebiederm@xmission.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Don't understand comment in arch/x86/boot/compressed/misc.c
Date: Wed, 11 May 2011 17:40:04 -0500	[thread overview]
Message-ID: <4DCB1044.6030505@landley.net> (raw)

It talks about when decompression in place is safe to do:

 * Getting to provable safe in place decompression is hard.
 * Worst case behaviours need to be analyzed.
...
 * The buffer for decompression in place is the length of the
 * uncompressed data, plus a small amount extra to keep the algorithm safe.
 * The compressed data is placed at the end of the buffer.  The output
 * pointer is placed at the start of the buffer and the input pointer
 * is placed where the compressed data starts.  Problems will occur
 * when the output pointer overruns the input pointer.
 *
 * The output pointer can only overrun the input pointer if the input
 * pointer is moving faster than the output pointer.  A condition only
 * triggered by data whose compressed form is larger than the uncompressed
 * form.

You have an output pointer at a lower address catching up to an input
pointer at a higher address.  If the input pointer is moving FASTER
than the output pointer, wouldn't the gap between them grow rather
than shrink?

The concern seems to be about COMPRESSING in place, rather than
decompressing...?

Rob

             reply	other threads:[~2011-05-11 22:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11 22:40 Rob Landley [this message]
2011-05-12  0:12 ` Don't understand comment in arch/x86/boot/compressed/misc.c Eric W. Biederman
2011-05-13  2:37   ` Rob Landley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DCB1044.6030505@landley.net \
    --to=rob@landley.net \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox