linux-toradex.git/lib/decompress_unlzma.c, branch v7.2-rc5

minmax: make generic MIN() and MAX() macros available everywhere

2024-07-28T22:49:18+00:00

This just standardizes the use of MIN() and MAX() macros, with the very
traditional semantics.  The goal is to use these for C constant
expressions and for top-level / static initializers, and so be able to
simplify the min()/max() macros.

These macro names were used by various kernel code - they are very
traditional, after all - and all such users have been fixed up, with a
few different approaches:

 - trivial duplicated macro definitions have been removed

   Note that 'trivial' here means that it's obviously kernel code that
   already included all the major kernel headers, and thus gets the new
   generic MIN/MAX macros automatically.

 - non-trivial duplicated macro definitions are guarded with #ifndef

   This is the "yes, they define their own versions, but no, the include
   situation is not entirely obvious, and maybe they don't get the
   generic version automatically" case.

 - strange use case #1

   A couple of drivers decided that the way they want to describe their
   versioning is with

	#define MAJ 1
	#define MIN 2
	#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN)

   which adds zero value and I just did my Alexander the Great
   impersonation, and rewrote that pointless Gordian knot as

	#define DRV_VERSION "1.2"

   instead.

 - strange use case #2

   A couple of drivers thought that it's a good idea to have a random
   'MIN' or 'MAX' define for a value or index into a table, rather than
   the traditional macro that takes arguments.

   These values were re-written as C enum's instead. The new
   function-line macros only expand when followed by an open
   parenthesis, and thus don't clash with enum use.

Happily, there weren't really all that many of these cases, and a lot of
users already had the pattern of using '#ifndef' guarding (or in one
case just using '#undef MIN') before defining their own private version
that does the same thing. I left such cases alone.

Cc: David Laight 
Cc: Lorenzo Stoakes 
Signed-off-by: Linus Torvalds

lib: fix inconsistent indenting in process_bit1()

2021-05-07T02:24:12+00:00

Smatch gives the warning:
	lib/decompress_unlzma.c:395 process_bit1() warn: inconsistent indenting

Link: https://lkml.kernel.org/r/1614567775-4478-1-git-send-email-wangqing@vivo.com
Signed-off-by: Wang Qing 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/: replace HTTP links with HTTPS ones

2020-08-12T17:58:00+00:00

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Signed-off-by: Alexander A. Klimov 
Signed-off-by: Andrew Morton 
Acked-by: Coly Li 	[crc64.c]
Link: http://lkml.kernel.org/r/20200726112154.16510-1-grandmaster@al2klimov.de
Signed-off-by: Linus Torvalds

lib/decompress_unlzma: Do a NULL check for pointer

2015-09-10T20:29:01+00:00

Compare pointer-typed values to NULL rather than 0.

The semantic patch that makes this change is available
in scripts/coccinelle/null/badzero.cocci.

Signed-off-by: Fabio Estevam 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib/decompressors: use real out buf size for gunzip with kernel

2015-09-10T20:29:01+00:00

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.
This bug only affect kernel preboot path that use outbuf[].

Add __decompress and take real out_buf_len for gunzip instead of guessing
wrong buf size.

Fixes: 1431574a1c4 (lib/decompressors: fix "no limit" output buffer length)
Signed-off-by: Yinghai Lu 
Cc: Alexandre Courbot 
Cc: Jon Medhurst 
Cc: Stephen Warren 
Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

initramfs: support initramfs that is bigger than 2GiB

2014-08-08T22:57:26+00:00

Now with 64bit bzImage and kexec tools, we support ramdisk that size is
bigger than 2g, as we could put it above 4G.

Found compressed initramfs image could not be decompressed properly.  It
turns out that image length is int during decompress detection, and it
will become < 0 when length is more than 2G.  Furthermore, during
decompressing len as int is used for inbuf count, that has problem too.

Change len to long, that should be ok as on 32 bit platform long is
32bits.

Tested with following compressed initramfs image as root with kexec.
	gzip, bzip2, xz, lzma, lzop, lz4.
run time for populate_rootfs():
   size        name       Nehalem-EX  Westmere-EX  Ivybridge-EX
 9034400256 root_img     :   26s           24s          30s
 3561095057 root_img.lz4 :   28s           27s          27s
 3459554629 root_img.lzo :   29s           29s          28s
 3219399480 root_img.gz  :   64s           62s          49s
 2251594592 root_img.xz  :  262s          260s         183s
 2226366598 root_img.lzma:  386s          376s         277s
 2901482513 root_img.bz2 :  635s          599s

Signed-off-by: Yinghai Lu 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Rashika Kheria 
Cc: Josh Triplett 
Cc: Kyungsik Lee 
Cc: P J P 
Cc: Al Viro 
Cc: Tetsuo Handa 
Cc: "Daniel M. Weeks" 
Cc: Alexandre Courbot 
Cc: Jan Beulich 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

treewide: Fix comment and string typo 'bufer'

2011-12-06T08:53:40+00:00

Signed-off-by: Paul Bolle 
Signed-off-by: Jiri Kosina

Decompressors: validate match distance in decompress_unlzma.c

2011-01-13T16:03:24+00:00

Validate the newly decoded distance (rep0) in process_bit1().  This is to
detect corrupt LZMA data quickly.  The old code can run for long time
producing garbage until it hits the end of the input.

Signed-off-by: Lasse Collin 
Cc: "H. Peter Anvin" 
Cc: Alain Knaff 
Cc: Albin Tonnerre 
Cc: Phillip Lougher 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Decompressors: check for write errors in decompress_unlzma.c

2011-01-13T16:03:24+00:00

The return value of wr->flush() is not checked in write_byte().  This
means that the decompressor won't stop even if the caller doesn't want
more data.  This can happen e.g.  with corrupt LZMA-compressed initramfs.
Returning the error quickly allows the user to see the error message
quicker.

There is a similar missing check for wr.flush() near the end of unlzma().

Signed-off-by: Lasse Collin 
Cc: "H. Peter Anvin" 
Cc: Alain Knaff 
Cc: Albin Tonnerre 
Cc: Phillip Lougher 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Decompressors: check for read errors in decompress_unlzma.c

2011-01-13T16:03:24+00:00

Return value of rc->fill() is checked in rc_read() and error() is called
when needed, but then the code continues as if nothing had happened.

rc_read() is a void function and it's on the top of performance critical
call stacks, so propagating the error code via return values doesn't sound
like the best fix.  It seems better to check rc->buffer_size (which holds
the return value of rc->fill()) in the main loop.  It does nothing bad
that the code runs a little with unknown data after a failed rc->fill().

This fixes an infinite loop in initramfs decompression if the
LZMA-compressed initramfs image is corrupt.

Signed-off-by: Lasse Collin 
Cc: "H. Peter Anvin" 
Cc: Alain Knaff 
Cc: Albin Tonnerre 
Cc: Phillip Lougher 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds