1. 28 Feb, 2017 1 commit
    • Arnd Bergmann's avatar
      ARM: 8654/1: decompressor: add strlen prototype · 7b96ddd0
      Arnd Bergmann authored
      The decompress.c file contains a declaration for strstr() so we can
      include some compression library code.
      With the updated LZ4 implementation, we run into the same problem again
      for strlen():
      In file included from ../include/linux/rcupdate.h:40:0,
                       from ../include/linux/srcu.h:33,
                       from ../include/linux/notifier.h:15,
                       from ../include/linux/memory_hotplug.h:6,
                       from ../include/linux/mmzone.h:749,
                       from ../include/linux/gfp.h:5,
                       from ../include/linux/kmod.h:22,
                       from ../include/linux/module.h:13,
                       from ../arch/arm/boot/compressed/../../../../lib/lz4/lz4_decompress.c:39,
                       from ../arch/arm/boot/compressed/../../../../lib/decompress_unlz4.c:13,
                       from ../arch/arm/boot/compressed/decompress.c:55:
      include/linux/cpumask.h: In function 'cpumask_parse':
      include/linux/cpumask.h:592:53: error: implicit declaration of function 'strlen';did you mean 'strstr'? [-Werror=implicit-function-declaration]
      This adds another declaration to work around the new problem.
      Fixes: ce83d9ab80d6 ("lib: update LZ4 compressor module")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
  2. 10 Sep, 2015 1 commit
    • Yinghai Lu's avatar
      lib/decompressors: use real out buf size for gunzip with kernel · 2d3862d2
      Yinghai Lu authored
      When loading x86 64bit kernel above 4GiB with patched grub2, got kernel
      gunzip error.
      | early console in decompress_kernel
      | decompress_kernel:
      |       input: [0x807f2143b4-0x807ff61aee]
      |      output: [0x807cc00000-0x807f3ea29b] 0x027ea29c: output_len
      | boot via startup_64
      | KASLR using RDTSC...
      |  new output: [0x46fe000000-0x470138cfff] 0x0338d000: output_run_size
      |  decompress: [0x46fe000000-0x47007ea29b] <=== [0x807f2143b4-0x807ff61aee]
      | Decompressing Linux... gz...
      | uncompression error
      | -- System halted
      the new buffer is at 0x46fe000000ULL, decompressor_gzip is using
      0xffffffb901ffffff as out_len.  gunzip in lib/zlib_inflate/inflate.c cap
      that len to 0x01ffffff and decompress fails later.
      We could hit this problem with crashkernel booting that uses kexec loading
      kernel above 4GiB.
      We have decompress_* support:
          1. inbuf[]/outbuf[] for kernel preboot.
          2. inbuf[]/flush() for initramfs
          3. fill()/flush() for initrd.
  3. 09 Jul, 2013 1 commit
  4. 11 Jan, 2013 1 commit
  5. 25 Aug, 2012 1 commit
  6. 24 Mar, 2012 1 commit
  7. 07 May, 2011 1 commit
  8. 14 Apr, 2010 1 commit
  9. 15 Mar, 2010 1 commit
  10. 25 Feb, 2010 1 commit
    • Russell King's avatar
      ARM: Eliminate decompressor -Dstatic= PIC hack · 5de813b6
      Russell King authored
      We used to build decompressors with -Dstatic= to avoid any local data
      being generated.  The problem is that local data generates GOTOFF
      relocations, which means we can't relocate the data relative to the
      text segment.
      Global data, on the other hand, goes through the GOT, and can be
      relocated anywhere.
      Unfortunately, with the new decompressors, this presents a problem
      since they declare static data within functions, and this leads to
      stack overflow.
      Fix this by separating out the decompressor code into a separate file,
      and removing 'static' from BSS data in misc.c.
      Also, discard the .data section - this means that should we end up
      with read/write initialized data, the decompressor will fail to link
      and the problem will be obvious.
      Acked-by: default avatarNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>