From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760029AbcCDQ0M (ORCPT ); Fri, 4 Mar 2016 11:26:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52566 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754012AbcCDQ0I (ORCPT ); Fri, 4 Mar 2016 11:26:08 -0500 From: Baoquan He To: linux-kernel@vger.kernel.org Cc: yinghai@kernel.org, keescook@chromium.org, hpa@zytor.com, vgoyal@redhat.com, mingo@redhat.com, bp@alien8.de, luto@kernel.org, lasse.collin@tukaani.org, akpm@linux-foundation.org, dyoung@redhat.com, Baoquan He Subject: [PATCH v3 04/19] x86, kaskr: Update the description for decompressor worst case Date: Sat, 5 Mar 2016 00:25:02 +0800 Message-Id: <1457108717-12191-5-git-send-email-bhe@redhat.com> In-Reply-To: <1457108717-12191-1-git-send-email-bhe@redhat.com> References: <1457108717-12191-1-git-send-email-bhe@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Current analysis is only for gzip decompressor only. In fact we can support 6 different decompressor. Update the description to cover all of them. Meanwhile fix several typos. Signed-off-by: Baoquan He --- v2->v3: This is newly added. arch/x86/boot/compressed/misc.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c index a56bb5d..7a65a8a 100644 --- a/arch/x86/boot/compressed/misc.c +++ b/arch/x86/boot/compressed/misc.c @@ -19,11 +19,13 @@ */ /* - * Getting to provable safe in place decompression is hard. - * Worst case behaviours need to be analyzed. - * Background information: + * Getting to provable safe in place decompression is hard. Worst case + * behaviours need be analyzed. Here let's take decompressing gzip-compressed + * kernel as example to illustrate it. + * + * The file layout of gzip compressed kernel is as follows. For more information, + * please refer to rfc 1951 and rfc 1952. * - * The file layout is: * magic[2] * method[1] * flags[1] @@ -70,13 +72,13 @@ * of 5 bytes per 32767 bytes. * * The worst case internal to a compressed block is very hard to figure. - * The worst case can at least be boundined by having one bit that represents + * The worst case can at least be bounded by having one bit that represents * 32764 bytes and then all of the rest of the bytes representing the very * very last byte. * * All of which is enough to compute an amount of extra data that is required * to be safe. To avoid problems at the block level allocating 5 extra bytes - * per 32767 bytes of data is sufficient. To avoind problems internal to a + * per 32767 bytes of data is sufficient. To avoid problems internal to a * block adding an extra 32767 bytes (the worst case uncompressed block size) * is sufficient, to ensure that in the worst case the decompressed data for * block will stop the byte before the compressed data for a block begins. @@ -88,11 +90,17 @@ * Adding 8 bytes per 32K is a bit excessive but much easier to calculate. * Adding 32768 instead of 32767 just makes for round numbers. * + * Above analysis is for decompressing gzip compressed kernel only. Up to + * now 6 different decompressor are supported all together. And among them + * xz stores data in chunks and has maximum chunk of 64K. Hence safety + * margin should be updated to cover all decompressors so that we don't + * need to deal with each of them separately. Please check + * the description in lib/decompressor_xxx.c for specific information. + * + * extra_bytes = (uncompressed_size >> 12) + 65536 + 128. + * */ -/* - * gzip declarations - */ #define STATIC static #undef memcpy -- 2.5.0