February 2025 - Linux-stable-mirror

[PATCH] x86: rust: set rustc-abi=x86-softfloat on rustc>=1.86.0

by Alice Ryhl

When using Rust on the x86 architecture, we are currently using the unstable target.json feature to specify the compilation target. Rustc is going to change how softfloat is specified in the target.json file on x86, thus update generate_rust_target.rs to specify softfloat using the new option. Note that if you enable this parameter with a compiler that does not recognize it, then that triggers a warning but it does not break the build. Cc: stable(a)vger.kernel.org # for 6.12.y Link: https://github.com/rust-lang/rust/pull/136146 Signed-off-by: Alice Ryhl <aliceryhl(a)google.com> --- scripts/generate_rust_target.rs | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs index 0d00ac3723b5..4fd6b6ab3e32 100644 --- a/scripts/generate_rust_target.rs +++ b/scripts/generate_rust_target.rs @@ -165,6 +165,18 @@ fn has(&self, option: &str) -> bool { let option = "CONFIG_".to_owned() + option; self.0.contains_key(&option) } + + /// Is the rustc version at least `major.minor.patch`? + fn rustc_version_atleast(&self, major: u32, minor: u32, patch: u32) -> bool { + let check_version = 100000 * major + 100 * minor + patch; + let actual_version = self + .0 + .get("CONFIG_RUSTC_VERSION") + .unwrap() + .parse::<u32>() + .unwrap(); + check_version <= actual_version + } } fn main() { @@ -182,6 +194,9 @@ fn main() { } } else if cfg.has("X86_64") { ts.push("arch", "x86_64"); + if cfg.rustc_version_atleast(1, 86, 0) { + ts.push("rustc-abi", "x86-softfloat"); + } ts.push( "data-layout", "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", @@ -215,6 +230,9 @@ fn main() { panic!("32-bit x86 only works under UML"); } ts.push("arch", "x86"); + if cfg.rustc_version_atleast(1, 86, 0) { + ts.push("rustc-abi", "x86-softfloat"); + } ts.push( "data-layout", "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-i128:128-f64:32:64-f80:32-n8:16:32-S128", --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20250203-rustc-1-86-x86-softfloat-0b973054c4bc Best regards, -- Alice Ryhl <aliceryhl(a)google.com>

3 weeks, 5 days

3
6
0 0

[PATCH] arm64: tegra: delete the Orin NX/Nano suspend key

by Ivy Huang

From: Ninad Malwade <nmalwade(a)nvidia.com> As per the Orin Nano Dev Kit schematic, GPIO_G.02 is not available on this device family. It should not be used at all on Orin NX/Nano. Having this unused pin mapped as the suspend key can lead to unpredictable behavior for low power modes. Orin NX/Nano uses GPIO_EE.04 as both a "power" button and a "suspend" button. However, we cannot have two gpio-keys mapped to the same GPIO. Therefore delete the "suspend" key. Cc: stable(a)vger.kernel.org Fixes: e63472eda5ea ("arm64: tegra: Support Jetson Orin NX reference platform") Signed-off-by: Ninad Malwade <nmalwade(a)nvidia.com> Signed-off-by: Ivy Huang <yijuh(a)nvidia.com> --- arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi index 19340d13f789..41821354bbda 100644 --- a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi @@ -227,13 +227,6 @@ wakeup-event-action = <EV_ACT_ASSERTED>; wakeup-source; }; - - key-suspend { - label = "Suspend"; - gpios = <&gpio TEGRA234_MAIN_GPIO(G, 2) GPIO_ACTIVE_LOW>; - linux,input-type = <EV_KEY>; - linux,code = <KEY_SLEEP>; - }; }; fan: pwm-fan { -- 2.17.1

3 weeks, 5 days

1
0
0 0

[PATCH] arm64: tegra: delete the Orin NX/Nano suspend key

by Ivy Huang

From: Ninad Malwade <nmalwade(a)nvidia.com> As per the Orin Nano Dev Kit schematic, GPIO_G.02 is not available on this device family. It should not be used at all on Orin NX/Nano. Having this unused pin mapped as the suspend key can lead to unpredictable behavior for low power modes. Orin NX/Nano uses GPIO_EE.04 as both a "power" button and a "suspend" button. However, we cannot have two gpio-keys mapped to the same GPIO. Therefore delete the "suspend" key. Cc: stable(a)vger.kernel.org Fixes: e63472eda5ea ("arm64: tegra: Support Jetson Orin NX reference platform") Signed-off-by: Ninad Malwade <nmalwade(a)nvidia.com> Signed-off-by: Ivy Huang <yijuh(a)nvidia.com> --- arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi index 19340d13f789..41821354bbda 100644 --- a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi @@ -227,13 +227,6 @@ wakeup-event-action = <EV_ACT_ASSERTED>; wakeup-source; }; - - key-suspend { - label = "Suspend"; - gpios = <&gpio TEGRA234_MAIN_GPIO(G, 2) GPIO_ACTIVE_LOW>; - linux,input-type = <EV_KEY>; - linux,code = <KEY_SLEEP>; - }; }; fan: pwm-fan { -- 2.17.1

3 weeks, 5 days

1
0
0 0

[PATCH v3 1/2] seccomp: passthrough uretprobe systemcall without filtering

by Eyal Birger

When attaching uretprobes to processes running inside docker, the attached process is segfaulted when encountering the retprobe. The reason is that now that uretprobe is a system call the default seccomp filters in docker block it as they only allow a specific set of known syscalls. This is true for other userspace applications which use seccomp to control their syscall surface. Since uretprobe is a "kernel implementation detail" system call which is not used by userspace application code directly, it is impractical and there's very little point in forcing all userspace applications to explicitly allow it in order to avoid crashing tracked processes. Pass this systemcall through seccomp without depending on configuration. Note: uretprobe isn't supported in i386 and __NR_ia32_rt_tgsigqueueinfo uses the same number as __NR_uretprobe so the syscall isn't forced in the compat bitmap. Fixes: ff474a78cef5 ("uprobe: Add uretprobe syscall to speed up return probe") Reported-by: Rafael Buchbinder <rafi(a)rbk.io> Link: https://lore.kernel.org/lkml/CAHsH6Gs3Eh8DFU0wq58c_LF8A4_+o6z456J7BidmcVY2A… Link: https://lore.kernel.org/lkml/20250121182939.33d05470@gandalf.local.home/T/#… Link: https://lore.kernel.org/lkml/20250128145806.1849977-1-eyal.birger@gmail.com/ Cc: stable(a)vger.kernel.org Signed-off-by: Eyal Birger <eyal.birger(a)gmail.com> --- v3: no change - deferring 32bit compat handling as there aren't plans to support this syscall in compat mode. v2: use action_cache bitmap and mode1 array to check the syscall --- kernel/seccomp.c | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/kernel/seccomp.c b/kernel/seccomp.c index f59381c4a2ff..09b6f8e6db51 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -734,13 +734,13 @@ seccomp_prepare_user_filter(const char __user *user_filter) #ifdef SECCOMP_ARCH_NATIVE /** - * seccomp_is_const_allow - check if filter is constant allow with given data + * seccomp_is_filter_const_allow - check if filter is constant allow with given data * @fprog: The BPF programs * @sd: The seccomp data to check against, only syscall number and arch * number are considered constant. */ -static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog, - struct seccomp_data *sd) +static bool seccomp_is_filter_const_allow(struct sock_fprog_kern *fprog, + struct seccomp_data *sd) { unsigned int reg_value = 0; unsigned int pc; @@ -812,6 +812,21 @@ static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog, return false; } +static bool seccomp_is_const_allow(struct sock_fprog_kern *fprog, + struct seccomp_data *sd) +{ +#ifdef __NR_uretprobe + if (sd->nr == __NR_uretprobe +#ifdef SECCOMP_ARCH_COMPAT + && sd->arch != SECCOMP_ARCH_COMPAT +#endif + ) + return true; +#endif + + return seccomp_is_filter_const_allow(fprog, sd); +} + static void seccomp_cache_prepare_bitmap(struct seccomp_filter *sfilter, void *bitmap, const void *bitmap_prev, size_t bitmap_size, int arch) @@ -1023,6 +1038,9 @@ static inline void seccomp_log(unsigned long syscall, long signr, u32 action, */ static const int mode1_syscalls[] = { __NR_seccomp_read, __NR_seccomp_write, __NR_seccomp_exit, __NR_seccomp_sigreturn, +#ifdef __NR_uretprobe + __NR_uretprobe, +#endif -1, /* negative terminated */ }; -- 2.43.0

3 weeks, 5 days

2
1
0 0

[PATCH] tpm: do not start chip while suspended

by Thadeu Lima de Souza Cascardo

tpm_chip_start may issue IO that should not be done while the chip is suspended. In the particular case of I2C, it will issue the following warning: [35985.503769] ------------[ cut here ]------------ [35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] <TASK> [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80 [35985.503960] hwrng_fillfn+0x13b/0x2e0 [35985.503964] ? __cfi_hwrng_fillfn+0x10/0x10 [35985.503969] kthread+0x23d/0x250 [35985.503974] ? srso_return_thunk+0x5/0x5f [35985.503979] ? lockdep_hardirqs_on+0x95/0x150 [35985.503985] ? __cfi_kthread+0x10/0x10 [35985.503989] ret_from_fork+0x44/0x50 [35985.503994] ? __cfi_kthread+0x10/0x10 [35985.503998] ret_from_fork_asm+0x11/0x20 [35985.504013] </TASK> [35985.504015] irq event stamp: 107462 [35985.504017] hardirqs last enabled at (107461): [<ffffffffa6b82d41>] _raw_spin_unlock_irqrestore+0x31/0x60 [35985.504022] hardirqs last disabled at (107462): [<ffffffffa6b77309>] __schedule+0x159/0x16f0 [35985.504027] softirqs last enabled at (104760): [<ffffffffa4f62ef5>] __irq_exit_rcu+0x75/0x160 [35985.504032] softirqs last disabled at (104755): [<ffffffffa4f62ef5>] __irq_exit_rcu+0x75/0x160 [35985.504036] ---[ end trace 0000000000000000 ]--- [35985.504126] tpm tpm0: i2c transfer failed (attempt 2/3): -108 [35985.504207] tpm tpm0: i2c transfer failed (attempt 3/3): -108 [35985.504395] tpm tpm0: i2c transfer failed (attempt 2/3): -108 [35985.504474] tpm tpm0: i2c transfer failed (attempt 3/3): -108 Test for the suspended flag inside tpm_try_get_ops while holding the chip tpm_mutex before calling tpm_chip_start. That will also prevent tpm_get_random from doing IO while the TPM is suspended. Fixes: 9265fed6db60 ("tpm: Lock TPM chip in tpm_pm_suspend() first") Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> Cc: stable(a)vger.kernel.org Cc: Jerry Snitselaar <jsnitsel(a)redhat.com> Cc: Mike Seo <mikeseohyungjin(a)gmail.com> Cc: Jarkko Sakkinen <jarkko(a)kernel.org> --- drivers/char/tpm/tpm-chip.c | 5 +++++ drivers/char/tpm/tpm-interface.c | 8 +------- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c index 7df7abaf3e526bf7e85ac9dfbaa1087a51d2ab7e..6db864696a583bf59c534ec8714900a6be7b5156 100644 --- a/drivers/char/tpm/tpm-chip.c +++ b/drivers/char/tpm/tpm-chip.c @@ -168,6 +168,11 @@ int tpm_try_get_ops(struct tpm_chip *chip) goto out_ops; mutex_lock(&chip->tpm_mutex); + + /* tmp_chip_start may issue IO that is denied while suspended */ + if (chip->flags & TPM_CHIP_FLAG_SUSPENDED) + goto out_lock; + rc = tpm_chip_start(chip); if (rc) goto out_lock; diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index b1daa0d7b341b1a4c71a200115f0d29d2e87512d..e6d786ce4e36970428b75d288a066e832c5b2af1 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -441,22 +441,16 @@ int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max) if (!out || max > TPM_MAX_RNG_DATA) return -EINVAL; + /* NULL will be returned if chip is suspended */ chip = tpm_find_get_ops(chip); if (!chip) return -ENODEV; - /* Give back zero bytes, as TPM chip has not yet fully resumed: */ - if (chip->flags & TPM_CHIP_FLAG_SUSPENDED) { - rc = 0; - goto out; - } - if (chip->flags & TPM_CHIP_FLAG_TPM2) rc = tpm2_get_random(chip, out, max); else rc = tpm1_get_random(chip, out, max); -out: tpm_put_ops(chip); return rc; } --- base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b change-id: 20250205-tpm-suspend-b22f745f3124 Best regards, -- Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com>

3 weeks, 5 days

2
1
0 0

[PATCH v2 0/2] ASoC: SOF: Correct sps->stream and cstream nullity management

by Peter Ujfalusi

Hi, Changes since v1: - fix the SHA of the Fixes tag The Nullity of sps->cstream needs to be checked in sof_ipc_msg_data() and not assume that it is not NULL. The sps->stream must be cleared to NULL on close since this is used as a check to see if we have active PCM stream. Regards, Peter --- Peter Ujfalusi (2): ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data() ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close sound/soc/sof/pcm.c | 2 ++ sound/soc/sof/stream-ipc.c | 6 +++++- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.48.1

3 weeks, 5 days

2
3
0 0

[PATCH 0/2] ASoC: SOF: Correct sps->stream and cstream nullity management

by Peter Ujfalusi

Hi, The Nullity of sps->cstream needs to be checked in sof_ipc_msg_data() and not assume that it is not NULL. The sps->stream must be cleared to NULL on close since this is used as a check to see if we have active PCM stream. Regards, Peter --- Peter Ujfalusi (2): ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data() ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close sound/soc/sof/pcm.c | 2 ++ sound/soc/sof/stream-ipc.c | 6 +++++- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.47.1

3 weeks, 5 days

2
5
0 0

[PATCH v2 0/2] ASoC: SOF: Correct sps->stream and cstream nullity management

by Peter Ujfalusi

Hi, Changes since v1: - Cc stable The nullity of sps->cstream needs to be checked in sof_ipc_msg_data() and not assume that it is not NULL. The sps->stream must be cleared to NULL on close since this is used as a check to see if we have active PCM stream. Regards, Peter --- Peter Ujfalusi (2): ASoC: SOF: stream-ipc: Check for cstream nullity in sof_ipc_msg_data() ASoC: SOF: pcm: Clear the susbstream pointer to NULL on close sound/soc/sof/pcm.c | 2 ++ sound/soc/sof/stream-ipc.c | 6 +++++- 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.47.0

3 weeks, 5 days

2
4
0 0

Re: [PATCH 6.13 000/619] 6.13.2-rc2 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

3 weeks, 5 days

1
0
0 0

[PATCH v2] arm64: Handle .ARM.attributes section in linker scripts

by Nathan Chancellor

A recent LLVM commit [1] started generating an .ARM.attributes section similar to the one that exists for 32-bit, which results in orphan section warnings (or errors if CONFIG_WERROR is enabled) from the linker because it is not handled in the arm64 linker scripts. ld.lld: error: arch/arm64/kernel/vdso/vgettimeofday.o:(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: arch/arm64/kernel/vdso/vgetrandom.o:(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/vsprintf.o):(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/win_minmax.o):(.ARM.attributes) is being placed in '.ARM.attributes' ld.lld: error: vmlinux.a(lib/xarray.o):(.ARM.attributes) is being placed in '.ARM.attributes' Discard the new sections in the necessary linker scripts to resolve the warnings, as the kernel and vDSO do not need to retain it, similar to the .note.gnu.property section. Cc: stable(a)vger.kernel.org Fixes: b3e5d80d0c48 ("arm64/build: Warn on orphan section placement") Link: https://github.com/llvm/llvm-project/commit/ee99c4d4845db66c4daa2373352133f… [1] Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- Changes in v2: - Discard the section instead of adding it to the final artifacts to mirror the .note.gnu.property section handling (Will). - Link to v1: https://lore.kernel.org/r/20250124-arm64-handle-arm-attributes-in-linker-sc… --- arch/arm64/kernel/vdso/vdso.lds.S | 1 + arch/arm64/kernel/vmlinux.lds.S | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/kernel/vdso/vdso.lds.S b/arch/arm64/kernel/vdso/vdso.lds.S index 4ec32e86a8da..8095fef66209 100644 --- a/arch/arm64/kernel/vdso/vdso.lds.S +++ b/arch/arm64/kernel/vdso/vdso.lds.S @@ -80,6 +80,7 @@ SECTIONS *(.data .data.* .gnu.linkonce.d.* .sdata*) *(.bss .sbss .dynbss .dynsbss) *(.eh_frame .eh_frame_hdr) + *(.ARM.attributes) } } diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index f84c71f04d9e..e73326bd3ff7 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -162,6 +162,7 @@ SECTIONS /DISCARD/ : { *(.interp .dynamic) *(.dynsym .dynstr .hash .gnu.hash) + *(.ARM.attributes) } . = KIMAGE_VADDR; --- base-commit: 1dd3393696efba1598aa7692939bba99d0cffae3 change-id: 20250123-arm64-handle-arm-attributes-in-linker-script-82aee25313ac Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

3 weeks, 5 days

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025