- 07 May, 2021 40 commits
-
-
Rasmus Villemoes authored
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: 29416K Before 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.dkSigned-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
Luis Chamberlain <mcgrof@kernel.org> Cc: Jessica Yu <jeyu@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Rasmus Villemoes authored
No callers in the tree. Link: https://lkml.kernel.org/r/20210309151723.1907838-2-linux@rasmusvillemoes.dkSigned-off-by:
-
Rasmus Villemoes authored
It's currently nigh impossible to get these pr_debug()s to print something. Being guarded by initcall_debug means one has to enable tons of other debug output during boot, and the system_state condition further means it's impossible to get them when loading modules later. Also, the compiler can't know that these global conditions do not change, so there are W=2 warnings kernel/async.c:125:9: warning: `calltime' may be used uninitialized in this function [-Wmaybe-uninitialized] kernel/async.c:300:9: warning: `starttime' may be used uninitialized in this function [-Wmaybe-uninitialized] Make it possible, for a DYNAMIC_DEBUG kernel, to get these to print their messages by booting with appropriate 'dyndbg="file async.c +p"' command line argument. For a non-DYNAMIC_DEBUG kernel, pr_debug() compiles to nothing. This does cost doing an unconditional ktime_get() for the starttime value, but the corresponding ktime_get for the end time can be elided by factoring it into a function which only gets called if the printk() arguments end up being evaluated. Link: https://lkml.kernel.org/r/20210309151723.1907838-1-linux@rasmusvillemoes.dkSigned-off-by:
-
Zhang Yunkai authored
'assert.h' included in 'sparsebit.c' is duplicated. It is also included in the 161th line. 'string.h' included in 'mincore_selftest.c' is duplicated. It is also included in the 15th line. 'sched.h' included in 'tlbie_test.c' is duplicated. It is also included in the 33th line. Link: https://lkml.kernel.org/r/20210316073336.426255-1-zhang.yunkai@zte.com.cnSigned-off-by:
Zhang Yunkai <zhang.yunkai@zte.com.cn> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by:
-
Alistair Popple authored
request_free_mem_region() is used to find an empty range of physical addresses for hotplugging ZONE_DEVICE memory. It does this by iterating over the range of possible addresses using region_intersects() to see if the range is free before calling request_mem_region() to allocate the region. However the resource_lock is dropped between these two calls meaning by the time request_mem_region() is called in request_free_mem_region() another thread may have already reserved the requested region. This results in unexpected failures and a message in the kernel log from hitting this condition: /* * mm/hmm.c reserves physical addresses which then * become unavailable to other users. Conflicts are * not expected. Warn to aid debugging if encountered. */ if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) { pr_warn("Unaddressable device %s %pR conflicts with %pR", conflict->name, conflict, res); These unexpected failures can be corrected by holding resource_lock across the two calls. This also requires memory allocation to be performed prior to taking the lock. Link: https://lkml.kernel.org/r/20210419070109.4780-3-apopple@nvidia.comSigned-off-by:Alistair Popple <apopple@nvidia.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Cc: Balbir Singh <bsingharora@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jerome Glisse <jglisse@redhat.com> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Muchun Song <smuchun@gmail.com> Signed-off-by:
-
Alistair Popple authored
Refactor the portion of __request_region() done whilst holding the resource_lock into a separate function to allow callers to hold the lock. Link: https://lkml.kernel.org/r/20210419070109.4780-2-apopple@nvidia.comSigned-off-by:
-
Alistair Popple authored
Introduce a version of region_intersects() that can be called with the resource_lock already held. This will be used in a future fix to __request_free_mem_region(). [akpm@linux-foundation.org: make __region_intersects static] Link: https://lkml.kernel.org/r/20210419070109.4780-1-apopple@nvidia.comSigned-off-by:
-
David Hildenbrand authored
All functions that search for IORESOURCE_SYSTEM_RAM or IORESOURCE_MEM resources now properly consider the whole resource tree, not just the first level. Let's drop the unused first_lvl / siblings_only logic. Remove documentation that indicates that some functions behave differently, all consider the full resource tree now. Link: https://lkml.kernel.org/r/20210325115326.7826-4-david@redhat.comSigned-off-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Dave Young <dyoung@redhat.com> Cc: Baoquan He <bhe@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Qian Cai <cai@lca.pw> Cc: Oscar Salvador <osalvador@suse.de> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by:
-
David Hildenbrand authored
It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY) only on the first level in the resource tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels, for example, inside device containers. IORESOURCE_SYSTEM_RAM is defined as IORESOURCE_MEM | IORESOURCE_SYSRAM and just a special type of IORESOURCE_MEM. The function walk_mem_res() only considers the first level and is used in arch/x86/mm/ioremap.c:__ioremap_check_mem() only. We currently fail to identify System RAM added by dax/kmem and virtio-mem as "IORES_MAP_SYSTEM_RAM", for example, allowing for remapping of such "normal RAM" in __ioremap_caller(). Let's find all IORESOURCE_MEM | IORESOURCE_BUSY resources, making the function behave similar to walk_system_ram_res(). Link: https://lkml.kernel.org/r/20210325115326.7826-3-david@redhat.com Fixes: ebf71552 ("virtio-mem: Add parent resource for all added "System RAM"") Fixes: c221c0b0 ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by:
-
David Hildenbrand authored
Patch series "kernel/resource: make walk_system_ram_res() and walk_mem_res() search the whole tree", v2. Playing with kdump+virtio-mem I noticed that kexec_file_load() does not consider System RAM added via dax/kmem and virtio-mem when preparing the elf header for kdump. Looking into the details, the logic used in walk_system_ram_res() and walk_mem_res() seems to be outdated. walk_system_ram_range() already does the right thing, let's change walk_system_ram_res() and walk_mem_res(), and clean up. Loading a kdump kernel via "kexec -p -s" ... will result in the kdump kernel to also dump dax/kmem and virtio-mem added System RAM now. Note: kexec-tools on x86-64 also have to be updated to consider this memory in the kexec_load() case when processing /proc/iomem. This patch (of 3): It used to be true that we can have system RAM (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY) only on the first level in the resource tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels, for example, inside device containers. We have two users of walk_system_ram_res(), which currently only consideres the first level: a) kernel/kexec_file.c:kexec_walk_resources() -- We properly skip IORESOURCE_SYSRAM_DRIVER_MANAGED resources via locate_mem_hole_callback(), so even after this change, we won't be placing kexec images onto dax/kmem and virtio-mem added memory. No change. b) arch/x86/kernel/crash.c:fill_up_crash_elf_data() -- we're currently not adding relevant ranges to the crash elf header, resulting in them not getting dumped via kdump. This change fixes loading a crashkernel via kexec_file_load() and including dax/kmem and virtio-mem added System RAM in the crashdump on x86-64. Note that e.g,, arm64 relies on memblock data and, therefore, always considers all added System RAM already. Let's find all IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY resources, making the function behave like walk_system_ram_range(). Link: https://lkml.kernel.org/r/20210325115326.7826-1-david@redhat.com Link: https://lkml.kernel.org/r/20210325115326.7826-2-david@redhat.com Fixes: ebf71552 ("virtio-mem: Add parent resource for all added "System RAM"") Fixes: c221c0b0 ("device-dax: "Hotplug" persistent memory for use like normal RAM") Signed-off-by:
Baoquan He <bhe@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Dave Young <dyoung@redhat.com> Cc: Baoquan He <bhe@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Qian Cai <cai@lca.pw> Cc: Oscar Salvador <osalvador@suse.de> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Barry Song authored
arm64 uses SP_EL0 to save the current task_struct address. While running in EL0, SP_EL0 is clobbered by userspace. So if the upper bit is not 1 (not TTBR1), the current address is invalid. This patch checks the upper bit of SP_EL0, if the upper bit is 1, lx_current() of arm64 will return the derefrence of current task. Otherwise, lx_current() will tell users they are running in userspace(EL0). While arm64 is running in EL0, it is actually pointless to print current task as the memory of kernel space is not accessible in EL0. Link: https://lkml.kernel.org/r/20210314203444.15188-3-song.bao.hua@hisilicon.comSigned-off-by:
Barry Song <song.bao.hua@hisilicon.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Kieran Bingham <kbingham@kernel.org> Signed-off-by:
-
Barry Song authored
Patch series "scripts/gdb: clarify the platforms supporting lx_current and add arm64 support", v2. lx_current depends on per_cpu current_task variable which exists on x86 only. so it actually works on x86 only. the 1st patch documents this clearly; the 2nd patch adds support for arm64. This patch (of 2): x86 is the only architecture which has per_cpu current_task: arch$ git grep current_task | grep -i per_cpu x86/include/asm/current.h:DECLARE_PER_CPU(struct task_struct *, current_task); x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) ____cacheline_aligned = x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task); x86/kernel/cpu/common.c:DEFINE_PER_CPU(struct task_struct *, current_task) = &init_task; x86/kernel/cpu/common.c:EXPORT_PER_CPU_SYMBOL(current_task); x86/kernel/smpboot.c: per_cpu(current_task, cpu) = idle; On other architectures, lx_current() will lead to a python exception: (gdb) p $lx_current().pid Python Exception <class 'gdb.error'> No symbol "current_task" in current context.: Error occurred in Python: No symbol "current_task" in current context. To avoid more people struggling and wasting time in other architectures, document it. Link: https://lkml.kernel.org/r/20210314203444.15188-1-song.bao.hua@hisilicon.com Link: https://lkml.kernel.org/r/20210314203444.15188-2-song.bao.hua@hisilicon.comSigned-off-by:
-
Johannes Berg authored
If we store the relative path, the user might later cd to a different directory, and that would break the automatic symbol resolving that happens when a module is loaded into the target kernel. Fix this by storing the abspath() of each path given, just like we already do for the cwd (os.getcwd() is absolute.) Link: https://lkml.kernel.org/r/20201217091747.bf4332cf2b35.I10ebbdb7e9b80ab1a5cddebf53d073be8232d656@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com> Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Signed-off-by:
-
Yafang Shao authored
When I was implementing a latency analyzer tool by using task->delays and other things, I found an issue in delayacct. The issue is it should clear the target's flag instead of current's in delayacct_blkio_end(). When I git blame delayacct, I found there're some similar issues we have fixed in delayacct_blkio_end(). - Commit c96f5471 ("delayacct: Account blkio completion on the correct task") fixed the issue that it should account blkio completion on the target task instead of current. - Commit b512719f ("delayacct: fix crash in delayacct_blkio_end() after delayacct init failure") fixed the issue that it should check target task's delays instead of current task'. It seems that delayacct_blkio_{begin, end} are error prone. So I introduce a new paratmeter - the target task 'p' - to these helpers. After that change, the callsite will specifilly set the right task, which should make it less error prone. Link: https://lkml.kernel.org/r/20210414083720.24083-1-laoar.shao@gmail.comSigned-off-by:
Yafang Shao <laoar.shao@gmail.com> Cc: Tejun Heo <tj@kernel.org> Cc: Josh Snyder <joshs@netflix.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
He Ying authored
We found these warnings in kernel/panic.c by using sparse tool: warning: symbol 'panic_smp_self_stop' was not declared. warning: symbol 'nmi_panic_self_stop' was not declared. warning: symbol 'crash_smp_send_stop' was not declared. To avoid them, add declarations for these three functions in include/linux/smp.h. Link: https://lkml.kernel.org/r/20210316084150.75201-1-heying24@huawei.comSigned-off-by:
He Ying <heying24@huawei.com> Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
-
Nick Desaulniers authored
LLVM changed the expected function signatures for llvm_gcda_start_file() and llvm_gcda_emit_function() in the clang-11 release. Drop the older implementations and require folks to upgrade their compiler if they're interested in GCOV support. Link: https://reviews.llvm.org/rGcdd683b516d147925212724b09ec6fb792a40041 Link: https://reviews.llvm.org/rG13a633b438b6500ecad9e4f936ebadf3411d0f44 Link: https://lkml.kernel.org/r/20210312224132.3413602-3-ndesaulniers@google.com Link: https://lkml.kernel.org/r/20210413183113.2977432-1-ndesaulniers@google.comSigned-off-by:
Nick Desaulniers <ndesaulniers@google.com> Suggested-by:
Nathan Chancellor <nathan@kernel.org> Acked-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by:
Fangrui Song <maskray@google.com> Cc: Prasad Sodagudi <psodagud@quicinc.com> Cc: Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Using vmalloc() in gcov is really quite wasteful, many of the objects allocated are really small (e.g. I've seen 24 bytes.) Use kvmalloc() to automatically pick the better of kmalloc() or vmalloc() depending on the size. [johannes.berg@intel.com: fix clang-11+ build] Link: https://lkml.kernel.org/r/20210412214210.6e1ecca9cdc5.I24459763acf0591d5e6b31c7e3a59890d802f79c@changeid Link: https://lkml.kernel.org/r/20210315235453.799e7a9d627d.I741d0db096c6f312910f7f1bcdfde0fda20801a4@changeidSigned-off-by:
-
Johannes Berg authored
Use just a single vmalloc() with struct_size() instead of a separate kmalloc() for the iter struct. Link: https://lkml.kernel.org/r/20210315235453.b6de4a92096e.Iac40a5166589cefbff8449e466bd1b38ea7a17af@changeidSigned-off-by:
-
Johannes Berg authored
There's a lot of duplicated code between gcc and clang implementations, move it over to fs.c to simplify the code, there's no reason to believe that for small data like this one would not just implement the simple convert_to_gcda() function. Link: https://lkml.kernel.org/r/20210315235453.e3fbb86e99a0.I08a3ee6dbe47ea3e8024956083f162884a958e40@changeidSigned-off-by:
-
Pavel Tatashin authored
kmsg_dump(KMSG_DUMP_SHUTDOWN) is called before machine_restart(), machine_halt(), and machine_power_off(). The only one that is missing is machine_kexec(). The dmesg output that it contains can be used to study the shutdown performance of both kernel and systemd during kexec reboot. Here is example of dmesg data collected after kexec: root@dplat-cp22:~# cat /sys/fs/pstore/dmesg-ramoops-0 | tail ... [ 70.914592] psci: CPU3 killed (polled 0 ms) [ 70.915705] CPU4: shutdown [ 70.916643] psci: CPU4 killed (polled 4 ms) [ 70.917715] CPU5: shutdown [ 70.918725] psci: CPU5 killed (polled 0 ms) [ 70.919704] CPU6: shutdown [ 70.920726] psci: CPU6 killed (polled 4 ms) [ 70.921642] CPU7: shutdown [ 70.922650] psci: CPU7 killed (polled 0 ms) Link: https://lkml.kernel.org/r/20210319192326.146000-2-pasha.tatashin@soleen.comSigned-off-by:
Pavel Tatashin <pasha.tatashin@soleen.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Petr Mladek <pmladek@suse.com> Reviewed-by:
Bhupesh Sharma <bhsharma@redhat.com> Acked-by:
Tyler Hicks <tyhicks@linux.microsoft.com> Cc: James Morris <jmorris@namei.org> Cc: Sasha Levin <sashal@kernel.org> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
-
Jia-Ju Bai authored
When vzalloc() returns NULL to sha_regions, no error return code of kexec_calculate_store_digests() is assigned. To fix this bug, ret is assigned with -ENOMEM in this case. Link: https://lkml.kernel.org/r/20210309083904.24321-1-baijiaju1990@gmail.com Fixes: a43cac0d ("kexec: split kexec_file syscall code to kexec_file.c") Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Reported-by:
TOTE Robot <oslab@tsinghua.edu.cn> Acked-by:
-
Joe LeVeque authored
The purpose is to notify the kernel module for fast reboot. Upstream a patch from the SONiC network operating system [1]. [1]: https://github.com/Azure/sonic-linux-kernel/pull/46 Link: https://lkml.kernel.org/r/20210304124626.13927-1-pmenzel@molgen.mpg.deSigned-off-by:
Joe LeVeque <jolevequ@microsoft.com> Signed-off-by:
Paul Menzel <pmenzel@molgen.mpg.de> Acked-by:
-
Xiaofeng Cao authored
change 'ancestoral' to 'ancestral' change 'reuseable' to 'reusable' delete 'do' grammatically Link: https://lkml.kernel.org/r/20210317082031.11692-1-caoxiaofeng@yulong.comSigned-off-by:
Xiaofeng Cao <caoxiaofeng@yulong.com> Reviewed-by:
Christian Brauner <christian.brauner@ubuntu.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Rolf Eike Beer authored
All this can happen without a single goto. Link: https://lkml.kernel.org/r/2072685.XptgVkyDqn@devpool47Signed-off-by:
Rolf Eike Beer <eb@emlix.com> Reviewed-by:
-
Jim Newsome authored
Add a special-case when waiting on a pid (via waitpid, waitid, wait4, etc) to avoid doing an O(n) scan of children and tracees, and instead do an O(1) lookup. This improves performance when waiting on a pid from a thread group with many children and/or tracees. Time to fork and then call waitpid on the child, from a task that already has N children [1]: N | Before | After -----|---------|------ 1 | 74 us | 74 us 20 | 72 us | 75 us 100 | 83 us | 77 us 500 | 99 us | 74 us 1000 | 179 us | 75 us 5000 | 804 us | 79 us 8000 | 1268 us | 78 us [1]: https://lkml.org/lkml/2021/3/12/1567 This can make a substantial performance improvement for applications with a thread that has many children or tracees and frequently needs to wait on them. Tools that use ptrace to intercept syscalls for a large number of processes are likely to fall into this category. In particular this patch was developed while building a ptrace-based second generation of the Shadow emulator [2], for which it allows us to avoid quadratic scaling (without having to use a workaround that introduces a ~40% performance penalty) [3]. Other examples of tools that fall into this category which this patch may help include User Mode Linux [4] and DetTrace [5]. [2]: https://shadow.github.io/ [3]: https://github.com/shadow/shadow/issues/1134#issuecomment-798992292 [4]: https://en.wikipedia.org/wiki/User-mode_Linux [5]: https://github.com/dettrace/dettrace Link: https://lkml.kernel.org/r/20210314231544.9379-1-jnewsome@torproject.orgSigned-off-by:
James Newsome <jnewsome@torproject.org> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> Cc: "Eric W . Biederman" <ebiederm@xmission.com> Cc: Christian Brauner <christian@brauner.io> Signed-off-by:
-
Gustavo A. R. Silva authored
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warning: CC [M] fs/hpfs/dir.o fs/hpfs/dir.c: In function `hpfs_readdir': fs/hpfs/dir.c:163:41: warning: array subscript 1 is above array bounds of `u8[1]' {aka `unsigned char[1]'} [-Warray-bounds] 163 | || de ->name[0] != 1 || de->name[1] != 1)) | ~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/109 Link: https://lkml.kernel.org/r/20210326173510.GA81212@embeddedorSigned-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Signed-off-by:
-
Lu Jialin authored
numer -> number in fs/nilfs2/cpfile.c Decription -> Description in fs/nilfs2/ioctl.c isntance -> instance in fs/nilfs2/the_nilfs.c Link: https://lkml.kernel.org/r/1617942951-14631-1-git-send-email-konishi.ryusuke@gmail.com Link: https://lore.kernel.org/r/20210409022519.176988-1-lujialin4@huawei.comSigned-off-by:
Lu Jialin <lujialin4@huawei.com> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Signed-off-by:
-
Liu xuzhi authored
Two typos are found out by codespell tool \ in 2217th and 2254th lines of segment.c: $ codespell ./fs/nilfs2/ ./segment.c:2217 :retured ==> returned ./segment.c:2254: retured ==> returned Fix two typos found by codespell. Link: https://lkml.kernel.org/r/1617864087-8198-1-git-send-email-konishi.ryusuke@gmail.comSigned-off-by:
Liu xuzhi <liu.xuzhi@zte.com.cn> Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Link: https://lkml.kernel.org/r/5b7caa73958588065fabc59032c340179b409ef5.1605896059.git.gustavoars@kernel.orgSigned-off-by:
-
Davidlohr Bueso authored
Commit 339ddb53 ("fs/epoll: remove unnecessary wakeups of nested epoll") changed the userspace visible behavior of exclusive waiters blocked on a common epoll descriptor upon a single event becoming ready. Previously, all tasks doing epoll_wait would awake, and now only one is awoken, potentially causing missed wakeups on applications that rely on this behavior, such as Apache Qpid. While the aforementioned commit aims at having only a wakeup single path in ep_poll_callback (with the exceptions of epoll_ctl cases), we need to restore the wakeup in what was the old ep_scan_ready_list() such that the next thread can be awoken, in a cascading style, after the waker's corresponding ep_send_events(). Link: https://lkml.kernel.org/r/20210405231025.33829-3-dave@stgolabs.net Fixes: 339ddb53 ("fs/epoll: remove unnecessary wakeups of nested epoll") Signed-off-by:
Davidlohr Bueso <dbueso@suse.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Jason Baron <jbaron@akamai.com> Cc: Roman Penyaev <rpenyaev@suse.de> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Davidlohr Bueso authored
Patch series "fs/epoll: restore user-visible behavior upon event ready". This series tries to address a change in user visible behavior, reported in https://bugzilla.kernel.org/show_bug.cgi?id=208943. Epoll does not report an event to all the threads running epoll_wait() on the same epoll descriptor. Unsurprisingly, this was bisected back to 339ddb53 (fs/epoll: remove unnecessary wakeups of nested epoll), which has had various problems in the past, beyond only nested epoll usage. This patch (of 2): This incorporates the testcase originally reported in: https://bugzilla.kernel.org/show_bug.cgi?id=208943 Which ensures an event is reported to all threads blocked on the same epoll descriptor, otherwise only a single thread will receive the wakeup once the event become ready. Link: https://lkml.kernel.org/r/20210405231025.33829-1-dave@stgolabs.net Link: https://lkml.kernel.org/r/20210405231025.33829-2-dave@stgolabs.netSigned-off-by:
-
Christophe JAILLET authored
The devm_ variant of 'kcalloc()' and 'kmalloc_array()' are not tested Add the corresponding check. Link: https://lkml.kernel.org/r/205fc4847972fb6779abcc8818f39c14d1b45af1.1618595794.git.christophe.jaillet@wanadoo.frSigned-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Vincent Mailhol authored
__must_be_array, offsetof, sizeof_field and __stringify are all preprocessor macros and do not evaluate their arguments. As such, it is safe not to warn when arguments are being reused in those four sub-expressions. Exclude those so that they can pass checkpatch. Link: https://lkml.kernel.org/r/20210407105042.25380-1-mailhol.vincent@wanadoo.frSigned-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by:
-
Joe Perches authored
return sysfs_emit() uses should include a newline. Suggest adding a newline when one is missing. Add one using --fix too. Link: https://lkml.kernel.org/r/aa1819fa5faf786573df298e5e2e7d357ba7d4ad.camel@perches.comSigned-off-by:
-
Masahiro Yamada authored
compat_sys##name is declared twice, just one line below. With this removal SYSCALL_DEFINEx() (defined in <linux/syscalls.h>) and COMPAT_SYSCALL_DEFINEx() look symmetrical. Link: https://lkml.kernel.org/r/20210223114924.854794-1-masahiroy@kernel.orgSigned-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Randy Dunlap authored
Mark match_uint() as kernel-doc notation since it is already fully annotated as such. Use % prefix on constants in kernel-doc comments. Convert function return descriptions to use the "Return:" kernel-doc notation. Link: https://lkml.kernel.org/r/20210407034514.5651-1-rdunlap@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Alex Shi authored
Commit 52fbf113 ("lib/genalloc.c: fix allocation of aligned buffer from non-aligned chunk") added a new parameter 'start_addr' w/o description for it. That causes some doc compile warning: lib/genalloc.c:649: warning: Function parameter or member 'start_addr' not described in 'gen_pool_first_fit' lib/genalloc.c:667: warning: Function parameter or member 'start_addr' not described in 'gen_pool_first_fit_align' lib/genalloc.c:694: warning: Function parameter or member 'start_addr' not described in 'gen_pool_fixed_alloc' lib/genalloc.c:729: warning: Function parameter or member 'start_addr' not described in 'gen_pool_first_fit_order_align' lib/genalloc.c:752: warning: Function parameter or member 'start_addr' not described in 'gen_pool_best_fit' This fixes it by adding a parameter descriptions. Link: https://lkml.kernel.org/r/20210405132021.131231-1-alexs@kernel.orgSigned-off-by:
Alex Shi <alexs@kernel.org> Cc: Alexey Skidanov <alexey.skidanov@intel.com> Cc: Huang Shijie <sjhuang@iluvatar.ai> Cc: Alex Shi <alexs@kernel.org> Cc: Bhaskar Chowdhury <unixbhaskar@gmail.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Alex Shi authored
commit 3e8f399d ("writeback: rework wb_[dec|inc]_stat family of functions") add some function description of percpu_counter_add_batch. but the double '*' in comments means a kernel-doc format comment which isn't right. Since the whole file of lib/percpu_counter.c has no any other kernel-doc format comments, we'd better to remove this incomplete one to tame the kernel-doc warning: lib/percpu_counter.c:83: warning: Function parameter or member 'fbc' not described in 'percpu_counter_add_batch' lib/percpu_counter.c:83: warning: Function parameter or member 'amount' not described in 'percpu_counter_add_batch' lib/percpu_counter.c:83: warning: Function parameter or member 'batch' not described in 'percpu_counter_add_batch' Link: https://lkml.kernel.org/r/20210405135505.132446-1-alexs@kernel.orgSigned-off-by:
-
Zqiang authored
In RT system, the spin_lock will be replaced by sleepable rt_mutex lock, in __call_rcu(), disable interrupts before calling kasan_record_aux_stack(), will trigger this calltrace: BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:951 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 19, name: pgdatinit0 Call Trace: ___might_sleep.cold+0x1b2/0x1f1 rt_spin_lock+0x3b/0xb0 stack_depot_save+0x1b9/0x440 kasan_save_stack+0x32/0x40 kasan_record_aux_stack+0xa5/0xb0 __call_rcu+0x117/0x880 __exit_signal+0xafb/0x1180 release_task+0x1d6/0x480 exit_notify+0x303/0x750 do_exit+0x678/0xcf0 kthread+0x364/0x4f0 ret_from_fork+0x22/0x30 Replace spinlock with raw_spinlock. Link: https://lkml.kernel.org/r/20210329084009.27013-1-qiang.zhang@windriver.comSigned-off-by:Zqiang <qiang.zhang@windriver.com> Reported-by:
Andrew Halaney <ahalaney@redhat.com> Cc: Alexander Potapenko <glider@google.com> Cc: Gustavo A. R. Silva <gustavoars@kernel.org> Cc: Vijayanand Jitta <vjitta@codeaurora.org> Cc: Vinayak Menon <vinmenon@codeaurora.org> Cc: Yogesh Lal <ylal@codeaurora.org> Signed-off-by:
-
Richard Fitzgerald authored
crc8() does not change the data passed to it, so the pointer argument should be declared const. This avoids callers that receive const data having to cast it to a non-const pointer to call crc8(). Link: https://lkml.kernel.org/r/20210329122409.3291-1-rf@opensource.cirrus.comSigned-off-by:
Richard Fitzgerald <rf@opensource.cirrus.com> Acked-by:
-
