07 May, 2021
1 commit
-
Patch series "background initramfs unpacking, and CONFIG_MODPROBE_PATH", v3.
These two patches are independent, but better-together.
The second is a rather trivial patch that simply allows the developer to
change "/sbin/modprobe" to something else - e.g. the empty string, so
that all request_module() during early boot return -ENOENT early, without
even spawning a usermode helper, needlessly synchronizing with the
initramfs unpacking.The first patch delegates decompressing the initramfs to a worker thread,
allowing do_initcalls() in main.c to proceed to the device_ and late_
initcalls without waiting for that decompression (and populating of
rootfs) to finish. Obviously, some of those later calls may rely on the
initramfs being available, so I've added synchronization points in the
firmware loader and usermodehelper paths - there might be other places
that would need this, but so far no one has been able to think of any
places I have missed.There's not much to win if most of the functionality needed during boot is
only available as modules. But systems with a custom-made .config and
initramfs can boot faster, partly due to utilizing more than one cpu
earlier, partly by avoiding known-futile modprobe calls (which would still
trigger synchronization with the initramfs unpacking, thus eliminating
most of the first benefit).This patch (of 2):
Most of the boot process doesn't actually need anything from the
initramfs, until of course PID1 is to be executed. So instead of doing
the decompressing and populating of the initramfs synchronously in
populate_rootfs() itself, push that off to a worker thread.This is primarily motivated by an embedded ppc target, where unpacking
even the rather modest sized initramfs takes 0.6 seconds, which is long
enough that the external watchdog becomes unhappy that it doesn't get
attention soon enough. By doing the initramfs decompression in a worker
thread, we get to do the device_initcalls and hence start petting the
watchdog much sooner.Normal desktops might benefit as well. On my mostly stock Ubuntu kernel,
my initramfs is a 26M xz-compressed blob, decompressing to around 126M.
That takes almost two seconds:[ 0.201454] Trying to unpack rootfs image as initramfs...
[ 1.976633] Freeing initrd memory: 29416KBefore this patch, these lines occur consecutively in dmesg. With this
patch, the timestamps on these two lines is roughly the same as above, but
with 172 lines inbetween - so more than one cpu has been kept busy doing
work that would otherwise only happen after the populate_rootfs()
finished.Should one of the initcalls done after rootfs_initcall time (i.e., device_
and late_ initcalls) need something from the initramfs (say, a kernel
module or a firmware blob), it will simply wait for the initramfs
unpacking to be done before proceeding, which should in theory make this
completely safe.But if some driver pokes around in the filesystem directly and not via one
of the official kernel interfaces (i.e. request_firmware*(),
call_usermodehelper*) that theory may not hold - also, I certainly might
have missed a spot when sprinkling wait_for_initramfs(). So there is an
escape hatch in the form of an initramfs_async= command line parameter.Link: https://lkml.kernel.org/r/20210313212528.2956377-1-linux@rasmusvillemoes.dk
Link: https://lkml.kernel.org/r/20210313212528.2956377-2-linux@rasmusvillemoes.dk
Signed-off-by: Rasmus Villemoes
Reviewed-by: Luis Chamberlain
Cc: Jessica Yu
Cc: Borislav Petkov
Cc: Jonathan Corbet
Cc: Greg Kroah-Hartman
Cc: Nick Desaulniers
Cc: Takashi Iwai
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 Feb, 2021
2 commits
-
Pull RISC-V updates from Palmer Dabbelt:
"A handful of new RISC-V related patches for this merge window:- A check to ensure drivers are properly using uaccess. This isn't
manifesting with any of the drivers I'm currently using, but may
catch errors in new drivers.- Some preliminary support for the FU740, along with the HiFive
Unleashed it will appear on.- NUMA support for RISC-V, which involves making the arm64 code
generic.- Support for kasan on the vmalloc region.
- A handful of new drivers for the Kendryte K210, along with the DT
plumbing required to boot on a handful of K210-based boards.- Support for allocating ASIDs.
- Preliminary support for kernels larger than 128MiB.
- Various other improvements to our KASAN support, including the
utilization of huge pages when allocating the KASAN regions.We may have already found a bug with the KASAN_VMALLOC code, but it's
passing my tests. There's a fix in the works, but that will probably
miss the merge window.* tag 'riscv-for-linus-5.12-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (75 commits)
riscv: Improve kasan population by using hugepages when possible
riscv: Improve kasan population function
riscv: Use KASAN_SHADOW_INIT define for kasan memory initialization
riscv: Improve kasan definitions
riscv: Get rid of MAX_EARLY_MAPPING_SIZE
soc: canaan: Sort the Makefile alphabetically
riscv: Disable KSAN_SANITIZE for vDSO
riscv: Remove unnecessary declaration
riscv: Add Canaan Kendryte K210 SD card defconfig
riscv: Update Canaan Kendryte K210 defconfig
riscv: Add Kendryte KD233 board device tree
riscv: Add SiPeed MAIXDUINO board device tree
riscv: Add SiPeed MAIX GO board device tree
riscv: Add SiPeed MAIX DOCK board device tree
riscv: Add SiPeed MAIX BiT board device tree
riscv: Update Canaan Kendryte K210 device tree
dt-bindings: add resets property to dw-apb-timer
dt-bindings: fix sifive gpio properties
dt-bindings: update sifive uart compatible string
dt-bindings: update sifive clint compatible string
... -
On systems with large amounts of reserved memory we may fail to
successfully complete unpack_to_rootfs() and be left with:Kernel panic - not syncing: write error
this is not too helpful to understand what happened, so let's wrap the
panic() calls with a surrounding show_mem() such that we have a chance of
understanding the memory conditions leading to these allocation failures.[akpm@linux-foundation.org: replace macro with C function]
Link: https://lkml.kernel.org/r/20210114231517.1854379-1-f.fainelli@gmail.com
Signed-off-by: Florian Fainelli
Cc: Barret Rhoden
Cc: Arnd Bergmann
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
19 Feb, 2021
1 commit
-
Some architectures(eg, ARM and riscv) have similar logic to
check and reserve the memory of initrd, let's provide a common
function reserve_initrd_mem() to reduce duplicated code.Signed-off-by: Kefeng Wang
Signed-off-by: Palmer Dabbelt
12 Dec, 2020
1 commit
-
There is only one function in init/initramfs.c that is in the .text
section, and it is marked __weak. When building with clang-12 and the
integrated assembler, this leads to a bug with recordmcount:./scripts/recordmcount "init/initramfs.o"
Cannot find symbol for section 2: .text.
init/initramfs.o: failedI'm not quite sure what exactly goes wrong, but I notice that this
function is only ever called from an __init function, and normally
inlined. Marking it __init as well is clearly correct and it leads to
recordmcount no longer complaining.Link: https://lkml.kernel.org/r/20201204165742.3815221-1-arnd@kernel.org
Signed-off-by: Arnd Bergmann
Cc: Nathan Chancellor
Cc: Nick Desaulniers
Cc: Barret Rhoden
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Sep, 2020
1 commit
-
init_stat() returns 0 on success, same as vfs_lstat(). When it replaced
vfs_lstat(), the '!' was dropped.Fixes: 716308a5331b ("init: add an init_stat helper")
Signed-off-by: Barret Rhoden
Reviewed-by: Christoph Hellwig
Signed-off-by: Linus Torvalds
31 Jul, 2020
12 commits
-
Add a simple helper to set timestamps with a kernel space file name and
switch the early init code over to it.Signed-off-by: Christoph Hellwig
-
Add a simple helper to stat with a kernel space file name and switch
the early init code over to it.Signed-off-by: Christoph Hellwig
-
Add a simple helper to mknod with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_mknod.Signed-off-by: Christoph Hellwig
-
Add a simple helper to mkdir with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_mkdir.Signed-off-by: Christoph Hellwig
-
Add a simple helper to symlink with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_symlink.Signed-off-by: Christoph Hellwig
-
Add a simple helper to link with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_link.Signed-off-by: Christoph Hellwig
-
Add a simple helper to chmod with a kernel space file name and switch
the early init code over to it.Signed-off-by: Christoph Hellwig
-
Add a simple helper to chown with a kernel space file name and switch
the early init code over to it.Signed-off-by: Christoph Hellwig
-
Add a simple helper to rmdir with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_rmdir.Signed-off-by: Christoph Hellwig
-
Add a simple helper to unlink with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_unlink.Signed-off-by: Christoph Hellwig
-
Don't bother saving away the pathname and just use the new struct path
based utimes helper instead.Signed-off-by: Christoph Hellwig
Acked-by: Linus Torvalds -
There is no good reason to mess with file descriptors from in-kernel
code, switch the initramfs unpacking to struct file based write
instead.Signed-off-by: Christoph Hellwig
Acked-by: Linus Torvalds
30 Jul, 2020
2 commits
-
There is no point in trying to clean up after unpacking the initramfs
failed, as it should never get past the magic number check. In addition
the current code only removes file that are direct children of the root
entry, which wasn't complete anywayFixes: df52092f3c97 ("fastboot: remove duplicate unpack_to_rootfs()")
Reported-by: Marek Szyprowski
Signed-off-by: Christoph Hellwig -
If initrd support is not enable just print the warning directly instead
of hiding the fact that we just failed behind two stub functions.Signed-off-by: Christoph Hellwig
Acked-by: Linus Torvalds
10 May, 2020
1 commit
-
It seems that for whatever reason, gcc-10 ends up not inlining a couple
of functions that used to be inlined before. Even if they only have one
single callsite - it looks like gcc may have decided that the code was
unlikely, and not worth inlining.The code generation difference is harmless, but caused a few new section
mismatch errors, since the (now no longer inlined) function wasn't in
the __init section, but called other init functions:Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem()
Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap()
Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap()So add the appropriate __init annotation to make modpost not complain.
In both cases there were trivially just a single callsite from another
__init function.Signed-off-by: Linus Torvalds
16 Oct, 2019
1 commit
-
arm64 calls memblock_free() for the initrd area in its implementation of
free_initrd_mem(), but this call has no actual effect that late in the boot
process. By the time initrd is freed, all the reserved memory is managed by
the page allocator and the memblock.reserved is unused, so the only purpose
of the memblock_free() call is to keep track of initrd memory for debugging
and accounting.Without the memblock_free() call the only difference between arm64 and the
generic versions of free_initrd_mem() is the memory poisoning.Move memblock_free() call to the generic code, enable it there
for the architectures that define ARCH_KEEP_MEMBLOCK and use the generic
implementation of free_initrd_mem() on arm64.Tested-by: Anshuman Khandual #arm64
Reviewed-by: Anshuman Khandual
Acked-by: Will Deacon
Signed-off-by: Mike Rapoport
Signed-off-by: Catalin Marinas
29 Jun, 2019
1 commit
-
With gcc-4.6.3:
WARNING: vmlinux.o(.text.unlikely+0x140): Section mismatch in reference from the function populate_initrd_image() to the variable .init.ramfs.info:__initramfs_size
The function populate_initrd_image() references
the variable __init __initramfs_size.
This is often because populate_initrd_image lacks a __init
annotation or the annotation of __initramfs_size is wrong.WARNING: vmlinux.o(.text.unlikely+0x14c): Section mismatch in reference from the function populate_initrd_image() to the function .init.text:unpack_to_rootfs()
The function populate_initrd_image() references
the function __init unpack_to_rootfs().
This is often because populate_initrd_image lacks a __init
annotation or the annotation of unpack_to_rootfs is wrong.WARNING: vmlinux.o(.text.unlikely+0x198): Section mismatch in reference from the function populate_initrd_image() to the function .init.text:xwrite()
The function populate_initrd_image() references
the function __init xwrite().
This is often because populate_initrd_image lacks a __init
annotation or the annotation of xwrite is wrong.Indeed, if the compiler decides not to inline populate_initrd_image(), a
warning is generated.Fix this by adding the missing __init annotations.
Link: http://lkml.kernel.org/r/20190617074340.12779-1-geert@linux-m68k.org
Fixes: 7c184ecd262fe64f ("initramfs: factor out a helper to populate the initrd image")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Christoph Hellwig
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
19 May, 2019
1 commit
-
Since commit 54c7a8916a88 ("initramfs: free initrd memory if opening
/initrd.image fails"), the kernel has unconditionally attempted to free
the initrd even if it doesn't exist.In the non-existent case this causes a boot-time splat if
CONFIG_DEBUG_VIRTUAL is enabled due to a call to virt_to_phys() with a
NULL address.Instead we should check that the initrd actually exists and only attempt
to free it if it does.Link: http://lkml.kernel.org/r/20190516143125.48948-1-steven.price@arm.com
Fixes: 54c7a8916a88 ("initramfs: free initrd memory if opening /initrd.image fails")
Signed-off-by: Steven Price
Reported-by: Mark Rutland
Tested-by: Mark Rutland
Reviewed-by: Mike Rapoport
Cc: Christoph Hellwig
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 May, 2019
7 commits
-
Various architectures including x86 poison the freed initrd memory. Do
the same in the generic free_initrd_mem implementation and switch a few
more architectures that are identical to the generic code over to it now.Link: http://lkml.kernel.org/r/20190213174621.29297-9-hch@lst.de
Signed-off-by: Christoph Hellwig
Acked-by: Mike Rapoport
Cc: Catalin Marinas [arm64]
Cc: Geert Uytterhoeven [m68k]
Cc: Steven Price
Cc: Alexander Viro
Cc: Guan Xuetao
Cc: Russell King
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
For most architectures free_initrd_mem just expands to the same
free_reserved_area call. Provide that as a generic implementation marked
__weak.Link: http://lkml.kernel.org/r/20190213174621.29297-8-hch@lst.de
Signed-off-by: Christoph Hellwig
Acked-by: Geert Uytterhoeven [m68k]
Acked-by: Mike Rapoport
Cc: Catalin Marinas [arm64]
Cc: Steven Price
Cc: Alexander Viro
Cc: Guan Xuetao
Cc: Russell King
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
No need to handle the freeing disable in arch code when we already have a
core hook (and a different name for the option) for it.Link: http://lkml.kernel.org/r/20190213174621.29297-7-hch@lst.de
Signed-off-by: Christoph Hellwig
Acked-by: Catalin Marinas [arm64]
Acked-by: Mike Rapoport
Cc: Geert Uytterhoeven [m68k]
Cc: Steven Price
Cc: Alexander Viro
Cc: Guan Xuetao
Cc: Russell King
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The code for kernels that support ramdisks or not is mostly the same.
Unify it by using an IS_ENABLED for the info message, and moving the error
message into a stub for populate_initrd_image.[cai@lca.pw: fix a compilation error]
Link: http://lkml.kernel.org/r/20190328014806.36375-1-cai@lca.pw
Link: http://lkml.kernel.org/r/20190213174621.29297-6-hch@lst.de
Signed-off-by: Christoph Hellwig
Signed-off-by: Qian Cai
Acked-by: Mike Rapoport
Cc: Catalin Marinas [arm64]
Cc: Geert Uytterhoeven [m68k]
Cc: Steven Price
Cc: Alexander Viro
Cc: Guan Xuetao
Cc: Russell King
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This will allow for cleaner code sharing in the caller.
Link: http://lkml.kernel.org/r/20190213174621.29297-5-hch@lst.de
Signed-off-by: Christoph Hellwig
Acked-by: Mike Rapoport
Cc: Catalin Marinas [arm64]
Cc: Geert Uytterhoeven [m68k]
Cc: Steven Price
Cc: Alexander Viro
Cc: Guan Xuetao
Cc: Russell King
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Factor the kexec logic into a separate helper, and then inline the rest of
free_initrd into the only caller.Link: http://lkml.kernel.org/r/20190213174621.29297-4-hch@lst.de
Signed-off-by: Christoph Hellwig
Acked-by: Mike Rapoport
Cc: Catalin Marinas [arm64]
Cc: Geert Uytterhoeven [m68k]
Cc: Steven Price
Cc: Alexander Viro
Cc: Guan Xuetao
Cc: Russell King
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Patch series "initramfs tidyups".
I've spent some time chasing down behavior in initramfs and found
plenty of opportunity to improve the code. A first stab on that is
contained in this series.This patch (of 7):
We free the initrd memory for all successful or error cases except for the
case where opening /initrd.image fails, which looks like an oversight.Steven said:
: This also changes the behaviour when CONFIG_INITRAMFS_FORCE is enabled
: - specifically it means that the initrd is freed (previously it was
: ignored and never freed). But that seems like reasonable behaviour and
: the previous behaviour looks like another oversight.Link: http://lkml.kernel.org/r/20190213174621.29297-3-hch@lst.de
Signed-off-by: Christoph Hellwig
Reviewed-by: Steven Price
Acked-by: Mike Rapoport
Cc: Catalin Marinas [arm64]
Cc: Geert Uytterhoeven [m68k]
Cc: Alexander Viro
Cc: Russell King
Cc: Will Deacon
Cc: Guan Xuetao
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Mar, 2019
1 commit
-
Use distinct error messages when archive decompression failed.
Link: http://lkml.kernel.org/r/20190212075635.7373-1-david.engraf@sysgo.com
Signed-off-by: David Engraf
Reviewed-by: Andrew Morton
Tested-by: Andy Shevchenko
Cc: Dominik Brodowski
Cc: Greg Kroah-Hartman
Cc: Philippe Ombredanne
Cc: Arnd Bergmann
Cc: Luc Van Oostenryck
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Feb, 2019
1 commit
-
Revert ff1522bb7d9845 ("initramfs: cleanup incomplete rootfs").
Andy reports
: This breaks my setup where I have U-boot provided more size of initramfs
: than needed. This allows a bit of flexibility to increase or decrease
: initramfs compressed image without taking care of bootloader. The proper
: solution is to do this if we sure that we didn't get enough memory,
: otherwise I can't consider the error fatal to clean up rootfs.Fixes: ff1522bb7d9845 ("initramfs: cleanup incomplete rootfs")
Reported-by: Andy Shevchenko
Tested-by: Andy Shevchenko
Cc: David Engraf
Cc: Dominik Brodowski
Cc: Greg Kroah-Hartman
Cc: Philippe Ombredanne
Cc: Arnd Bergmann
Cc: Luc Van Oostenryck
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Jan, 2019
1 commit
-
Unpacking an external initrd may fail e.g. not enough memory. This
leads to an incomplete rootfs because some files might be extracted
already. Fixed by cleaning the rootfs so the kernel is not using an
incomplete rootfs.Link: http://lkml.kernel.org/r/20181030151805.5519-1-david.engraf@sysgo.com
Signed-off-by: David Engraf
Cc: Dominik Brodowski
Cc: Greg Kroah-Hartman
Cc: Philippe Ombredanne
Cc: Arnd Bergmann
Cc: Luc Van Oostenryck
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Dec, 2018
1 commit
-
Pull in v4.20-rc5, solving a conflict we'll otherwise get in aio.c and
also getting the merge fix that went into mainline that users are
hitting testing for-4.21/block and/or for-next.* tag 'v4.20-rc5': (664 commits)
Linux 4.20-rc5
PCI: Fix incorrect value returned from pcie_get_speed_cap()
MAINTAINERS: Update linux-mips mailing list address
ocfs2: fix potential use after free
mm/khugepaged: fix the xas_create_range() error path
mm/khugepaged: collapse_shmem() do not crash on Compound
mm/khugepaged: collapse_shmem() without freezing new_page
mm/khugepaged: minor reorderings in collapse_shmem()
mm/khugepaged: collapse_shmem() remember to clear holes
mm/khugepaged: fix crashes due to misaccounted holes
mm/khugepaged: collapse_shmem() stop if punched or truncated
mm/huge_memory: fix lockdep complaint on 32-bit i_size_read()
mm/huge_memory: splitting set mapping+index before unfreeze
mm/huge_memory: rename freeze_page() to unmap_page()
initramfs: clean old path before creating a hardlink
kernel/kcov.c: mark funcs in __sanitizer_cov_trace_pc() as notrace
psi: make disabling/enabling easier for vendor kernels
proc: fixup map_files test on arm
debugobjects: avoid recursive calls with kmemleak
userfaultfd: shmem: UFFDIO_COPY: set the page dirty if VM_WRITE is not set
...
01 Dec, 2018
1 commit
-
sys_link() can fail due to the new path already existing. This case
ofen occurs when we use a concated initrd, for example:1) prepare a basic rootfs, it contains a regular files rc.local
lizhijian@:~/yocto-tiny-i386-2016-04-22$ cat etc/rc.local
#!/bin/sh
echo "Running /etc/rc.local..."
yocto-tiny-i386-2016-04-22$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n -9 >../rootfs.cgz2) create a extra initrd which also includes a etc/rc.local
lizhijian@:~/lkp-x86_64/etc$ echo "append initrd" >rc.local
lizhijian@:~/lkp/lkp-x86_64/etc$ cat rc.local
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ ln rc.local rc.local.hardlink
append initrd
lizhijian@:~/lkp/lkp-x86_64/etc$ stat rc.local rc.local.hardlink
File: 'rc.local'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086 Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -
File: 'rc.local.hardlink'
Size: 14 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 11296086 Links: 2
Access: (0664/-rw-rw-r--) Uid: ( 1002/lizhijian) Gid: ( 1002/lizhijian)
Access: 2018-11-15 16:08:28.654464815 +0800
Modify: 2018-11-15 16:07:57.514903210 +0800
Change: 2018-11-15 16:08:24.180228872 +0800
Birth: -lizhijian@:~/lkp/lkp-x86_64$ find . | sed 's,^\./,,' | cpio -o -H newc | gzip -n -9 >../rc-local.cgz
lizhijian@:~/lkp/lkp-x86_64$ gzip -dc ../rc-local.cgz | cpio -t
.
etc
etc/rc.local.hardlink <<< it will be extracted first at this initrd
etc/rc.local3) concate 2 initrds and boot
lizhijian@:~/lkp$ cat rootfs.cgz rc-local.cgz >concate-initrd.cgz
lizhijian@:~/lkp$ qemu-system-x86_64 -nographic -enable-kvm -cpu host -smp 1 -m 1024 -kernel ~/lkp/linux/arch/x86/boot/bzImage -append "console=ttyS0 earlyprint=ttyS0 ignore_loglevel" -initrd ./concate-initr.cgz -serial stdio -nodefaultsIn this case, sys_link(2) will fail and return -EEXIST, so we can only get
the rc.local at rootfs.cgz instead of rc-local.cgz[akpm@linux-foundation.org: move code to avoid forward declaration]
Link: http://lkml.kernel.org/r/1542352368-13299-1-git-send-email-lizhijian@cn.fujitsu.com
Signed-off-by: Li Zhijian
Cc: Philip Li
Cc: Dominik Brodowski
Cc: Li Zhijian
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Nov, 2018
1 commit
-
This removes a bunch of core and elevator related code. On the core
front, we remove anything related to queue running, draining,
initialization, plugging, and congestions. We also kill anything
related to request allocation, merging, retrieval, and completion.Remove any checking for single queue IO schedulers, as they no
longer exist. This means we can also delete a bunch of code related
to request issue, adding, completion, etc - and all the SQ related
ops and helpers.Also kill the load_default_modules(), as all that did was provide
for a way to load the default single queue elevator.Tested-by: Ming Lei
Reviewed-by: Omar Sandoval
Signed-off-by: Jens Axboe
23 Aug, 2018
1 commit
-
Sparse checking used to be disabled on init/do_mounts.c and a few related
files because "Many of the syscalls used in this file expect some of the
arguments to be __user pointers not __kernel pointers".However since 28128c61e ("kconfig.h: Include compiler types to avoid
missed struct attributes") the checks are, in fact, not disabled anymore
because of the more early include of "linux/compiler_types.h"So remove the now ineffective #undefery that was done to disable these
warnings, as well as the associated comment.Link: http://lkml.kernel.org/r/20180617115355.53799-1-luc.vanoostenryck@gmail.com
Signed-off-by: Luc Van Oostenryck
Cc: Dominik Brodowski
Cc: Al Viro
Cc: Kees Cook
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
03 Apr, 2018
2 commits
-
Using this helper allows us to avoid the in-kernel calls to the
sys_getdents64() syscall. The ksys_ prefix denotes that this function
is meant as a drop-in replacement for the syscall. In particular, it
uses the same calling convention as sys_getdents64().This patch is part of a series which removes in-kernel calls to syscalls.
On this basis, the syscall entry path can be streamlined. For details, see
http://lkml.kernel.org/r/20180325162527.GA17492@light.dominikbrodowski.netCc: Alexander Viro
Signed-off-by: Dominik Brodowski -
Using this wrapper allows us to avoid the in-kernel calls to the
sys_open() syscall. The ksys_ prefix denotes that this function is meant
as a drop-in replacement for the syscall. In particular, it uses the
same calling convention as sys_open().This patch is part of a series which removes in-kernel calls to syscalls.
On this basis, the syscall entry path can be streamlined. For details, see
http://lkml.kernel.org/r/20180325162527.GA17492@light.dominikbrodowski.netCc: Al Viro
Cc: Andrew Morton
Signed-off-by: Dominik Brodowski
