- 21 Aug, 2023 15 commits
-
-
Helge Deller authored
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 bac59d18 ("x86/setup: Fix static memory detection"). Link: https://lkml.kernel.org/r/ZNqrLRaOi/3wPAdp@p100 Fixes: bac59d18 ("x86/setup: Fix static memory detection") Signed-off-by:
Helge Deller <deller@gmx.de> Cc: Borislav Petkov <bp@suse.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Andy Shevchenko authored
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/20230814163344.17429-3-andriy.shevchenko@linux.intel.comSigned-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Marco Elver <elver@google.com> Reviewed-by:
Petr Mladek <pmladek@suse.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by:
-
Andy Shevchenko authored
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/20230814163344.17429-1-andriy.shevchenko@linux.intel.com Link: https://lkml.kernel.org/r/20230814163344.17429-2-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Mateusz Guzik authored
xchg originated in 6e399cd1 ("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, fe69d560 ("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/1424979417.10344.14.camel@stgolabs.net/ [1] Link: https://lkml.kernel.org/r/20230814172140.1777161-1-mjguzik@gmail.comSigned-off-by:
Mateusz Guzik <mjguzik@gmail.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Acked-by:
David Hildenbrand <david@redhat.com> Cc: "Christian Brauner (Microsoft)" <brauner@kernel.org> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mateusz Guzik <mjguzik@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
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@p183Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Kuan-Ying Lee authored
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/20230808083020.22254-9-Kuan-Ying.Lee@mediatek.comSigned-off-by:
Kuan-Ying Lee <Kuan-Ying.Lee@mediatek.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Chinwen Chang <chinwen.chang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Qun-Wei Lin <qun-wei.lin@mediatek.com> Signed-off-by:
-
Kuan-Ying Lee authored
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/20230808083020.22254-8-Kuan-Ying.Lee@mediatek.comSigned-off-by: -
Kuan-Ying Lee authored
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/20230808083020.22254-7-Kuan-Ying.Lee@mediatek.comSigned-off-by: -
Kuan-Ying Lee authored
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/20230808083020.22254-6-Kuan-Ying.Lee@mediatek.comSigned-off-by:
-
Kuan-Ying Lee authored
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/20230808083020.22254-5-Kuan-Ying.Lee@mediatek.comSigned-off-by:
-
Kuan-Ying Lee authored
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/20230808083020.22254-4-Kuan-Ying.Lee@mediatek.comSigned-off-by:
-
Kuan-Ying Lee authored
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/20230808083020.22254-3-Kuan-Ying.Lee@mediatek.comSigned-off-by:
-
Kuan-Ying Lee authored
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/20230808083020.22254-1-Kuan-Ying.Lee@mediatek.com Link: https://lkml.kernel.org/r/20230808083020.22254-2-Kuan-Ying.Lee@mediatek.comSigned-off-by:
-
Jim Cromie authored
Reword the warning to complain about line length 1st, since thats whats actually tested. Link: https://lkml.kernel.org/r/20230808033019.21911-3-jim.cromie@gmail.com Cc: apw@canonical.com Cc: joe@perches.com Signed-off-by:
Jim Cromie <jim.cromie@gmail.com> Signed-off-by:
-
Jim Cromie authored
"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/20230808033019.21911-2-jim.cromie@gmail.comSigned-off-by:
-
- 18 Aug, 2023 25 commits
-
-
Pengfei Xu authored
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.comReviewed-by:
Dmitry Vyukov <dvyukov@google.com> Tested-by:
Pengfei Xu <pengfei.xu@intel.com> Cc: Aleksandr Nogikh <nogikh@google.com> Cc: <heng.su@intel.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Kees Cook <keescook@google.com>, Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Sohil Mehta <sohil.mehta@intel.com> Signed-off-by:
-
Artem Chernyshev authored
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/20230803145417.177649-1-artem.chernyshev@red-soft.ru Fixes: ccd979bd ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by:
Artem Chernyshev <artem.chernyshev@red-soft.ru> Reviewed-by:
Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Artem Chernyshev <artem.chernyshev@red-soft.ru> Cc: Joel Becker <jlbec@evilplan.org> Cc: Kurt Hackel <kurt.hackel@oracle.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by:
-
Douglas Anderson authored
After commit 77c12fc9 ("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: 77c12fc9 ("watchdog/hardlockup: add a "cpu" param to watchdog_hardlockup_check()") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/r/202307310955.pLZDhpnl-lkp@intel.comAcked-by:
Michal Hocko <mhocko@suse.com> Reviewed-by:
-
Douglas Anderson authored
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. [akpm@linux-foundation.org: fix trigger_allbutcpu_cpu_backtrace() stub] Link: https://lkml.kernel.org/r/20230804065935.v4.1.Ia35521b91fc781368945161d7b28538f9996c182@changeidSigned-off-by:
-
Andy Shevchenko authored
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/20230804064636.15368-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Greg Kroah-Hartman authored
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@gregkhSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: John Stultz <jstultz@google.com> Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org> Cc: "Arve Hjønnevåg" <arve@android.com> Cc: Valentin Schneider <vschneid@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Christian Brauner (Microsoft)" <brauner@kernel.org> Cc: Mike Christie <michael.christie@oracle.com> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Zqiang <qiang1.zhang@intel.com> Cc: Prathu Baronia <quic_pbaronia@quicinc.com> Cc: Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
-
Zhu Wang authored
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 <Al.Smith@aeschi.ch.eu.org>"; ^~~~ The 'cprt' is not used in any files, we move the copyright statement into the comment. Link: https://lkml.kernel.org/r/20230803015103.192985-1-wangzhu9@huawei.comSigned-off-by:Zhu Wang <wangzhu9@huawei.com> Cc: Al Smith <Al.Smith@aeschi.ch.eu.org> Signed-off-by:
-
Andy Shevchenko authored
abs_diff() belongs to math.h. Move it there. This will allow others to use it. [andriy.shevchenko@linux.intel.com: add abs_diff() documentation] Link: https://lkml.kernel.org/r/20230804050934.83223-1-andriy.shevchenko@linux.intel.com [akpm@linux-foundation.org: fix comment, per Randy] Link: https://lkml.kernel.org/r/20230803131918.53727-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> # gpu/ipu-v3 Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Cc: Helge Deller <deller@gmx.de> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Chengfeng Ye authored
&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/20230802131436.17765-1-dg573847474@gmail.comSigned-off-by:Chengfeng Ye <dg573847474@gmail.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <jiangqi903@gmail.com> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Signed-off-by:
-
Chengfeng Ye authored
&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/20230802123824.15301-1-dg573847474@gmail.comSigned-off-by: -
Kuan-Ying Lee authored
'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/20230710092852.31049-1-Kuan-Ying.Lee@mediatek.com Fixes: b4aff751 ("scripts/gdb: use mem instead of core_layout to get the module address") Signed-off-by:
Pankaj Raghav <p.raghav@samsung.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: Chinwen Chang <chinwen.chang@mediatek.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Qun-Wei Lin <qun-wei.lin@mediatek.com> Signed-off-by:
-
John Sanpe authored
Replace internal logic with separate bitrev library. Link: https://lkml.kernel.org/r/20230730081717.1498217-1-sanpeqf@gmail.comSigned-off-by:
John Sanpe <sanpeqf@gmail.com> Cc: Bhaskar Chowdhury <unixbhaskar@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Koudai Iwahori authored
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/20230801121052.2475183-1-koudai@google.comSigned-off-by:
Koudai Iwahori <koudai@google.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Cc: Kieran Bingham <kbingham@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
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/0820010f-e9dc-779d-7924-49c7df446bce@linux.ibm.com/ Link: https://lkml.kernel.org/r/20230725123042.2269077-1-arnd@kernel.orgSigned-off-by:
Arnd Bergmann <arnd@arndb.de> Tested-by:
Peter Oberparleiter <oberpar@linux.ibm.com> Acked-by:
-
Kees Cook authored
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/20230726215919.never.127-kees@kernel.orgSigned-off-by:
-
Christophe JAILLET authored
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.frSigned-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Christophe JAILLET authored
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.frSigned-off-by: -
Andy Shevchenko authored
Replace custom implementation of the macros from args.h. Link: https://lkml.kernel.org/r/20230718211147.18647-5-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Replace custom implementation of the macros from args.h. Link: https://lkml.kernel.org/r/20230718211147.18647-4-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
Replace custom implementation of the macros from args.h. Link: https://lkml.kernel.org/r/20230718211147.18647-3-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Andy Shevchenko authored
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/20230718211147.18647-1-andriy.shevchenko@linux.intel.com Link: https://lkml.kernel.org/r/20230718211147.18647-2-andriy.shevchenko@linux.intel.comSigned-off-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> [PCI] Cc: Brendan Higgins <brendan.higgins@linux.dev> Cc: Daniel Latypov <dlatypov@google.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Gow <davidgow@google.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Masami Hiramatsu (Google) <mhiramat@kernel.org> Cc: Shuah Khan <skhan@linuxfoundation.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jakob Koschel authored
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/20230717-enable-kasan-lto1-v3-1-650e1efc19d1@gmail.comReviewed-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Jakob Koschel <jkl820.git@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Cc: Kees Cook <keescook@chromium.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Tom Rix <trix@redhat.com> Signed-off-by:
-
Colin Ian King authored
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/20230719121735.2831164-1-colin.i.king@gmail.comSigned-off-by:
Colin Ian King <colin.i.king@gmail.com> Cc: Christian Brauner <brauner@kernel.org> Signed-off-by:
-
Wang Ming authored
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/20230719144355.6720-1-machel@vivo.comSigned-off-by:
Wang Ming <machel@vivo.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Wang Ming authored
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/20230713082455.2415-1-machel@vivo.comSigned-off-by:
-
