aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-08-24crash: move a few code bits to setup support of crash hotplugEric DeVolder5-233/+238
Patch series "crash: Kernel handling of CPU and memory hot un/plug", v28. Once the kdump service is loaded, if changes to CPUs or memory occur, either by hot un/plug or off/onlining, the crash elfcorehdr must also be updated. The elfcorehdr describes to kdump the CPUs and memory in the system, and any inaccuracies can result in a vmcore with missing CPU context or memory regions. The current solution utilizes udev to initiate an unload-then-reload of the kdump image (eg. kernel, initrd, boot_params, purgatory and elfcorehdr) by the userspace kexec utility. In the original post I outlined the significant performance problems related to offloading this activity to userspace. This patchset introduces a generic crash handler that registers with the CPU and memory notifiers. Upon CPU or memory changes, from either hot un/plug or off/onlining, this generic handler is invoked and performs important housekeeping, for example obtaining the appropriate lock, and then invokes an architecture specific handler to do the appropriate elfcorehdr update. Note the description in patch 'crash: change crash_prepare_elf64_headers() to for_each_possible_cpu()' and 'x86/crash: optimize CPU changes' that enables further optimizations related to CPU plug/unplug/online/offline performance of elfcorehdr updates. In the case of x86_64, the arch specific handler generates a new elfcorehdr, and overwrites the old one in memory; thus no involvement with userspace needed. To realize the benefits/test this patchset, one must make a couple of minor changes to userspace: - Prevent udev from updating kdump crash kernel on hot un/plug changes. Add the following as the first lines to the RHEL udev rule file /usr/lib/udev/rules.d/98-kexec.rules: # The kernel updates the crash elfcorehdr for CPU and memory changes SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end" SUBSYSTEM=="memory", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end" With this changeset applied, the two rules evaluate to false for CPU and memory change events and thus skip the userspace unload-then-reload of kdump. - Change to the kexec_file_load for loading the kdump kernel: Eg. on RHEL: in /usr/bin/kdumpctl, change to: standard_kexec_args="-p -d -s" which adds the -s to select kexec_file_load() syscall. This kernel patchset also supports kexec_load() with a modified kexec userspace utility. A working changeset to the kexec userspace utility is posted to the kexec-tools mailing list here: http://lists.infradead.org/pipermail/kexec/2023-May/027049.html To use the kexec-tools patch, apply, build and install kexec-tools, then change the kdumpctl's standard_kexec_args to replace the -s with --hotplug. The removal of -s reverts to the kexec_load syscall and the addition of --hotplug invokes the changes put forth in the kexec-tools patch. This patch (of 8): The crash hotplug support leans on the work for the kexec_file_load() syscall. To also support the kexec_load() syscall, a few bits of code need to be move outside of CONFIG_KEXEC_FILE. As such, these bits are moved out of kexec_file.c and into a common location crash_core.c. In addition, struct crash_mem and crash_notes were moved to new locales so that PROC_KCORE, which sets CRASH_CORE alone, builds correctly. No functionality change intended. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Eric DeVolder <[email protected]> Reviewed-by: Sourabh Jain <[email protected]> Acked-by: Hari Bathini <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Akhil Raj <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Boris Ostrovsky <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Dave Young <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Eric W. Biederman <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Mimi Zohar <[email protected]> Cc: Naveen N. Rao <[email protected]> Cc: Oscar Salvador <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Sean Christopherson <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Thomas Weißschuh <[email protected]> Cc: Valentin Schneider <[email protected]> Cc: Vivek Goyal <[email protected]> Cc: Vlastimil Babka <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21kstrtox: consistently use _tolower()Andy Shevchenko1-1/+1
We already use _tolower() in other places, so convert the one which open codes it. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21kill do_each_thread()Oleg Nesterov4-13/+6
Eric has pointed out that we still have 3 users of do_each_thread(). Change them to use for_each_process_thread() and kill this helper. There is a subtle change, after do_each_thread/while_each_thread g == t == &init_task, while after for_each_process_thread() they both point to nowhere, but this doesn't matter. > Why is for_each_process_thread() better than do_each_thread()? Say, for_each_process_thread() is rcu safe, do_each_thread() is not. And certainly for_each_process_thread(p, t) { do_something(p, t); } looks better than do_each_thread(p, t) { do_something(p, t); } while_each_thread(p, t); And again, there are only 3 users of this awkward helper left. It should have been killed years ago and in fact I thought it had already been killed. It uses while_each_thread() which needs some changes. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Oleg Nesterov <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: "Christian Brauner (Microsoft)" <[email protected]> Cc: Eric W. Biederman <[email protected]> Cc: Jiri Slaby <[email protected]> # tty/serial Signed-off-by: Andrew Morton <[email protected]>
2023-08-21nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuseRyusuke Konishi2-3/+7
A syzbot stress test using a corrupted disk image reported that mark_buffer_dirty() called from __nilfs_mark_inode_dirty() or nilfs_palloc_commit_alloc_entry() may output a kernel warning, and can panic if the kernel is booted with panic_on_warn. This is because nilfs2 keeps buffer pointers in local structures for some metadata and reuses them, but such buffers may be forcibly discarded by nilfs_clear_dirty_page() in some critical situations. This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only"), but the issue has potentially existed before. Fix this issue by checking the uptodate flag when attempting to reuse an internally held buffer, and reloading the metadata instead of reusing the buffer if the flag was lost. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi <[email protected]> Reported-by: [email protected] Closes: https://lkml.kernel.org/r/[email protected] Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") Tested-by: Ryusuke Konishi <[email protected]> Cc: <[email protected]> # 3.10+ Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/bloat-o-meter: count weak symbol sizesGeert Uytterhoeven1-5/+5
Currently, bloat-o-meter does not take into account weak symbols, and thus ignores any size changes in code or data marked __weak. Fix this by handling weak code ("w"/"W") and data ("v"/"V"). Link: https://lkml.kernel.org/r/a1e7abd2571c3bbfe75345d6ee98b276d2d5c39d.1692200010.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21treewide: drop CONFIG_EMBEDDEDRandy Dunlap78-85/+76
There is only one Kconfig user of CONFIG_EMBEDDED and it can be switched to EXPERT or "if !ARCH_MULTIPLATFORM" (suggested by Arnd). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Acked-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Acked-by: Palmer Dabbelt <[email protected]> [RISC-V] Acked-by: Greg Ungerer <[email protected]> Acked-by: Jason A. Donenfeld <[email protected]> Acked-by: Michael Ellerman <[email protected]> [powerpc] Cc: Russell King <[email protected]> Cc: Vineet Gupta <[email protected]> Cc: Brian Cain <[email protected]> Cc: Michal Simek <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: Dinh Nguyen <[email protected]> Cc: Jonas Bonn <[email protected]> Cc: Stefan Kristiansson <[email protected]> Cc: Stafford Horne <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Albert Ou <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Rich Felker <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: Max Filippov <[email protected]> Cc: Josh Triplett <[email protected]> Cc: Masahiro Yamada <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21lockdep: fix static memory detection even moreHelge Deller2-40/+14
On the parisc architecture, lockdep reports for all static objects which are in the __initdata section (e.g. "setup_done" in devtmpfs, "kthreadd_done" in init/main.c) this warning: INFO: trying to register non-static key. The warning itself is wrong, because those objects are in the __initdata section, but the section itself is on parisc outside of range from _stext to _end, which is why the static_obj() functions returns a wrong answer. While fixing this issue, I noticed that the whole existing check can be simplified a lot. Instead of checking against the _stext and _end symbols (which include code areas too) just check for the .data and .bss segments (since we check a data object). This can be done with the existing is_kernel_core_data() macro. In addition objects in the __initdata section can be checked with init_section_contains(), and is_kernel_rodata() allows keys to be in the _ro_after_init section. This partly reverts and simplifies commit bac59d18c701 ("x86/setup: Fix static memory detection"). Link: https://lkml.kernel.org/r/ZNqrLRaOi/3wPAdp@p100 Fixes: bac59d18c701 ("x86/setup: Fix static memory detection") Signed-off-by: Helge Deller <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21lib/vsprintf: declare no_hash_pointers in sprintf.hAndy Shevchenko3-4/+3
Sparse is not happy to see non-static variable without declaration: lib/vsprintf.c:61:6: warning: symbol 'no_hash_pointers' was not declared. Should it be static? Declare respective variable in the sprintf.h. With this, add a comment to discourage its use if no real need. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Marco Elver <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Steven Rostedt (Google) <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21lib/vsprintf: split out sprintf() and friendsAndy Shevchenko4-29/+28
Patch series "lib/vsprintf: Rework header inclusions", v3. Some patches that reduce the mess with the header inclusions related to vsprintf.c module. Each patch has its own description, and has no dependencies to each other, except the collisions over modifications of the same places. Hence the series. This patch (of 2): kernel.h is being used as a dump for all kinds of stuff for a long time. sprintf() and friends are used in many drivers without need of the full kernel.h dependency train with it. Here is the attempt on cleaning it up by splitting out sprintf() and friends. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Marco Elver <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Steven Rostedt (Google) <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21kernel/fork: stop playing lockless games for exe_file replacementMateusz Guzik2-15/+11
xchg originated in 6e399cd144d8 ("prctl: avoid using mmap_sem for exe_file serialization"). While the commit message does not explain *why* the change, I found the original submission [1] which ultimately claims it cleans things up by removing dependency of exe_file on the semaphore. However, fe69d560b5bd ("kernel/fork: always deny write access to current MM exe_file") added a semaphore up/down cycle to synchronize the state of exe_file against fork, defeating the point of the original change. This is on top of semaphore trips already present both in the replacing function and prctl (the only consumer). Normally replacing exe_file does not happen for busy processes, thus write-locking is not an impediment to performance in the intended use case. If someone keeps invoking the routine for a busy processes they are trying to play dirty and that's another reason to avoid any trickery. As such I think the atomic here only adds complexity for no benefit. Just write-lock around the replacement. I also note that replacement races against the mapping check loop as nothing synchronizes actual assignment with with said checks but I am not addressing it in this patch. (Is the loop of any use to begin with?) Link: https://lore.kernel.org/linux-mm/[email protected]/ [1] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Mateusz Guzik <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Acked-by: David Hildenbrand <[email protected]> Cc: "Christian Brauner (Microsoft)" <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Eric W. Biederman <[email protected]> Cc: Konstantin Khlebnikov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Mateusz Guzik <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21adfs: delete unused "union adfs_dirtail" definitionAlexey Dobriyan1-5/+0
union adfs_dirtail::new stands in the way if Linux++ project: "new" can't be used as member's name because it is a keyword in C++. Link: https://lkml.kernel.org/r/43b0a4c8-a7cf-4ab1-98f7-0f65c096f9e8@p183 Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/vmalloc: add vmallocinfo supportKuan-Ying Lee3-0/+65
This GDB script shows the vmallocinfo for user to analyze the vmalloc memory usage. Example output: 0xffff800008000000-0xffff800008009000 36864 <start_kernel+372> pages=8 vmalloc 0xffff800008009000-0xffff80000800b000 8192 <gicv2m_init_one+400> phys=0x8020000 ioremap 0xffff80000800b000-0xffff80000800d000 8192 <bpf_prog_alloc_no_stats+72> pages=1 vmalloc 0xffff80000800d000-0xffff80000800f000 8192 <bpf_jit_alloc_exec+16> pages=1 vmalloc 0xffff800008010000-0xffff80000ad30000 47316992 <paging_init+452> phys=0x40210000 vmap 0xffff80000ad30000-0xffff80000c1c0000 21561344 <paging_init+556> phys=0x42f30000 vmap 0xffff80000c1c0000-0xffff80000c370000 1769472 <paging_init+592> phys=0x443c0000 vmap 0xffff80000c370000-0xffff80000de90000 28442624 <paging_init+692> phys=0x44570000 vmap 0xffff80000de90000-0xffff80000f4c1000 23269376 <paging_init+788> phys=0x46090000 vmap 0xffff80000f4c1000-0xffff80000f4c3000 8192 <gen_pool_add_owner+112> pages=1 vmalloc 0xffff80000f4c3000-0xffff80000f4c5000 8192 <gen_pool_add_owner+112> pages=1 vmalloc 0xffff80000f4c5000-0xffff80000f4c7000 8192 <gen_pool_add_owner+112> pages=1 vmalloc Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/slab: add slab supportKuan-Ying Lee3-0/+340
Add 'lx-slabinfo' and 'lx-slabtrace' support. This GDB scripts print slabinfo and slabtrace for user to analyze slab memory usage. Example output like below: (gdb) lx-slabinfo Pointer | name | active_objs | num_objs | objsize | objperslab | pagesperslab ------------------ | -------------------- | ------------ | ------------ | -------- | ----------- | ------------- 0xffff0000c59df480 | p9_req_t | 0 | 0 | 280 | 29 | 2 0xffff0000c59df280 | isp1760_qh | 0 | 0 | 160 | 25 | 1 0xffff0000c59df080 | isp1760_qtd | 0 | 0 | 184 | 22 | 1 0xffff0000c59dee80 | isp1760_urb_listite | 0 | 0 | 136 | 30 | 1 0xffff0000c59dec80 | asd_sas_event | 0 | 0 | 256 | 32 | 2 0xffff0000c59dea80 | sas_task | 0 | 0 | 448 | 36 | 4 0xffff0000c59de880 | bio-120 | 18 | 21 | 384 | 21 | 2 0xffff0000c59de680 | io_kiocb | 0 | 0 | 448 | 36 | 4 0xffff0000c59de480 | bfq_io_cq | 0 | 0 | 1504 | 21 | 8 0xffff0000c59de280 | bfq_queue | 0 | 0 | 720 | 22 | 4 0xffff0000c59de080 | mqueue_inode_cache | 1 | 28 | 1152 | 28 | 8 0xffff0000c59dde80 | v9fs_inode_cache | 0 | 0 | 832 | 39 | 8 ... (gdb) lx-slabtrace --cache_name kmalloc-1k 63 <tty_register_device_attr+508> waste=16632/264 age=46856/46871/46888 pid=1 cpus=6, 0xffff800008720240 <__kmem_cache_alloc_node+236>: mov x22, x0 0xffff80000862a4fc <kmalloc_trace+64>: mov x21, x0 0xffff8000095d086c <tty_register_device_attr+508>: mov x19, x0 0xffff8000095d0f98 <tty_register_driver+704>: cmn x0, #0x1, lsl #12 0xffff80000c2677e8 <vty_init+620>: Cannot access memory at address 0xffff80000c2677e8 0xffff80000c265a10 <tty_init+276>: Cannot access memory at address 0xffff80000c265a10 0xffff80000c26d3c4 <chr_dev_init+204>: Cannot access memory at address 0xffff80000c26d3c4 0xffff8000080161d4 <do_one_initcall+176>: mov w21, w0 0xffff80000c1c1b58 <kernel_init_freeable+956>: Cannot access memory at address 0xffff80000c1c1b58 0xffff80000acf1334 <kernel_init+36>: bl 0xffff8000081ac040 <async_synchronize_full> 0xffff800008018d00 <ret_from_fork+16>: mrs x28, sp_el0 (gdb) lx-slabtrace --cache_name kmalloc-1k --free 428 <not-available> age=4294958600 pid=0 cpus=0, Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/page_owner: add page owner supportKuan-Ying Lee3-0/+198
This GDB script prints page owner information for user to analyze the memory usage or memory corruption issue. Example output from an aarch64 system: (gdb) lx-dump-page-owner --pfn 655360 page_owner tracks the page as allocated Page last allocated via order 0, gfp_mask: 0x8, pid: 1, tgid: 1 ("swapper/0\000\000\000\000\000\000"), ts 1295948880 ns, free_ts 1011852016 ns PFN: 655360, Flags: 0x3fffc0000000000 0xffff8000086ab964 <post_alloc_hook+452>: ldp x19, x20, [sp, #16] 0xffff80000862e4e0 <split_map_pages+344>: cbnz w22, 0xffff80000862e57c <split_map_pages+500> 0xffff8000086370c4 <isolate_freepages_range+556>: mov x0, x27 0xffff8000086bc1cc <alloc_contig_range+808>: mov x24, x0 0xffff80000877d6d8 <cma_alloc+772>: mov w1, w0 0xffff8000082c8d18 <dma_alloc_from_contiguous+104>: ldr x19, [sp, #16] 0xffff8000082ce0e8 <atomic_pool_expand+208>: mov x19, x0 0xffff80000c1e41b4 <__dma_atomic_pool_init+172>: Cannot access memory at address 0xffff80000c1e41b4 0xffff80000c1e4298 <dma_atomic_pool_init+92>: Cannot access memory at address 0xffff80000c1e4298 0xffff8000080161d4 <do_one_initcall+176>: mov w21, w0 0xffff80000c1c1b50 <kernel_init_freeable+952>: Cannot access memory at address 0xffff80000c1c1b50 0xffff80000acf87dc <kernel_init+36>: bl 0xffff8000081ab100 <async_synchronize_full> 0xffff800008018d00 <ret_from_fork+16>: mrs x28, sp_el0 page last free stack trace: 0xffff8000086a6e8c <free_unref_page_prepare+796>: mov w2, w23 0xffff8000086aee1c <free_unref_page+96>: tst w0, #0xff 0xffff8000086af3f8 <__free_pages+292>: ldp x19, x20, [sp, #16] 0xffff80000c1f3214 <init_cma_reserved_pageblock+220>: Cannot access memory at address 0xffff80000c1f3214 0xffff80000c20363c <cma_init_reserved_areas+1284>: Cannot access memory at address 0xffff80000c20363c 0xffff8000080161d4 <do_one_initcall+176>: mov w21, w0 0xffff80000c1c1b50 <kernel_init_freeable+952>: Cannot access memory at address 0xffff80000c1c1b50 0xffff80000acf87dc <kernel_init+36>: bl 0xffff8000081ab100 <async_synchronize_full> 0xffff800008018d00 <ret_from_fork+16>: mrs x28, sp_el0 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/stackdepot: add stackdepot supportKuan-Ying Lee3-0/+57
Add support for printing the backtrace of stackdepot handle. This is the preparation patch for dumping page_owner, slabtrace usage. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/aarch64: add aarch64 page operation helper commands and configsKuan-Ying Lee4-204/+626
1. Move page table debugging from mm.py to pgtable.py. 2. Add aarch64 kernel config and memory constants value. 3. Add below aarch64 page operation helper commands. page_to_pfn, page_to_phys, pfn_to_page, page_address, virt_to_phys, sym_to_pfn, pfn_to_kaddr, virt_to_page. 4. Only support CONFIG_SPARSEMEM_VMEMMAP=y now. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/utils: add common type usageKuan-Ying Lee1-0/+20
Since we often use 'unsigned long', 'size_t', 'usigned int' and 'struct page', we add these common types to utils. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/modules: add get module text supportKuan-Ying Lee1-1/+31
When we get an text address from coredump and we cannot find this address in vmlinux, it might located in kernel module. We want to know which kernel module it located in. This GDB scripts can help us to find the target kernel module. (gdb) lx-getmod-by-textaddr 0xffff800002d305ac 0xffff800002d305ac is in kasan_test.ko Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21scripts/gdb/symbols: add specific ko module load commandKuan-Ying Lee1-2/+21
Patch series "Add GDB memory helper commands", v2. I've created some GDB commands I think useful when I debug some memory issues and kernel module issue. For memory issue, we would like to get slabinfo, slabtrace, page_owner and vmallocinfo to debug the memory issues. For module issue, we would like to query kernel module name when we get a module text address and load module symbol by specific path. Patch 1-2: - Add kernel module related command. Patch 3-5: - Prepares for the memory-related command. Patch 6-8: - Add memory-related commands. This patch (of 8): Add lx-symbols <ko_path> command to support add specific ko module. Example output like below: (gdb) lx-symbols mm/kasan/kasan_test.ko loading @0xffff800002d30000: mm/kasan/kasan_test.ko Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kuan-Ying Lee <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21checkpatch: reword long-line warning about commit-msgJim Cromie1-1/+1
Reword the warning to complain about line length 1st, since thats whats actually tested. Link: https://lkml.kernel.org/r/[email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Jim Cromie <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-21checkpatch: special case extern struct in .cJim Cromie1-0/+20
"externs should be avoided in .c files" needs an exception for linker symbols, like those that mark the start, stop of many kernel sections. Since checkpatch already checks REALNAME to avoid looking at fragments changing vmlinux.lds.h, add a new else-if block to look at them instead. As a simple heuristic, treat all words (in the patch-line) as possible symbols, to screen later warnings. For my test case, the possible-symbols included BOUNDED_BY (a macro), which is extra, but not troublesome - these are just to screen WARNINGS that might be issued on later fragments (changing .c files) Where the WARN is issued, precede it with an else-if block to catch one common extern-in-c use case: "extern struct foo bar[]". Here we can at least issue a softer warning, after checking for a match with a maybe-linker-symbol parsed earlier from the patch. Though heuristic, it worked for my test-case, allowing both start__, stop__ $symbol's (wo the prefixes specifically named). I've coded it narrowly, it can be expanded later to cover any other expressions. It does require that the externs in .c's have the additions to vmlinux.lds.h in the same patch. And requires vmlinux.lds.h before .c fragments. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Jim Cromie <[email protected]> Cc: Joe Perches <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18x86/kernel: increase kcov coverage under arch/x86/kernel folderPengfei Xu1-5/+4
Currently kcov instrument is disabled for object files under arch/x86/kernel folder. For object files under arch/x86/kernel, actually just disabling the kcov instrument of files:"head32.o or head64.o and sev.o" could achieve successful booting and provide kcov coverage for object files that do not disable kcov instrument. The additional kcov coverage collected from arch/x86/kernel folder helps kernel fuzzing efforts to find bugs. Link to related improvement discussion is below: https://groups.google.com/g/syzkaller/c/Dsl-RYGCqs8/m/x-tfpTyFBAAJ Related ticket is as follow: https://bugzilla.kernel.org/show_bug.cgi?id=198443 Link: https://lkml.kernel.org/r/06c0bb7b5f61e5884bf31180e8c122648c752010.1690771380.git.pengfei.xu@intel.com Reviewed-by: Dmitry Vyukov <[email protected]> Tested-by: Dmitry Vyukov <[email protected]> Signed-off-by: Pengfei Xu <[email protected]> Cc: Aleksandr Nogikh <[email protected]> Cc: <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Kees Cook <[email protected]>, Cc: Kirill A. Shutemov <[email protected]> Cc: Sohil Mehta <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18fs: ocfs2: namei: check return value of ocfs2_add_entry()Artem Chernyshev1-0/+4
Process result of ocfs2_add_entry() in case we have an error value. Found by Linux Verification Center (linuxtesting.org) with SVACE. Link: https://lkml.kernel.org/r/[email protected] Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Artem Chernyshev <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Artem Chernyshev <[email protected]> Cc: Joel Becker <[email protected]> Cc: Kurt Hackel <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18watchdog/hardlockup: avoid large stack frames in watchdog_hardlockup_check()Douglas Anderson1-7/+2
After commit 77c12fc95980 ("watchdog/hardlockup: add a "cpu" param to watchdog_hardlockup_check()") we started storing a `struct cpumask` on the stack in watchdog_hardlockup_check(). On systems with CONFIG_NR_CPUS set to 8192 this takes up 1K on the stack. That triggers warnings with `CONFIG_FRAME_WARN` set to 1024. We'll use the new trigger_allbutcpu_cpu_backtrace() to avoid needing to use a CPU mask at all. Link: https://lkml.kernel.org/r/20230804065935.v4.2.I501ab68cb926ee33a7c87e063d207abf09b9943c@changeid Fixes: 77c12fc95980 ("watchdog/hardlockup: add a "cpu" param to watchdog_hardlockup_check()") Signed-off-by: Douglas Anderson <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Acked-by: Michal Hocko <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Cc: Lecopzer Chen <[email protected]> Cc: Pingfan Liu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18nmi_backtrace: allow excluding an arbitrary CPUDouglas Anderson16-32/+32
The APIs that allow backtracing across CPUs have always had a way to exclude the current CPU. This convenience means callers didn't need to find a place to allocate a CPU mask just to handle the common case. Let's extend the API to take a CPU ID to exclude instead of just a boolean. This isn't any more complex for the API to handle and allows the hardlockup detector to exclude a different CPU (the one it already did a trace for) without needing to find space for a CPU mask. Arguably, this new API also encourages safer behavior. Specifically if the caller wants to avoid tracing the current CPU (maybe because they already traced the current CPU) this makes it more obvious to the caller that they need to make sure that the current CPU ID can't change. [[email protected]: fix trigger_allbutcpu_cpu_backtrace() stub] Link: https://lkml.kernel.org/r/20230804065935.v4.1.Ia35521b91fc781368945161d7b28538f9996c182@changeid Signed-off-by: Douglas Anderson <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: kernel test robot <[email protected]> Cc: Lecopzer Chen <[email protected]> Cc: Petr Mladek <[email protected]> Cc: Pingfan Liu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18range.h: Move resource API and constant to respective filesAndy Shevchenko5-10/+12
range.h works with struct range data type. The resource_size_t is an alien here. (1) Move cap_resource() implementation into its only user, and (2) rename and move RESOURCE_SIZE_MAX to limits.h. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Cc: Alexander Sverdlin <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Dave Hansen <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18kthread: unexport __kthread_should_park()Greg Kroah-Hartman2-3/+1
There are no in-kernel users of __kthread_should_park() so mark it as static and do not export it. Link: https://lkml.kernel.org/r/2023080450-handcuff-stump-1d6e@gregkh Signed-off-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: John Stultz <[email protected]> Cc: "Peter Zijlstra (Intel)" <[email protected]> Cc: "Arve Hjønnevåg" <[email protected]> Cc: Valentin Schneider <[email protected]> Cc: Andrew Morton <[email protected]> Cc: "Christian Brauner (Microsoft)" <[email protected]> Cc: Mike Christie <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Zqiang <[email protected]> Cc: Prathu Baronia <[email protected]> Cc: Sami Tolvanen <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18efs: clean up -Wunused-const-variable= warningZhu Wang1-4/+1
When building with W=1, the following warning occurs. In file included from fs/efs/super.c:18:0: fs/efs/efs.h:22:19: warning: `cprt' defined but not used [-Wunused-const-variable=] static const char cprt[] = "EFS: "EFS_VERSION" - (c) 1999 Al Smith <[email protected]>"; ^~~~ The 'cprt' is not used in any files, we move the copyright statement into the comment. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Zhu Wang <[email protected]> Cc: Al Smith <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18drm/i915: Move abs_diff() to math.hAndy Shevchenko6-27/+29
abs_diff() belongs to math.h. Move it there. This will allow others to use it. [[email protected]: add abs_diff() documentation] Link: https://lkml.kernel.org/r/[email protected] [[email protected]: fix comment, per Randy] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> # tty/serial Acked-by: Jani Nikula <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> # gpu/ipu-v3 Cc: Alexey Dobriyan <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: David Airlie <[email protected]> Cc: Helge Deller <[email protected]> Cc: Imre Deak <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18ocfs2: cluster: fix potential deadlock on &o2net_debug_lockChengfeng Ye1-20/+20
&o2net_debug_lock is acquired by timer o2net_idle_timer() along the following call chain. Thus the acquisition of the lock under process context should disable bottom half, otherwise deadlock could happen if the timer happens to preempt the execution while the lock is held in process context on the same CPU. <timer interrupt> -> o2net_idle_timer() -> queue_delayed_work() -> sc_put() -> sc_kref_release() -> o2net_debug_del_sc() -> spin_lock(&o2net_debug_lock); Several lock acquisition of &o2net_debug_lock under process context do not disable irq or bottom half. The patch fixes these potential deadlocks scenerio by using spin_lock_bh() on &o2net_debug_lock. This flaw was found by an experimental static analysis tool I am developing for irq-related deadlock. x86_64 allmodconfig using gcc shows no new warning. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Chengfeng Ye <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Joseph Qi <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18ocfs2: cluster: fix potential deadlock on &qs->qs_lockChengfeng Ye1-13/+13
&qs->qs_lock is acquired by timer o2net_idle_timer() along the following call chain. Thus the acquisition of the lock under process context should disable bottom half, otherwise deadlock could happen if the timer happens to preempt the execution while the lock is held in process context on the same CPU. <timer interrupt> -> o2net_idle_timer() -> o2quo_conn_err() -> spin_lock(&qs->qs_lock) Several lock acquisition of &qs->qs_lock under process contex do not disable irq or bottom half. The patch fixes these potential deadlocks scenerio by using spin_lock_bh() on &qs->qs_lock. This flaw was found by an experimental static analysis tool I am developing for irq-related deadlock. x86_64 allmodconfig using gcc shows no new warning. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Chengfeng Ye <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Joseph Qi <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18scripts/gdb: fix 'lx-lsmod' show the wrong sizeKuan-Ying Lee2-3/+12
'lsmod' shows total core layout size, so we need to sum up all the sections in core layout in gdb scripts. / # lsmod kasan_test 200704 0 - Live 0xffff80007f640000 Before patch: (gdb) lx-lsmod Address Module Size Used by 0xffff80007f640000 kasan_test 36864 0 After patch: (gdb) lx-lsmod Address Module Size Used by 0xffff80007f640000 kasan_test 200704 0 Link: https://lkml.kernel.org/r/[email protected] Fixes: b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") Signed-off-by: Kuan-Ying Lee <[email protected]> Reviewed-by: Pankaj Raghav <[email protected]> Cc: AngeloGioacchino Del Regno <[email protected]> Cc: Chinwen Chang <[email protected]> Cc: Jan Kiszka <[email protected]> Cc: Kieran Bingham <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: Matthias Brugger <[email protected]> Cc: Qun-Wei Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18lib/bch.c: use bitrev instead of internal logicJohn Sanpe2-36/+3
Replace internal logic with separate bitrev library. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: John Sanpe <[email protected]> Cc: Bhaskar Chowdhury <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18scripts/gdb: fix lx-symbols command for arm64 LLVMKoudai Iwahori1-7/+10
lx-symbols assumes that module's .text sections is located at `module->mem[MOD_TEXT].base` and passes it to add-symbol-file command. However, .text section follows after .plt section in modules built by LLVM toolchain for arm64 target. Symbol addresses are skewed in GDB. Fix this issue by using the address of .text section stored in `module->sect_attrs`. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Koudai Iwahori <[email protected]> Cc: Jan Kiszka <[email protected]> Cc: Kieran Bingham <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18gcov: shut up missing prototype warnings for internal stubsArnd Bergmann1-0/+2
gcov uses global functions that are called from generated code, but these have no prototype in a header, which causes a W=1 build warning: kernel/gcov/gcc_base.c:12:6: error: no previous prototype for '__gcov_init' [-Werror=missing-prototypes] kernel/gcov/gcc_base.c:40:6: error: no previous prototype for '__gcov_flush' [-Werror=missing-prototypes] kernel/gcov/gcc_base.c:46:6: error: no previous prototype for '__gcov_merge_add' [-Werror=missing-prototypes] kernel/gcov/gcc_base.c:52:6: error: no previous prototype for '__gcov_merge_single' [-Werror=missing-prototypes] Just turn off these warnings unconditionally for the two files that contain them. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]> Tested-by: Peter Oberparleiter <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18ocfs2: use regular seq_show_option for osb_cluster_stackKees Cook1-2/+1
While cleaning up seq_show_option_n()'s use of strncpy, it was noticed that the osb_cluster_stack member is always NUL-terminated, so there is no need to use the special seq_show_option_n() routine. Replace it with the standard seq_show_option() routine. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18ocfs2: Use struct_size()Christophe JAILLET1-3/+3
Use struct_size() instead of hand-writing it, when allocating a structure with a flex array. This is less verbose. Link: https://lkml.kernel.org/r/9d99ea2090739f816d0dc0c4ebaa42b26fc48a9e.1689533270.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18ocfs2: use flexible array in 'struct ocfs2_recovery_map'Christophe JAILLET2-5/+2
Turn 'rm_entries' in 'struct ocfs2_recovery_map' into a flexible array. The advantages are: - save the size of a pointer when the new undo structure is allocated - avoid some always ugly pointer arithmetic to get the address of 'rm_entries' - avoid an indirection when the array is accessed While at it, use struct_size() to compute the size of the new undo structure. Link: https://lkml.kernel.org/r/c645911ffd2720fce5e344c17de642518cd0db52.1689533270.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18genetlink: replace custom CONCATENATE() implementationAndy Shevchenko2-18/+17
Replace custom implementation of the macros from args.h. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Brendan Higgins <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Daniel Latypov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Gow <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Masami Hiramatsu (Google) <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Steven Rostedt (Google) <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18arm64: smccc: replace custom COUNT_ARGS() & CONCATENATE() implementationsAndy Shevchenko1-37/+32
Replace custom implementation of the macros from args.h. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Brendan Higgins <[email protected]> Cc: Daniel Latypov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Gow <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Masami Hiramatsu (Google) <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Steven Rostedt (Google) <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18x86/asm: replace custom COUNT_ARGS() & CONCATENATE() implementationsAndy Shevchenko1-8/+3
Replace custom implementation of the macros from args.h. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Borislav Petkov (AMD) <[email protected]> Cc: Brendan Higgins <[email protected]> Cc: Daniel Latypov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Gow <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Masami Hiramatsu (Google) <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Steven Rostedt (Google) <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18kernel.h: split out COUNT_ARGS() and CONCATENATE() to args.hAndy Shevchenko5-8/+32
Patch series "kernel.h: Split out a couple of macros to args.h", v4. There are macros in kernel.h that can be used outside of that header. Split them to args.h and replace open coded variants. This patch (of 4): kernel.h is being used as a dump for all kinds of stuff for a long time. The COUNT_ARGS() and CONCATENATE() macros may be used in some places without need of the full kernel.h dependency train with it. Here is the attempt on cleaning it up by splitting out these macros(). While at it, include new header where it's being used. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Steven Rostedt (Google) <[email protected]> Cc: Bjorn Helgaas <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> [PCI] Cc: Brendan Higgins <[email protected]> Cc: Daniel Latypov <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Gow <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Masami Hiramatsu (Google) <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18arch: enable HAS_LTO_CLANG with KASAN and KCOVJakob Koschel1-1/+3
Both KASAN and KCOV had issues with LTO_CLANG if DEBUG_INFO is enabled. With LTO inlinable function calls are required to have debug info if they are inlined into a function that has debug info. Starting with LLVM 17 this will be fixed ([1],[2]) and enabling LTO with KASAN/KCOV and DEBUG_INFO doesn't cause linker errors anymore. Link: https://github.com/llvm/llvm-project/commit/913f7e93dac67ecff47bade862ba42f27cb68ca9 Link: https://github.com/llvm/llvm-project/commit/4a8b1249306ff11f229320abdeadf0c215a00400 Link: https://lkml.kernel.org/r/[email protected] Reviewed-by: Nathan Chancellor <[email protected]> Signed-off-by: Jakob Koschel <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Cc: Kees Cook <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Tom Rix <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18fs: hfsplus: make extend error rate limitedColin Ian King1-3/+3
Extending a file where there is not enough free space can trigger frequent extend alloc file error messages and this can easily spam the kernel log. Make the error message rate limited. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Colin Ian King <[email protected]> Cc: Christian Brauner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18lib: error-inject: remove error checking for debugfs_create_dir()Wang Ming1-2/+0
It is expected that most callers should _ignore_ the errors return by debugfs_create_dir() in ei_debugfs_init(). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Wang Ming <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18lib: remove error checking for debugfs_create_dir()Wang Ming1-3/+0
It is expected that most callers should _ignore_ the errors return by debugfs_create_dir() in err_inject_init(). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Wang Ming <[email protected]> Cc: Akinobu Mita <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18kernel: relay: remove unnecessary NULL values from relay_open_bufLi kunyu1-1/+1
buf is assigned first, so it does not need to initialize the assignment. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Li kunyu <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18remove ARCH_DEFAULT_KEXEC from Kconfig.kexecEric DeVolder2-4/+0
This patch is a minor cleanup to the series "refactor Kconfig to consolidate KEXEC and CRASH options". In that series, a new option ARCH_DEFAULT_KEXEC was introduced in order to obtain the equivalent behavior of s390 original Kconfig settings for KEXEC. As it turns out, this new option did not fully provide the equivalent behavior, rather a "select KEXEC" did. As such, the ARCH_DEFAULT_KEXEC is not needed anymore, so remove it. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Eric DeVolder <[email protected]> Acked-by: Alexander Gordeev <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18kexec: rename ARCH_HAS_KEXEC_PURGATORYEric DeVolder8-11/+11
The Kconfig refactor to consolidate KEXEC and CRASH options utilized option names of the form ARCH_SUPPORTS_<option>. Thus rename the ARCH_HAS_KEXEC_PURGATORY to ARCH_SUPPORTS_KEXEC_PURGATORY to follow the same. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Eric DeVolder <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18sh/kexec: refactor for kernel/Kconfig.kexecEric DeVolder1-38/+8
The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Eric DeVolder <[email protected]> Acked-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.