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

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

rust: replace `clippy::dbg_macro` with `disallowed_macros`

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

commit 8577c9dca799bd74377f7c30015d8cdc53a53ca2 upstream. Back when we used Rust 1.60.0 (before Rust was merged in the kernel), we added `-Wclippy::dbg_macro` to the compilation flags. This worked great with our custom `dbg!` macro (vendored from `std`, but slightly modified to use the kernel printing facilities). However, in the very next version, 1.61.0, it stopped working [1] since the lint started to use a Rust diagnostic item rather than a path to find the `dbg!` macro [1]. This behavior remains until the current nightly (1.83.0). Therefore, currently, the `dbg_macro` is not doing anything, which explains why we can invoke `dbg!` in samples/rust/rust_print.rs`, as well as why changing the `#[allow()]`s to `#[expect()]`s in `std_vendor.rs` doctests does not work since they are not fulfilled. One possible workaround is using `rustc_attrs` like the standard library does. However, this is intended to be internal, and we just started supporting several Rust compiler versions, so it is best to avoid it. Therefore, instead, use `disallowed_macros`. It is a stable lint and is more flexible (in that we can provide different macros), although its diagnostic message(s) are not as nice as the specialized one (yet), and does not allow to set different lint levels per macro/path [2]. In turn, this requires allowing the (intentional) `dbg!` use in the sample, as one would have expected. Finally, in a single case, the `allow` is fixed to be an inner attribute, since otherwise it was not being applied. Link: https://github.com/rust-lang/rust-clippy/issues/11303 [1] Link: https://github.com/rust-lang/rust-clippy/issues/11307 [2] Tested-by: Gary Guo Reviewed-by: Gary Guo Link: https://lore.kernel.org/r/20240904204347.168520-13-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

samples/landlock: Fix possible NULL dereference in parse_path()

2025-02-08T08:57:11+00:00

[ Upstream commit 078bf9438a31567e2c0587159ccefde835fb1ced ] malloc() may return NULL, leading to NULL dereference. Add a NULL check. Fixes: ba84b0bf5a16 ("samples/landlock: Add a sandbox manager example") Signed-off-by: Zichen Xie Link: https://lore.kernel.org/r/20241128032955.11711-1-zichenxie0106@gmail.com [mic: Simplify fix] Signed-off-by: Mickaël Salaün Signed-off-by: Sasha Levin

samples/bpf: Fix a resource leak

2024-12-14T19:03:46+00:00

[ Upstream commit f3ef53174b23246fe9bc2bbc2542f3a3856fa1e2 ] The opened file should be closed in show_sockopts(), otherwise resource leak will occur that this problem was discovered by reading code Signed-off-by: Zhu Jun Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20241010014126.2573-1-zhujun2@cmss.chinamobile.com Signed-off-by: Sasha Levin

kfifo: don't include dma-mapping.h in kfifo.h

2024-12-05T13:03:03+00:00

[ Upstream commit 44059790a5cb9258ae6137387e4c39b717fd2ced ] Nothing in kfifo.h directly needs dma-mapping.h, only two macros use DMA_MAPPING_ERROR when actually instantiated. Drop the dma-mapping.h include to reduce include bloat. Add an explicity include to drivers/mailbox/omap-mailbox.c as that file uses __raw_readl and __raw_writel through a complicated include chain involving Fixes: d52b761e4b1a ("kfifo: add kfifo_dma_out_prepare_mapped()") Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20241023055317.313234-1-hch@lst.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

bpf: Fix the xdp_adjust_tail sample prog issue

2024-12-05T13:01:42+00:00

[ Upstream commit 4236f114a3ffbbfd217436c08852e94cae372f57 ] During the xdp_adjust_tail test, probabilistic failure occurs and SKB package is discarded by the kernel. After checking the issues by tracking SKB package, it is identified that they were caused by checksum errors. Refer to checksum of the arch/arm64/include/asm/checksum.h for fixing. v2: Based on Alexei Starovoitov's suggestions, it is necessary to keep the code implementation consistent. Fixes: c6ffd1ff7856 (bpf: add bpf_xdp_adjust_tail sample prog) Signed-off-by: Yuan Chen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240930024115.52841-1-chenyuan_fl@163.com Signed-off-by: Sasha Levin

Merge tag 'net-6.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2024-11-14T18:05:33+00:00

Pull networking fixes from Paolo Abeni: "Including fixes from bluetooth. Quite calm week. No new regression under investigation. Current release - regressions: - eth: revert "igb: Disable threaded IRQ for igb_msix_other" Current release - new code bugs: - bluetooth: btintel: direct exception event to bluetooth stack Previous releases - regressions: - core: fix data-races around sk->sk_forward_alloc - netlink: terminate outstanding dump on socket close - mptcp: error out earlier on disconnect - vsock: fix accept_queue memory leak - phylink: ensure PHY momentary link-fails are handled - eth: mlx5: - fix null-ptr-deref in add rule err flow - lock FTE when checking if active - eth: dwmac-mediatek: fix inverted handling of mediatek,mac-wol Previous releases - always broken: - sched: fix u32's systematic failure to free IDR entries for hnodes. - sctp: fix possible UAF in sctp_v6_available() - eth: bonding: add ns target multicast address to slave device - eth: mlx5: fix msix vectors to respect platform limit - eth: icssg-prueth: fix 1 PPS sync" * tag 'net-6.12-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (38 commits) net: sched: u32: Add test case for systematic hnode IDR leaks selftests: bonding: add ns multicast group testing bonding: add ns target multicast address to slave device net: ti: icssg-prueth: Fix 1 PPS sync stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines net: Make copy_safe_from_sockptr() match documentation net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol ipmr: Fix access to mfc_cache_list without lock held samples: pktgen: correct dev to DEV net: phylink: ensure PHY momentary link-fails are handled mptcp: pm: use _rcu variant under rcu_read_lock mptcp: hold pm lock when deleting entry mptcp: update local address flags when setting it net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for hnodes. MAINTAINERS: Re-add cancelled Renesas driver sections Revert "igb: Disable threaded IRQ for igb_msix_other" Bluetooth: btintel: Direct exception event to bluetooth stack Bluetooth: hci_core: Fix calling mgmt_device_connected virtio/vsock: Improve MSG_ZEROCOPY error handling vsock: Fix sk_error_queue memory leak ...

samples: pktgen: correct dev to DEV

2024-11-14T02:54:33+00:00

In the pktgen_sample01_simple.sh script, the device variable is uppercase 'DEV' instead of lowercase 'dev'. Because of this typo, the script cannot enable UDP tx checksum. Fixes: 460a9aa23de6 ("samples: pktgen: add UDP tx checksum support") Signed-off-by: Wei Fang Reviewed-by: Simon Horman Acked-by: Jesper Dangaard Brouer Link: https://patch.msgid.link/20241112030347.1849335-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski

samples/landlock: Clarify option parsing behaviour

2024-10-22T18:43:43+00:00

Clarify the distinction between filesystem variables (mandatory) and all others (optional). For optional variables, explain the difference between unset variables (no access check performed) and empty variables (nothing allowed for lists of allowed paths/ports, or no effect for lists of scopes). List the known LL_SCOPED values and their effect. Signed-off-by: Matthieu Buffet Link: https://lore.kernel.org/r/20241019151534.1400605-4-matthieu@buffet.re [mic: Add a missing colon] Signed-off-by: Mickaël Salaün