kernel/linux.git/init/initramfs.c, branch v4.11.5

initramfs: avoid "label at end of compound statement" error

2017-05-20T12:49:49+00:00

commit 394e4f5d5834b610ee032cceb20a1b1f45b01d28 upstream. Commit 17a9be317475 ("initramfs: Always do fput() and load modules after rootfs populate") introduced an error for the CONFIG_BLK_DEV_RAM=y case, because even though the code looks fine, the compiler really wants a statement after a label, or you'll get complaints: init/initramfs.c: In function 'populate_rootfs': init/initramfs.c:644:2: error: label at end of compound statement That commit moved the subsequent statements to outside the compound statement, leaving the label without any associated statements. Reported-by: Jörg Otte Fixes: 17a9be317475 ("initramfs: Always do fput() and load modules after rootfs populate") Cc: Al Viro Cc: Stafford Horne Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

initramfs: Always do fput() and load modules after rootfs populate

2017-05-20T12:49:49+00:00

commit 17a9be31747535184f2af156b1f080ec4c92a952 upstream. In OpenRISC we do not have a bootloader passed initrd, but the built in initramfs does contain the /init and other binaries, including modules. The previous commit 08865514805d2 ("initramfs: finish fput() before accessing any binary from initramfs") made a change to only call fput() if the bootloader initrd was available, this caused intermittent crashes for OpenRISC. This patch changes the fput() to happen unconditionally if any rootfs is loaded. Also, I added some comments to make it a bit more clear why we call unpack_to_rootfs() multiple times. Fixes: 08865514805d2 ("initramfs: finish fput() before accessing any binary from initramfs") Cc: Lokesh Vutla Cc: Al Viro Acked-by: Al Viro Signed-off-by: Stafford Horne Signed-off-by: Greg Kroah-Hartman

initramfs: finish fput() before accessing any binary from initramfs

2017-02-28T02:43:46+00:00

Commit 4a9d4b024a31 ("switch fput to task_work_add") implements a schedule_work() for completing fput(), but did not guarantee calling __fput() after unpacking initramfs. Because of this, there is a possibility that during boot a driver can see ETXTBSY when it tries to load a binary from initramfs as fput() is still pending on that binary. This patch makes sure that fput() is completed after unpacking initramfs and removes the call to flush_delayed_fput() in kernel_init() which happens very late after unpacking initramfs. Link: http://lkml.kernel.org/r/20170201140540.22051-1-lokeshvutla@ti.com Signed-off-by: Lokesh Vutla Reported-by: Murali Karicheri Cc: Al Viro Cc: Tero Kristo Cc: Sekhar Nori Cc: Nishanth Menon Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

kexec: split kexec_load syscall from kexec core code

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

There are two kexec load syscalls, kexec_load another and kexec_file_load. kexec_file_load has been splited as kernel/kexec_file.c. In this patch I split kexec_load syscall code to kernel/kexec.c. And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and use kexec_file_load only, or vice verse. The original requirement is from Ted Ts'o, he want kexec kernel signature being checked with CONFIG_KEXEC_VERIFY_SIG enabled. But kexec-tools use kexec_load syscall can bypass the checking. Vivek Goyal proposed to create a common kconfig option so user can compile in only one syscall for loading kexec kernel. KEXEC/KEXEC_FILE selects KEXEC_CORE so that old config files still work. Because there's general code need CONFIG_KEXEC_CORE, so I updated all the architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects KEXEC_CORE in arch Kconfig. Also updated general kernel code with to kexec_load syscall. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Dave Young Cc: Eric W. Biederman Cc: Vivek Goyal Cc: Petr Tesarik Cc: Theodore Ts'o Cc: Josh Boyer Cc: David Howells Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

init/initramfs.c: resolve shadow warnings

2014-10-14T00:18:22+00:00

Resolve shadow warnings that are produced in W=2 builds by renaming a global with a too-generic name and renaming a formal parameter. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Mark Rustad Signed-off-by: Jeff Kirsher Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

initramfs: add write error checks

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

On a system with low memory extracting the initramfs may fail. If this happens the user gets "Failed to execute /init" instead of an initramfs error. Check return value of sys_write and call error() when the write was incomplete or failed. Signed-off-by: David Engraf 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

initramfs: support initrd that is bigger than 2GiB

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

When initrd (compressed or not) is used, kernel report data corrupted with /dev/ram0. The root cause: During initramfs checking, if it is initrd, it will be transferred to /initrd.image with sys_write. sys_write only support 2G-4K write, so if the initrd ram is more than that, /initrd.image will not complete at all. Add local xwrite to loop calling sys_write to workaround the problem. Also need to use xwrite in write_buffer() to handle: image is uncompressed cpio and there is one big file (>2G) in it. unpack_to_rootfs ===> write_buffer ===> actions[]/do_copy At the same time, we don't need to worry about sys_read/sys_write in do_mounts_rd.c::crd_load. As decompressor will have fill/flush and local buffer that is smaller than 2G. Test with uncompressed initrd, and compressed ones with gz, bz2, lzma,xz, lzop. Signed-off-by: Yinghai Lu Acked-by: H. Peter Anvin Cc: Ingo Molnar Cc: Geert Uytterhoeven Cc: Tetsuo Handa Cc: "Daniel M. Weeks" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

initramfs: debug detected compression method

2014-04-07T23:36:11+00:00

This can greatly aid in narrowing down the real source of initramfs problems such as failures related to the compression of the in-kernel initramfs when an external initramfs is in use as well. Existing errors are ambiguous as to which initramfs is a problem and why. [akpm@linux-foundation.org: use pr_debug()] Signed-off-by: Daniel M. Weeks Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

init: fix possible format string bug

2014-01-24T00:36:58+00:00

Use constant format string in case message changes. Signed-off-by: Tetsuo Handa Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds