linux-toradex.git/arch/s390/boot, branch v4.4.73

s390/decompressor: fix initrd corruption caused by bss clear

2017-04-12T10:38:34+00:00

commit d82c0d12c92705ef468683c9b7a8298dd61ed191 upstream.

Reorder the operations in decompress_kernel() to ensure initrd is moved
to a safe location before the bss section is zeroed.

During decompression bss can overlap with the initrd and this can
corrupt the initrd contents depending on the size of the compressed
kernel (which affects where the initrd is placed by the bootloader) and
the size of the bss section of the decompressor.

Also use the correct initrd size when checking for overlaps with
parmblock.

Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels)
Reviewed-by: Joy Latten 
Reviewed-by: Vineetha HariPai 
Signed-off-by: Marcelo Henrique Cerri 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

s390/boot/decompression: disable floating point in decompressor

2015-09-29T12:45:10+00:00

my gcc 5.1 used an ldgr instruction with a register != 0,2,4,6 for
spilling/filling into a floating point register in our decompressor.

This will cause an AFP-register data exception as the decompressor
did not setup the additional floating point registers via cr0.
That causes a program check loop that looked like a hang with
one "Uncompressing Linux... " message (directly booted via kvm)
or a loop of "Uncompressing Linux... " messages (when booted via
zipl boot loader).

The offending code in my build was

   48e400:       e3 c0 af ff ff 71       lay     %r12,-1(%r10)
-->48e406:       b3 c1 00 1c             ldgr    %f1,%r12
   48e40a:       ec 6c 01 22 02 7f       clij    %r6,2,12,0x48e64e

but gcc could do spilling into an fpr at any function. We can
simply disable floating point support at that early stage.

Signed-off-by: Christian Borntraeger 
Acked-by: Heiko Carstens 
Cc: stable@vger.kernel.org

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

s390: remove "64" suffix from a couple of files

2015-03-25T10:49:34+00:00

Rename a couple of files to get rid of the "64" suffix.
"git blame" will still work.

Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390: remove 31 bit support

2015-03-25T10:49:33+00:00

Remove the 31 bit support in order to reduce maintenance cost and
effectively remove dead code. Since a couple of years there is no
distribution left that comes with a 31 bit kernel.

The 31 bit kernel also has been broken since more than a year before
anybody noticed. In addition I added a removal warning to the kernel
shown at ipl for 5 minutes: a960062e5826 ("s390: add 31 bit warning
message") which let everybody know about the plan to remove 31 bit
code. We didn't get any response.

Given that the last 31 bit only machine was introduced in 1999 let's
remove the code.
Anybody with 31 bit user space code can still use the compat mode.

Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390/sclp: fix declaration of _sclp_print_early()

2015-01-08T09:02:51+00:00

_sclp_print_early() has return value: at present, return 0 for OK, 1 for
failure. It returns '%r2', so use 'long' as return value (upper caller
can check '%r2' directly). The related warning:

    CC      arch/s390/boot/compressed/misc.o
  arch/s390/boot/compressed/misc.c:66:8: warning: type defaults to 'int' in declaration of '_sclp_print_early' [-Wimplicit-int]
   extern _sclp_print_early(const char *);
          ^

At present, _sclp_print_early() is only used by puts(), so can still
remain its declaration in 'misc.c' file.

[heiko.carstens@de.ibm.com]: move declaration to sclp.h header file

Signed-off-by: Chen Gang 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390/boot: fix boot of compressed kernel built with gcc 4.9

2014-05-27T08:26:04+00:00

Add -fno-delete-null-pointer-checks to CFLAGS for the code in
arch/s390/boot. Without the option a compressed kernel built with
gcc 4.9 won't boot.

Signed-off-by: Martin Schwidefsky

s390/boot: Install bzImage as default kernel image

2013-11-15T13:08:36+00:00

The compressed kernel image is built since commit "[S390] add support for
compressed kernels" (1844c9bc0b2fed3023551c1affe033ab38e90b9a).
Now install the compressed kernel image (bzImage) as default.

Signed-off-by: Hendrik Brueckner 
Signed-off-by: Martin Schwidefsky

s390: add support for LZ4-compressed kernel

2013-07-26T11:25:19+00:00

Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390: fix linker script for 31 bit builds

2012-10-18T15:50:10+00:00

Because of a change in the s390 arch backend of binutils (commit 23ecd77
"Pick the default arch depending on the target size" in binutils repo)
31 bit builds will fail since the linker would now try to create 64 bit
binary output.
Fix this by setting OUTPUT_ARCH to s390:31-bit instead of s390.
Thanks to Andreas Krebbel for figuring out the issue.

Fixes this build error:

  LD      init/built-in.o
s390x-4.7.2-ld: s390:31-bit architecture of input file
 `arch/s390/kernel/head.o' is incompatible with s390:64-bit output

Cc: Andreas Krebbel 
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky