kernel/linux.git/samples, branch v6.12.80

samples/ftrace: Adjust LoongArch register restore order in direct calls

2026-01-08T09:14:50+00:00

commit bb85d206be208bbf834883e948125a35ac59993a upstream. Ensure that in the ftrace direct call logic, the CPU register state (with ra = parent return address) is restored to the correct state after the execution of the custom trampoline function and before returning to the traced function. Additionally, guarantee the correctness of the jump logic for jr t0 (traced function address). Cc: stable@vger.kernel.org Fixes: 9cdc3b6a299c ("LoongArch: ftrace: Add direct call support") Reported-by: Youling Tang Acked-by: Steven Rostedt (Google) Signed-off-by: Chenghao Duan Signed-off-by: Huacai Chen Signed-off-by: Greg Kroah-Hartman

samples: work around glibc redefining some of our defines wrong

2025-12-12T17:37:21+00:00

[ Upstream commit a48f822908982353c3256e35a089e9e7d0d61580 ] Apparently as of version 2.42, glibc headers define AT_RENAME_NOREPLACE and some of the other flags for renameat2() and friends in . Which would all be fine, except for inexplicable reasons glibc decided to define them _differently_ from the kernel definitions, which then makes some of our sample code that includes both kernel headers and user space headers unhappy, because the compiler will (correctly) complain about redefining things. Now, mixing kernel headers and user space headers is always a somewhat iffy proposition due to namespacing issues, but it's kind of inevitable in our sample and selftest code. And this is just glibc being stupid. Those defines come from the kernel, glibc is exposing the kernel interfaces, and glibc shouldn't make up some random new expressions for these values. It's not like glibc headers changed the actual result values, but they arbitrarily just decided to use a different expression to describe those values. The kernel just does #define AT_RENAME_NOREPLACE 0x0001 while glibc does # define RENAME_NOREPLACE (1 << 0) # define AT_RENAME_NOREPLACE RENAME_NOREPLACE instead. Same value in the end, but very different macro definition. For absolutely no reason. This has since been fixed in the glibc development tree, so eventually we'll end up with the canonical expressions and no clashes. But in the meantime the broken headers are in the glibc-2.42 release and have made it out into distributions. Do a minimal work-around to make the samples build cleanly by just undefining the affected macros in between the user space header include and the kernel header includes. Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

ftrace/samples: Fix function size computation

2025-09-19T14:35:44+00:00

[ Upstream commit 80d03a40837a9b26750a25122b906c052cc846c9 ] In my_tramp1 function .size directive was placed above ASM_RET instruction, leading to a wrong function size. Link: https://lore.kernel.org/aK3d7vxNcO52kEmg@vova-pc Fixes: 9d907f1ae80b ("samples/ftrace: Fix asm function ELF annotations") Signed-off-by: Vladimir Riabchun Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin

samples: mei: Fix building on musl libc

2025-08-15T10:13:38+00:00

[ Upstream commit 239df3e4b4752524e7c0fb3417c218d8063654b4 ] The header bits/wordsize.h is glibc specific and on building on musl with allyesconfig results in samples/mei/mei-amt-version.c:77:10: fatal error: bits/wordsize.h: No such file or directory 77 | #include | ^~~~~~~~~~~~~~~~~ mei-amt-version.c build file without bits/wordsize.h on musl and glibc. However on musl we get the follwing error without sys/time.h samples/mei/mei-amt-version.c: In function 'mei_recv_msg': samples/mei/mei-amt-version.c:159:24: error: storage size of 'tv' isn't known 159 | struct timeval tv; | ^~ samples/mei/mei-amt-version.c:160:9: error: unknown type name 'fd_set' 160 | fd_set set; | ^~~~~~ samples/mei/mei-amt-version.c:168:9: error: implicit declaration of function 'FD_ZERO' [-Wimplicit-function-declaration] 168 | FD_ZERO(&set); | ^~~~~~~ samples/mei/mei-amt-version.c:169:9: error: implicit declaration of function 'FD_SET'; did you mean 'L_SET'? [-Wimplicit-function-declaration] 169 | FD_SET(me->fd, &set); | ^~~~~~ | L_SET samples/mei/mei-amt-version.c:170:14: error: implicit declaration of function 'select' [-Wimplicit-function-declaration] 170 | rc = select(me->fd + 1, &set, NULL, NULL, &tv); | ^~~~~~ samples/mei/mei-amt-version.c:171:23: error: implicit declaration of function 'FD_ISSET' [-Wimplicit-function-declaration] 171 | if (rc > 0 && FD_ISSET(me->fd, &set)) { | ^~~~~~~~ samples/mei/mei-amt-version.c:159:24: warning: unused variable 'tv' [-Wunused-variable] 159 | struct timeval tv; | ^~ Hence the the file has been included. Fixes: c52827cc4ddf ("staging/mei: add mei user space example") Signed-off-by: Brahmajit Das Link: https://lore.kernel.org/r/20250702135955.24955-1-listout@listout.xyz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

samples/bpf: Fix compilation failure for samples/bpf on LoongArch Fedora

2025-05-29T09:02:01+00:00

[ Upstream commit 548762f05d19c5542db7590bcdfb9be1fb928376 ] When building the latest samples/bpf on LoongArch Fedora make M=samples/bpf There are compilation errors as follows: In file included from ./linux/samples/bpf/sockex2_kern.c:2: In file included from ./include/uapi/linux/in.h:25: In file included from ./include/linux/socket.h:8: In file included from ./include/linux/uio.h:9: In file included from ./include/linux/thread_info.h:60: In file included from ./arch/loongarch/include/asm/thread_info.h:15: In file included from ./arch/loongarch/include/asm/processor.h:13: In file included from ./arch/loongarch/include/asm/cpu-info.h:11: ./arch/loongarch/include/asm/loongarch.h:13:10: fatal error: 'larchintrin.h' file not found ^~~~~~~~~~~~~~~ 1 error generated. larchintrin.h is included in /usr/lib64/clang/14.0.6/include, and the header file location is specified at compile time. Test on LoongArch Fedora: https://github.com/fedora-remix-loongarch/releases-info Signed-off-by: Haoran Jiang Signed-off-by: zhangxi Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20250425095042.838824-1-jianghaoran@kylinos.cn Signed-off-by: Sasha Levin

tracing: samples: Initialize trace_array_printk() with the correct function

2025-05-22T12:29:48+00:00

commit 1b0c192c92ea1fe2dcb178f84adf15fe37c3e7c8 upstream. When using trace_array_printk() on a created instance, the correct function to use to initialize it is: trace_array_init_printk() Not trace_printk_init_buffer() The former is a proper function to use, the latter is for initializing trace_printk() and causes the NOTICE banner to be displayed. Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Divya Indi Link: https://lore.kernel.org/20250509152657.0f6744d9@gandalf.local.home Fixes: 89ed42495ef4a ("tracing: Sample module to demonstrate kernel access to Ftrace instances.") Fixes: 38ce2a9e33db6 ("tracing: Add trace_array_init_printk() to initialize instance trace_printk() buffers") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman

tracing: Verify event formats that have "%*p.."

2025-05-02T05:58:52+00:00

[ Upstream commit ea8d7647f9ddf1f81e2027ed305299797299aa03 ] The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory. The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%*p.." the verifier will ignore it, and that could be dangerous. Cover this case as well. Also add to the sample code a use case of "%*pbl". Link: https://lore.kernel.org/all/bcba4d76-2c3f-4d11-baf0-02905db953dd@oracle.com/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Fixes: 5013f454a352c ("tracing: Add check of trace event print fmts for dereferencing pointers") Link: https://lore.kernel.org/20250327195311.2d89ec66@gandalf.local.home Reported-by: Libo Chen Reviewed-by: Libo Chen Tested-by: Libo Chen Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin

tracing: Add __print_dynamic_array() helper

2025-05-02T05:58:51+00:00

[ Upstream commit e52750fb1458ae9ea5860a08ed7a149185bc5b97 ] When printing a dynamic array in a trace event, the method is rather ugly. It has the format of: __print_array(__get_dynamic_array(array), __get_dynmaic_array_len(array) / el_size, el_size) Since dynamic arrays are known to the tracing infrastructure, create a helper macro that does the above for you. __print_dynamic_array(array, el_size) Which would expand to the same output. Signed-off-by: Steven Rostedt (Google) Signed-off-by: Avadhut Naik Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Qiuxu Zhuo Link: https://lore.kernel.org/r/20241022194158.110073-3-avadhut.naik@amd.com Stable-dep-of: ea8d7647f9dd ("tracing: Verify event formats that have "%*p.."") Signed-off-by: Sasha Levin

rust: treewide: switch to the kernel `Vec` type

2025-03-13T12:01:46+00:00

commit 58eff8e872bd04ccb3adcf99aec7334ffad06cfd upstream. Now that we got the kernel `Vec` in place, convert all existing `Vec` users to make use of it. Reviewed-by: Alice Ryhl Reviewed-by: Benno Lossin Reviewed-by: Gary Guo Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20241004154149.93856-20-dakr@kernel.org [ Converted `kasan_test_rust.rs` too, as discussed. - Miguel ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: start using the `#[expect(...)]` attribute

2025-03-13T12:01:42+00:00

commit 1f9ed172545687e5c04c77490a45896be6d2e459 upstream. In Rust, it is possible to `allow` particular warnings (diagnostics, lints) locally, making the compiler ignore instances of a given warning within a given function, module, block, etc. It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-function" static void f(void) {} #pragma GCC diagnostic pop But way less verbose: #[allow(dead_code)] fn f() {} By that virtue, it makes it possible to comfortably enable more diagnostics by default (i.e. outside `W=` levels) that may have some false positives but that are otherwise quite useful to keep enabled to catch potential mistakes. The `#[expect(...)]` attribute [1] takes this further, and makes the compiler warn if the diagnostic was _not_ produced. For instance, the following will ensure that, when `f()` is called somewhere, we will have to remove the attribute: #[expect(dead_code)] fn f() {} If we do not, we get a warning from the compiler: warning: this lint expectation is unfulfilled --> x.rs:3:10 | 3 | #[expect(dead_code)] | ^^^^^^^^^ | = note: `#[warn(unfulfilled_lint_expectations)]` on by default This means that `expect`s do not get forgotten when they are not needed. See the next commit for more details, nuances on its usage and documentation on the feature. The attribute requires the `lint_reasons` [2] unstable feature, but it is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has already been useful to clean things up in this patch series, finding cases where the `allow`s should not have been there. Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s where possible. This feature was also an example of the ongoing collaboration between Rust and the kernel -- we tested it in the kernel early on and found an issue that was quickly resolved [3]. Cc: Fridtjof Stoldt Cc: Urgau Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1] Link: https://github.com/rust-lang/rust/issues/54503 [2] Link: https://github.com/rust-lang/rust/issues/114557 [3] Reviewed-by: Alice Ryhl Reviewed-by: Trevor Gross Tested-by: Gary Guo Reviewed-by: Gary Guo Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman