- 12 Aug, 2010 1 commit
-
-
David Howells authored
Don't try and #include <linux/slab.h> in lib/inflate.c from the bootloader code as linux/slab.h hauls in function defs that aren't available in the bootloader code and may also haul in conflicting functions. To fix this, make the inclusion of linux/slab.h contingent on NO_INFLATE_MALLOC as are the usages of kmalloc() and kfree(). In MN10300, this causes the following errors: In file included from include/linux/string.h:21, from include/linux/bitmap.h:8, from include/linux/nodemask.h:93, from include/linux/mmzone.h:16, from include/linux/gfp.h:4, from include/linux/slab.h:12, from arch/mn10300/boot/compressed/../../../../lib/inflate.c:106, from arch/mn10300/boot/compressed/misc.c:170: /warthog/am33/linux-2.6-mn10300/arch/mn10300/include/asm/string.h:19: error: conflicting types for 'memset' arch/mn10300/boot/compressed/misc.c:59: error: previous definition of 'memset' was here Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 30 Mar, 2010 1 commit
-
-
Tejun Heo authored
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include bloc...
-
- 15 Sep, 2009 1 commit
-
-
Nicolas Pitre authored
Due to problems at cam.org, my nico@cam.org email address is no longer valid. FRom now on, nico@fluxnic.net should be used instead. Signed-off-by:
Nicolas Pitre <nico@fluxnic.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 25 Jul, 2008 1 commit
-
-
Thomas Petazzoni authored
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 t...
-
- 29 Apr, 2008 1 commit
-
-
Jim Meyering authored
lib/inflate.c (inflate_dynamic): Don't deref NULL upon failed malloc. Signed-off-by:
Jim Meyering <meyering@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 02 May, 2007 2 commits
-
-
Jeremy Fitzhardinge authored
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 <jeremy@xensource.com> Signed-off-by:
Andi Kleen <ak@suse.de>
-
Jeremy Fitzhardinge authored
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 [<c0106b64>] show_trace_log_lvl+0x1a/0x30 [<c01075e6>] show_trace+0x12/0x14 [<c010763f>] dump_stack+0x16/0x18 [<c0107ca4>] do_IRQ+0x6d/0xd9 [<c010202b>] xen_evtchn_do_upcall+0x6e/0xa2 [<c0106781>] xen_hypervisor_callback+0x25/0x2c [<c010116c>] xen_restore_fl+0x27/0x29 [<c0330f63>] _spin_unlock_irqrestore+0x4a/0x50 [<c0117aab>] change_page_attr+0x577/0x584 [<c0117b45>] kernel_map_pages+0x8d/0xb4 [<c016a314>] cache_alloc_refill+0x53f/0x632 [<c016a6c2>] __kmalloc+0xc1/0x10d [<c0463d34>] malloc+0x10/0x12 [<c04641c1>] huft_build+0x2a7/0x5fa [<c04645a5>] inflate_fixed+0x91/0x136 [<c04657e2>] unpack_to_rootfs+0x5f2/0x8c1 [<c0465acf>] 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 <jeremy@xensource.com> Signed-off-by:
Andi Kleen <ak@suse.de> Cc: Tim Yamin <plasmaroo@gentoo.org> Cc: Andi Kleen <ak@suse.de> Cc: Matt Mackall <mpm@selenic.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ian Molton <spyro@f2s.com>
-
- 05 Aug, 2005 1 commit
-
-
Tim Yamin authored
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 <plasmaroo@gentoo.org> Signed-off-by:
Tavis Ormandy <taviso@gentoo.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- 16 Apr, 2005 1 commit
-
-
Linus Torvalds authored
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!
-