aboutsummaryrefslogtreecommitdiff
path: root/scripts
AgeCommit message (Collapse)AuthorFilesLines
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-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-20scripts: generate_rust_analyzer: provide `cfg`s for `core` and `alloc`Martin Rodriguez Reboredo1-2/+14
Both `core` and `alloc` have their `cfgs` (such as `no_rc`) missing in `rust-project.json`. To remedy this, pass the flags to `generate_rust_analyzer.py` for them to be added to a dictionary where each key corresponds to a crate and each value to a list of `cfg`s. The dictionary is then used to pass the `cfg`s to each crate in the generated file (for `core` and `alloc` only). Signed-off-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Removed `Suggested-by` as discussed in mailing list. ] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-20extrawarn: move -Wrestrict into W=1 warningsArnd Bergmann1-3/+2
There are few of these, so enable them whenever W=1 is enabled. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-08-20extrawarn: enable format and stringop overflow warnings in W=1Arnd Bergmann1-5/+6
The stringop and format warnings got disabled globally when they were newly introduced in commit bd664f6b3e376 ("disable new gcc-7.1.1 warnings for now"), 217c3e0196758 ("disable stringop truncation warnings for now") and 5a76021c2eff7 ("gcc-10: disable 'stringop-overflow' warning for now"). In all cases, the sentiment at the time was that the warnings are useful, and we actually addressed a number of real bugs based on them, but we never managed to eliminate them all because even the build bots using W=1 builds only see the -Wstringop-truncation warnings that are enabled at that level. Move these into the W=1 section to give them a larger build coverage and actually eliminate them over time. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-08-20kbuild: avoid duplicate warning optionsArnd Bergmann1-17/+26
Some warning options are disabled at one place and then conditionally re-enabled later in scripts/Makefile.extrawarn. For consistency, rework this file so each of those warnings only gets etiher enabled or disabled based on the W= flags but not both. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-08-20kbuild: consolidate warning flags in scripts/Makefile.extrawarnArnd Bergmann1-0/+90
Warning options are enabled and disabled in inconsistent ways and inconsistent locations. Start rearranging those by moving all options into Makefile.extrawarn. This should not change any behavior, but makes sure we can group them in a way that ensures that each warning that got temporarily disabled is turned back on at an appropriate W=1 level later on. Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Masahiro Yamada <[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-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-18arch/ia64/include: remove CONFIG_IA64_DEBUG_CMPXCHG from uapi headerThomas Huth1-1/+0
CONFIG_* switches should not be exposed in uapi headers. The macros that are defined here are also only useful for the kernel code, so let's move them to asm/cmpxchg.h instead. The only two files that are using these macros are the headers arch/ia64/include/asm/bitops.h and arch/ia64/include/asm/atomic.h and these include asm/cmpxchg.h via asm/intrinsics.h, so this movement should not cause any trouble. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Huth <[email protected]> Cc: Arnd Bergmann <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-08-18scripts: kernel-doc: fix macro handling in enumsPavan Kumar Linga1-0/+1
drivers/net/ethernet/intel/idpf/idpf.h uses offsetof to initialize the enum enumerators: enum idpf_cap_field { IDPF_BASE_CAPS = -1, IDPF_CSUM_CAPS = offsetof(struct virtchnl2_get_capabilities, csum_caps), IDPF_SEG_CAPS = offsetof(struct virtchnl2_get_capabilities, seg_caps), IDPF_RSS_CAPS = offsetof(struct virtchnl2_get_capabilities, rss_caps), IDPF_HSPLIT_CAPS = offsetof(struct virtchnl2_get_capabilities, hsplit_caps), IDPF_RSC_CAPS = offsetof(struct virtchnl2_get_capabilities, rsc_caps), IDPF_OTHER_CAPS = offsetof(struct virtchnl2_get_capabilities, other_caps), }; kernel-doc parses the above enumerator with a ',' inside the macro and treats 'csum_caps', 'seg_caps' etc. also as enumerators resulting in the warnings: drivers/net/ethernet/intel/idpf/idpf.h:130: warning: Enum value 'csum_caps' not described in enum 'idpf_cap_field' drivers/net/ethernet/intel/idpf/idpf.h:130: warning: Enum value 'seg_caps' not described in enum 'idpf_cap_field' drivers/net/ethernet/intel/idpf/idpf.h:130: warning: Enum value 'rss_caps' not described in enum 'idpf_cap_field' drivers/net/ethernet/intel/idpf/idpf.h:130: warning: Enum value 'hsplit_caps' not described in enum 'idpf_cap_field' drivers/net/ethernet/intel/idpf/idpf.h:130: warning: Enum value 'rsc_caps' not described in enum 'idpf_cap_field' drivers/net/ethernet/intel/idpf/idpf.h:130: warning: Enum value 'other_caps' not described in enum 'idpf_cap_field' Fix it by removing the macro arguments within the parentheses. Cc: Jonathan Corbet <[email protected]> Signed-off-by: Pavan Kumar Linga <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-08-18scripts: kernel-doc: parse DEFINE_DMA_UNMAP_[ADDR|LEN]Pavan Kumar Linga1-0/+4
At present, if the macros DEFINE_DMA_UNMAP_ADDR() and DEFINE_DMA_UNMAP_LEN() are used in the structures as shown below, instead of parsing the parameter in the parentheses, kernel-doc parses 'DEFINE_DMA_UNMAP_ADDR(' and 'DEFINE_DMA_UNMAP_LEN(' which results in the following warnings: drivers/net/ethernet/intel/idpf/idpf_txrx.h:201: warning: Function parameter or member 'DEFINE_DMA_UNMAP_ADDR(dma' not described in 'idpf_tx_buf' drivers/net/ethernet/intel/idpf/idpf_txrx.h:201: warning: Function parameter or member 'DEFINE_DMA_UNMAP_LEN(len' not described in 'idpf_tx_buf' struct idpf_tx_buf { DEFINE_DMA_UNMAP_ADDR(dma); DEFINE_DMA_UNMAP_LEN(len); }; Fix the warnings by parsing DEFINE_DMA_UNMAP_ADDR() and DEFINE_DMA_UNMAP_LEN(). Cc: Jonathan Corbet <[email protected]> Acked-by: Randy Dunlap <[email protected]> Signed-off-by: Pavan Kumar Linga <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-08-17dt: dt-check-compatible: Find struct of_device_id instances with compiler ↵Rob Herring1-2/+2
annotations The regex search for declarations of struct of_device_id was missing cases that had a compiler annotation such as "__maybe_unused". Improve the regex to allow for these. Use '\S' instead of specific characters to shorten the regex. That also finds some more compatibles using '.' characters. Unfortunately, these changes add ~400 more compatibles without a schema. Reviewed-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]>
2023-08-16kconfig: port qconf to work with Qt6 in addition to Qt5Boris Kolpackov2-21/+44
Tested with Qt5 5.15 and Qt6 6.4. Note that earlier versions of Qt5 are no longer guaranteed to work. Signed-off-by: Boris Kolpackov <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-08-15rust: bindgen: upgrade to 0.65.1Aakash Sen Sharma1-1/+1
In LLVM 16, anonymous items may return names like `(unnamed union at ..)` rather than empty names [1], which breaks Rust-enabled builds because bindgen assumed an empty name instead of detecting them via `clang_Cursor_isAnonymous` [2]: $ make rustdoc LLVM=1 CLIPPY=1 -j$(nproc) RUSTC L rust/core.o BINDGEN rust/bindings/bindings_generated.rs BINDGEN rust/bindings/bindings_helpers_generated.rs BINDGEN rust/uapi/uapi_generated.rs thread 'main' panicked at '"ftrace_branch_data_union_(anonymous_at__/_/include/linux/compiler_types_h_146_2)" is not a valid Ident', .../proc-macro2-1.0.24/src/fallback.rs:693:9 ... thread 'main' panicked at '"ftrace_branch_data_union_(anonymous_at__/_/include/linux/compiler_types_h_146_2)" is not a valid Ident', .../proc-macro2-1.0.24/src/fallback.rs:693:9 ... This was fixed in bindgen 0.62.0. Therefore, upgrade bindgen to a more recent version, 0.65.1, to support LLVM 16. Since bindgen 0.58.0 changed the `--{white,black}list-*` flags to `--{allow,block}list-*` [3], update them on our side too. In addition, bindgen 0.61.0 moved its CLI utility into a binary crate called `bindgen-cli` [4]. Thus update the installation command in the Quick Start guide. Moreover, bindgen 0.61.0 changed the default functionality to bind `size_t` to `usize` [5] and added the `--no-size_t-is-usize` flag to not bind `size_t` as `usize`. Then bindgen 0.65.0 removed the `--size_t-is-usize` flag [6]. Thus stop passing the flag to bindgen. Finally, bindgen 0.61.0 added support for the `noreturn` attribute (in its different forms) [7]. Thus remove the infinite loop in our Rust panic handler after calling `BUG()`, since bindgen now correctly generates a `BUG()` binding that returns `!` instead of `()`. Link: https://github.com/llvm/llvm-project/commit/19e984ef8f49bc3ccced15621989fa9703b2cd5b [1] Link: https://github.com/rust-lang/rust-bindgen/pull/2319 [2] Link: https://github.com/rust-lang/rust-bindgen/pull/1990 [3] Link: https://github.com/rust-lang/rust-bindgen/pull/2284 [4] Link: https://github.com/rust-lang/rust-bindgen/commit/cc78b6fdb6e829e5fb8fa1639f2182cb49333569 [5] Link: https://github.com/rust-lang/rust-bindgen/pull/2408 [6] Link: https://github.com/rust-lang/rust-bindgen/issues/2094 [7] Signed-off-by: Aakash Sen Sharma <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/1013 Tested-by: Ariel Miculas <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Reworded commit message. Mentioned the `bindgen-cli` binary crate change, linked to it and updated the Quick Start guide. Re-added a deleted "as" word in a code comment and reflowed comment to respect the maximum length. ] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-14rust: upgrade to Rust 1.71.1Miguel Ojeda1-1/+1
This is the second upgrade to the Rust toolchain, from 1.68.2 to 1.71.1 (i.e. the latest). See the upgrade policy [1] and the comments on the first upgrade in commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2"). # Unstable features No unstable features (that we use) were stabilized. Therefore, the only unstable feature allowed to be used outside the `kernel` crate is still `new_uninit`, though other code to be upstreamed may increase the list. Please see [2] for details. # Required changes For the upgrade, this patch requires the following changes: - Removal of the `__rust_*` allocator functions, together with the addition of the `__rust_no_alloc_shim_is_unstable` static. See [3] for details. - Some more compiler builtins added due to `<f{32,64}>::midpoint()` that got added in Rust 1.71 [4]. # `alloc` upgrade and reviewing The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://rust-for-linux.com/rust-version-policy [1] Link: https://github.com/Rust-for-Linux/linux/issues/2 [2] Link: https://github.com/rust-lang/rust/pull/86844 [3] Link: https://github.com/rust-lang/rust/pull/92048 [4] Closes: https://github.com/Rust-for-Linux/linux/issues/68 Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Trevor Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-13Merge tag 'kbuild-fixes-v6.5-2' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Clear errno before calling getline() - Fix a modpost warning for ARCH=alpha * tag 'kbuild-fixes-v6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: alpha: remove __init annotation from exported page_is_ram() scripts/kallsyms: Fix build failure by setting errno before calling getline()
2023-08-13kconfig: nconf: Add search jump featureJesse Taube3-15/+140
Menuconfig has a feature where you can "press the key in the (#) prefix to jump directly to that location. You will be returned to the current search results after exiting this new menu." This commit adds this feature to nconfig, with almost identical code. Signed-off-by: Jesse Taube <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-08-10gcc-plugins: Rename last_stmt() for GCC 14+Kees Cook1-0/+4
In GCC 14, last_stmt() was renamed to last_nondebug_stmt(). Add a helper macro to handle the renaming. Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2023-08-10btf, scripts: rust: drop is_rust_module.shAndrea Righi2-18/+0
With commit c1177979af9c ("btf, scripts: Exclude Rust CUs with pahole") we are now able to use pahole directly to identify Rust compilation units (CUs) and exclude them from generating BTF debugging information (when DEBUG_INFO_BTF is enabled). And if pahole doesn't support the --lang-exclude flag, we can't enable both RUST and DEBUG_INFO_BTF at the same time. So, in any case, the script is_rust_module.sh is just redundant and we can drop it. NOTE: we may also be able to drop the "Rust loadable module" mark inside Rust modules, but it seems safer to keep it for now to make sure we are not breaking any external tool that may potentially rely on it. Signed-off-by: Andrea Righi <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Eric Curtin <[email protected]> Reviewed-by: Eric Curtin <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Acked-by: Daniel Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Picked the `Reviewed-by`s from the old patch too. ] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-10kbuild: rust_is_available: add test suiteMiguel Ojeda1-0/+346
The `rust_is_available.sh` script runs for everybody compiling the kernel, even if not using Rust. Therefore, it is important to ensure that the script is correct to avoid breaking people's compilation. In addition, the script needs to be able to handle a set of subtle cases, including parsing version strings of different tools. Therefore, maintenance of this script can be greatly eased with a set of tests. Thus add a test suite to cover hopefully most of the setups that the script may encounter in the wild. Extra setups can be easily added later on if missing. The script currently covers all the branches of the shell script, including several ways in which they may be entered. Python is used for this script, since the script under test does not depend on Rust, thus hopefully making it easier for others to use if the need arises. Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-10kbuild: rust_is_available: check that output looks as expectedMiguel Ojeda1-0/+28
The script already checks for `$RUSTC` and `$BINDGEN` existing and exiting without failure. However, one may still pass an unexpected binary that does not output what the later parsing expects. The script still successfully reports a failure as expected, but the error is confusing. For instance: $ RUSTC=true BINDGEN=bindgen CC=clang scripts/rust_is_available.sh scripts/rust_is_available.sh: 19: arithmetic expression: expecting primary: "100000 * + 100 * + " *** *** Please see Documentation/rust/quick-start.rst for details *** on how to set up the Rust support. *** Thus add an explicit check and a proper message for unexpected output from the called command. Similarly, do so for the `libclang` version parsing, too. Link: https://lore.kernel.org/rust-for-linux/CAK7LNAQYk6s11MASRHW6oxtkqF00EJVqhHOP=5rynWt-QDUsXw@mail.gmail.com/ Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-10kbuild: rust_is_available: handle failures calling `$RUSTC`/`$BINDGEN`Miguel Ojeda1-2/+26
The script already checks if `$RUSTC` and `$BINDGEN` exists via `command`, but the environment variables may point to a non-executable file, or the programs may fail for some other reason. While the script successfully exits with a failure as it should, the error given can be quite confusing depending on the shell and the behavior of its `command`. For instance, with `dash`: $ RUSTC=./mm BINDGEN=bindgen CC=clang scripts/rust_is_available.sh scripts/rust_is_available.sh: 19: arithmetic expression: expecting primary: "100000 * + 100 * + " Thus detect failure exit codes when calling `$RUSTC` and `$BINDGEN` and print a better message, in a similar way to what we do when extracting the `libclang` version found by `bindgen`. Link: https://lore.kernel.org/rust-for-linux/CAK7LNAQYk6s11MASRHW6oxtkqF00EJVqhHOP=5rynWt-QDUsXw@mail.gmail.com/ Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-10kbuild: rust_is_available: normalize version matchingMiguel Ojeda1-4/+5
In order to match the version string, `sed` is used in a couple cases, and `grep` and `head` in a couple others. Make the script more consistent and easier to understand by using the same method, `sed`, for all of them. This makes the version matching also a bit more strict for the changed cases, since the strings `rustc ` and `bindgen ` will now be required, which should be fine since `rustc` complains if one attempts to call it with another program name, and `bindgen` uses a hardcoded string. In addition, clarify why one of the existing `sed` commands does not provide an address like the others. Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-10kbuild: rust_is_available: fix confusion when a version appears in the pathMiguel Ojeda1-3/+1
`bindgen`'s output for `libclang`'s version check contains paths, which in turn may contain strings that look like version numbers [1][2]: .../6.1.0-dev/.../rust_is_available_bindgen_libclang.h:2:9: warning: clang version 11.1.0 [-W#pragma-messages], err: false which the script will pick up as the version instead of the latter. It is also the case that versions may appear after the actual version (e.g. distribution's version text), which was the reason behind `head` [3]: .../rust-is-available-bindgen-libclang.h:2:9: warning: clang version 13.0.0 (Fedora 13.0.0-3.fc35) [-W#pragma-messages], err: false Thus instead ask for a match after the `clang version` string. Reported-by: Jordan Isaacs <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/942 [1] Reported-by: "Ethan D. Twardy" <[email protected]> Closes: https://lore.kernel.org/rust-for-linux/[email protected]/ [2] Reported-by: Tiago Lam <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/pull/789 [3] Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Ethan Twardy <[email protected]> Tested-by: Ethan Twardy <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-09kbuild: rust_is_available: check that environment variables are setMiguel Ojeda1-0/+29
Sometimes [1] users may attempt to setup the Rust support by checking what Kbuild does and they end up finding out about `scripts/rust_is_available.sh`. Inevitably, they run the script directly, but unless they setup the required variables, the result of the script is not meaningful. We could add some defaults to the variables, but that could be confusing for those that may override the defaults (compared to their kernel builds), and `$CC` would not be a simple default in any case. Therefore, instead, explicitly check whether the expected variables are set (`$RUSTC`, `$BINDGEN` and `$CC`). If not, print an explanation about the fact that the script is meant to be called from Kbuild, since that is the most likely cause for the variables not being set. Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ [1] Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-09kbuild: rust_is_available: add check for `bindgen` invocationMiguel Ojeda1-1/+21
`scripts/rust_is_available.sh` calls `bindgen` with a special header in order to check whether the `libclang` version in use is suitable. However, the invocation itself may fail if, for instance, `bindgen` cannot locate `libclang`. This is fine for Kconfig (since the script will still fail and therefore disable Rust as it should), but it is pretty confusing for users of the `rustavailable` target given the error will be unrelated: ./scripts/rust_is_available.sh: 21: arithmetic expression: expecting primary: "100000 * + 100 * + " make: *** [Makefile:1816: rustavailable] Error 2 Instead, run the `bindgen` invocation independently in a previous step, saving its output and return code. If it fails, then show the user a proper error message. Otherwise, continue as usual with the saved output. Since the previous patch we show a reference to the docs, and the docs now explain how `bindgen` looks for `libclang`, thus the error message can leverage the documentation, avoiding duplication here (and making users aware of the setup guide in the documentation). Reported-by: Nick Desaulniers <[email protected]> Link: https://lore.kernel.org/rust-for-linux/CAKwvOdm5JT4wbdQQYuW+RT07rCi6whGBM2iUAyg8A1CmLXG6Nw@mail.gmail.com/ Reported-by: François Valenduc <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/934 Reported-by: Alexandru Radovici <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/pull/921 Reported-by: Matthew Leach <[email protected]> Closes: https://lore.kernel.org/rust-for-linux/[email protected]/ Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-09kbuild: rust_is_available: print docs referenceMiguel Ojeda1-0/+17
People trying out the Rust support in the kernel may get warnings and errors from `scripts/rust_is_available.sh` from the `rustavailable` target or the build step. Some of those users may be following the Quick Start guide, but others may not (likely those getting warnings from the build step instead of the target). While the messages are fairly clear on what the problem is, it may not be clear how to solve the particular issue, especially for those not aware of the documentation. We could add all sorts of details on the script for each one, but it is better to point users to the documentation instead, where it is easily readable in different formats. It also avoids duplication. Thus add a reference to the documentation whenever the script fails or there is at least a warning. Reviewed-by: Finn Behrens <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-09kbuild: rust_is_available: fix version check when CC has multiple argumentsRussell Currey1-2/+2
rust_is_available.sh uses cc-version.sh to identify which C compiler is in use, as scripts/Kconfig.include does. cc-version.sh isn't designed to be able to handle multiple arguments in one variable, i.e. "ccache clang". Its invocation in rust_is_available.sh quotes "$CC", which makes $1 == "ccache clang" instead of the intended $1 == ccache & $2 == clang. cc-version.sh could also be changed to handle having "ccache clang" as one argument, but it only has the one consumer upstream, making it simpler to fix the caller here. Signed-off-by: Russell Currey <[email protected]> Fixes: 78521f3399ab ("scripts: add `rust_is_available.sh`") Link: https://github.com/Rust-for-Linux/linux/pull/873 [ Reworded title prefix and reflow line to 75 columns. ] Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-09kbuild: rust_is_available: remove -v optionMasahiro Yamada1-56/+40
The -v option is passed when this script is invoked from Makefile, but not when invoked from Kconfig. As you can see in scripts/Kconfig.include, the 'success' macro suppresses stdout and stderr anyway, so this script does not need to be quiet. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Reworded prefix to match the others in the patch series. ] Reviewed-by: Martin Rodriguez Reboredo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-08-08scripts/setlocalversion: also consider annotated tags of the form ↵Rasmus Villemoes1-10/+26
vx.y.z-${file_localversion} Commit 6ab7e1f95e96 ("setlocalversion: use only the correct release tag for git-describe") was absolutely correct to limit which annotated tags would be used to compute the -01234-gabcdef suffix. Otherwise, if some random annotated tag exists closer to HEAD than the vX.Y.Z one, the commit count would be too low. However, since the version string always includes the ${file_localversion} part, now the problem is that the count can be too high. For example, building an 6.4.6-rt8 kernel with a few patches on top, I currently get $ make -s kernelrelease 6.4.6-rt8-00128-gd78b7f406397 But those 128 commits include the 100 commits that are in v6.4.6..v6.4.6-rt8, so this is somewhat misleading. Amend the logic so that, in addition to the linux-next consideration, the script also looks for a tag corresponding to the 6.4.6-rt8 part of what will become the `uname -r` string. With this patch (so 29 patches on top of v6.4.6-rt8), one instead gets $ make -s kernelrelease 6.4.6-rt8-00029-gd533209291a2 While there, note that the line git describe --exact-match --match=$tag $tag 2>/dev/null obviously asks if $tag is an annotated tag, but it does not actually tell if the commit pointed to has any relation to HEAD. So remove both uses of --exact-match, and instead just ask if the description generated is identical to the tag we provided. Since we then already have the result of git describe --match=$tag we also end up reducing the number of times we invoke "git describe". Signed-off-by: Rasmus Villemoes <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-08-08scripts/setlocalversion: clean up stale commentRasmus Villemoes1-1/+1
Nobody has complained since 2a73cce2dad3 ("scripts/setlocalversion: remove mercurial, svn and git-svn supports"), so let's also clean up the header comment accordingly. Signed-off-by: Rasmus Villemoes <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
2023-08-08kbuild: deb-pkg: split debian/rulesMasahiro Yamada2-29/+33
debian/rules is generated by shell, but the escape sequence (\$) is unreadable. debian/rules embeds only two variables (ARCH and KERNELRELEASE). Split them out to debian/rules.vars, and check-in the rest of Makefile code to scripts/package/debian/rules. Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2023-08-08kbuild: deb-pkg: use Debian compliant shebang for debian/rulesMasahiro Yamada2-2/+2
Debian Policy "4.9. Main building script: debian/rules" requires "debian/rules must start with the line #!/usr/bin/make -f". [1] Currently, Kbuild does not follow this policy. When Kbuild generates debian/rules, "#!$(command -v $MAKE) -f" is expanded by shell. The resuling string may not be "#!/usr/bin/make -f". There was a reason to opt out the Debian policy. If you run '/path/to/my/custom/make deb-pkg', debian/rules must also be invoked by the same Make program. If #!/usr/bin/make were hard-coded in debian/rules, the sub-make would be executed by a possibly different Make version. This is problematic due to the MAKEFLAGS incompatibility, especially the job server flag. Old Make versions used --jobserver-fds to propagate job server file descriptors, but Make >= 4.2 uses --jobserver-auth. The flag disagreement between the parent/child Makes would result in a process fork explosion. However, having a non-standard path in the shebang causes another issue; the generated source package is not portable as such a path does not exist in other build environments. This commit solves those conflicting demands. Hard-code '#!/usr/bin/make -f' in debian/rules to create a portable and Debian-compliant source package. Pass '--rules-file=$(MAKE) -f debian/rules' when dpkg-buildpackage is invoked from Makefile so that debian/rules is executed by the same Make program as used to start Kbuild. [1] https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Nicolas Schier <[email protected]>
2023-08-07scripts: `make rust-analyzer` for out-of-tree modulesVinay Varma1-9/+18
Adds support for out-of-tree rust modules to use the `rust-analyzer` make target to generate the rust-project.json file. The change involves adding an optional parameter `external_src` to the `generate_rust_analyzer.py` which expects the path to the out-of-tree module's source directory. When this parameter is passed, I have chosen not to add the non-core modules (samples and drivers) into the result since these are not expected to be used in third party modules. Related changes are also made to the Makefile and rust/Makefile allowing the `rust-analyzer` target to be used for out-of-tree modules as well. Link: https://github.com/Rust-for-Linux/linux/pull/914 Link: https://github.com/Rust-for-Linux/rust-out-of-tree-module/pull/2 Signed-off-by: Vinay Varma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]>
2023-07-31modpost: remove ElF_Rela variables from for-loop in section_rel(a)Masahiro Yamada1-14/+11
Remove the Elf_Rela variables used in the for-loop in section_rel(). This makes the code consistent; section_rel() only uses Elf_Rel, section_rela() only uses Elf_Rela. Signed-off-by: Masahiro Yamada <[email protected]>
2023-07-31modpost: clean up MIPS64 little endian relocation codeMasahiro Yamada2-55/+43
MIPS64 little endian target has an odd encoding of r_info. This commit makes the special handling less ugly. It is still ugly, but #if conditionals will go away, at least. Signed-off-by: Masahiro Yamada <[email protected]>
2023-07-31modpost: pass r_type to addend_*_rel()Masahiro Yamada1-13/+11
All of addend_*_rel() need the Elf_Rela pointer just for calculating ELF_R_TYPE(r->r_info). You can do it on the caller to de-duplicate the code. Signed-off-by: Masahiro Yamada <[email protected]>
2023-07-31modpost: change return type of addend_*_rel()Masahiro Yamada1-39/+24
Now that none of addend_*_rel() returns a meaningful value (the return value is always 0), change all of them to return the value of r_addend. Signed-off-by: Masahiro Yamada <[email protected]>
2023-07-30Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds1-68/+0
Pull kvm fixes from Paolo Bonzini: "x86: - Do not register IRQ bypass consumer if posted interrupts not supported - Fix missed device interrupt due to non-atomic update of IRR - Use GFP_KERNEL_ACCOUNT for pid_table in ipiv - Make VMREAD error path play nice with noinstr - x86: Acquire SRCU read lock when handling fastpath MSR writes - Support linking rseq tests statically against glibc 2.35+ - Fix reference count for stats file descriptors - Detect userspace setting invalid CR0 Non-KVM: - Remove coccinelle script that has caused multiple confusion ("debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage", acked by Greg)" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (21 commits) KVM: selftests: Expand x86's sregs test to cover illegal CR0 values KVM: VMX: Don't fudge CR0 and CR4 for restricted L2 guest KVM: x86: Disallow KVM_SET_SREGS{2} if incoming CR0 is invalid Revert "debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage" KVM: selftests: Verify stats fd is usable after VM fd has been closed KVM: selftests: Verify stats fd can be dup()'d and read KVM: selftests: Verify userspace can create "redundant" binary stats files KVM: selftests: Explicitly free vcpus array in binary stats test KVM: selftests: Clean up stats fd in common stats_test() helper KVM: selftests: Use pread() to read binary stats header KVM: Grab a reference to KVM for VM and vCPU stats file descriptors selftests/rseq: Play nice with binaries statically linked against glibc 2.35+ Revert "KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid" KVM: x86: Acquire SRCU read lock when handling fastpath MSR writes KVM: VMX: Use vmread_error() to report VM-Fail in "goto" path KVM: VMX: Make VMREAD error path play nice with noinstr KVM: x86/irq: Conditionally register IRQ bypass consumer again KVM: X86: Use GFP_KERNEL_ACCOUNT for pid_table in ipiv KVM: x86: check the kvm_cpu_get_interrupt result before using it KVM: x86: VMX: set irr_pending in kvm_apic_update_irr ...
2023-07-29Revert "debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage"Sean Christopherson1-68/+0
Remove coccinelle's recommendation to use DEFINE_DEBUGFS_ATTRIBUTE() instead of DEFINE_SIMPLE_ATTRIBUTE(). Regardless of whether or not the "significant overhead" incurred by debugfs_create_file() is actually meaningful, warnings from the script have led to a rash of low-quality patches that have sowed confusion and consumed maintainer time for little to no benefit. There have been no less than four attempts to "fix" KVM, and a quick search on lore shows that KVM is not alone. This reverts commit 5103068eaca290f890a30aae70085fac44cecaf6. Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/all/[email protected] Link: https://lkml.kernel.org/r/20230706072954.4881-1-duminjie%40vivo.com Link: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/all/Y2ENJJ1YiSg5oHiy@orome Link: https://lore.kernel.org/all/[email protected] Suggested-by: Paolo Bonzini <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.