16 Sep, 2009

1 commit


26 Jul, 2008

1 commit

  • Inflate requires some dynamic memory allocation very early in the boot
    process and this is provided with a set of four functions:
    malloc/free/gzip_mark/gzip_release.

    The old inflate code used a mark/release strategy rather than implement
    free. This new version instead keeps a count on the number of outstanding
    allocations and when it hits zero, it resets the malloc arena.

    This allows removing all the mark and release implementations and unifying
    all the malloc/free implementations.

    The architecture-dependent code must define two addresses:
    - free_mem_ptr, the address of the beginning of the area in which
    allocations should be made
    - free_mem_end_ptr, the address of the end of the area in which
    allocations should be made. If set to 0, then no check is made on
    the number of allocations, it just grows as much as needed

    The architecture-dependent code can also provide an arch_decomp_wdog()
    function call. This function will be called several times during the
    decompression process, and allow to notify the watchdog that the system is
    still running. If an architecture provides such a call, then it must
    define ARCH_HAS_DECOMP_WDOG so that the generic inflate code calls
    arch_decomp_wdog().

    Work initially done by Matt Mackall, updated to a recent version of the
    kernel and improved by me.

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Thomas Petazzoni
    Cc: Matt Mackall
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Mikael Starvik
    Cc: Jesper Nilsson
    Cc: Haavard Skinnemoen
    Cc: David Howells
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Andi Kleen
    Cc: "H. Peter Anvin"
    Acked-by: Paul Mundt
    Acked-by: Yoshinori Sato
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Petazzoni
     

29 Apr, 2008

1 commit


03 May, 2007

2 commits

  • inflate_dynamic() has piggy stack usage too, so heap allocate it too.
    I'm not sure it actually gets used, but it shows up large in "make
    checkstack".

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Andi Kleen

    Jeremy Fitzhardinge
     
  • inflate_fixed and huft_build together use around 2.7k of stack. When
    using 4k stacks, I saw stack overflows from interrupts arriving while
    unpacking the root initrd:

    do_IRQ: stack overflow: 384
    [] show_trace_log_lvl+0x1a/0x30
    [] show_trace+0x12/0x14
    [] dump_stack+0x16/0x18
    [] do_IRQ+0x6d/0xd9
    [] xen_evtchn_do_upcall+0x6e/0xa2
    [] xen_hypervisor_callback+0x25/0x2c
    [] xen_restore_fl+0x27/0x29
    [] _spin_unlock_irqrestore+0x4a/0x50
    [] change_page_attr+0x577/0x584
    [] kernel_map_pages+0x8d/0xb4
    [] cache_alloc_refill+0x53f/0x632
    [] __kmalloc+0xc1/0x10d
    [] malloc+0x10/0x12
    [] huft_build+0x2a7/0x5fa
    [] inflate_fixed+0x91/0x136
    [] unpack_to_rootfs+0x5f2/0x8c1
    [] populate_rootfs+0x1e/0xe4

    (This was under Xen, but there's no reason it couldn't happen on bare
    hardware.)

    This patch mallocs the local variables, thereby reducing the stack
    usage to sane levels.

    Also, up the heap size for the kernel decompressor to deal with the
    extra allocation.

    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Andi Kleen
    Cc: Tim Yamin
    Cc: Andi Kleen
    Cc: Matt Mackall
    Cc: Ivan Kokshaysky
    Cc: Richard Henderson
    Cc: Russell King
    Cc: Ian Molton

    Jeremy Fitzhardinge
     

06 Aug, 2005

1 commit

  • These bugs have been fixed in the standard zlib for a while.

    See for example

    a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
    b) http://bugs.gentoo.org/show_bug.cgi?id=94584

    Signed-off-by: Tim Yamin
    Signed-off-by: Tavis Ormandy
    Signed-off-by: Linus Torvalds

    Tim Yamin
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds