- Linux-stable-mirror - lists.linaro.org

[tip: timers/urgent] timers/migration: Fix off-by-one root mis-connection

by tip-bot2 for Frederic Weisbecker

The following commit has been merged into the timers/urgent branch of tip: Commit-ID: 868c9037df626b3c245ee26a290a03ae1f9f58d3 Gitweb: https://git.kernel.org/tip/868c9037df626b3c245ee26a290a03ae1f9f58d3 Author: Frederic Weisbecker <frederic(a)kernel.org> AuthorDate: Wed, 05 Feb 2025 17:02:20 +01:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Fri, 07 Feb 2025 09:02:16 +01:00 timers/migration: Fix off-by-one root mis-connection Before attaching a new root to the old root, the children counter of the new root is checked to verify that only the upcoming CPU's top group have been connected to it. However since the recently added commit b729cc1ec21a ("timers/migration: Fix another race between hotplug and idle entry/exit") this check is not valid anymore because the old root is pre-accounted as a child to the new root. Therefore after connecting the upcoming CPU's top group to the new root, the children count to be expected must be 2 and not 1 anymore. This omission results in the old root to not be connected to the new root. Then eventually the system may run with more than one top level, which defeats the purpose of a single idle migrator. Also the old root is pre-accounted but not connected upon the new root creation. But it can be connected to the new root later on. Therefore the old root may be accounted twice to the new root. The propagation of such overcommit can end up creating a double final top-level root with a groupmask incorrectly initialized. Although harmless given that the final top level roots will never have a parent to walk up to, this oddity opportunistically reported the core issue: WARNING: CPU: 8 PID: 0 at kernel/time/timer_migration.c:543 tmigr_requires_handle_remote CPU: 8 UID: 0 PID: 0 Comm: swapper/8 RIP: 0010:tmigr_requires_handle_remote Call Trace: <IRQ> ? tmigr_requires_handle_remote ? hrtimer_run_queues update_process_times tick_periodic tick_handle_periodic __sysvec_apic_timer_interrupt sysvec_apic_timer_interrupt </IRQ> Fix the problem by taking the old root into account in the children count of the new root so the connection is not omitted. Also warn when more than one top level group exists to better detect similar issues in the future. Fixes: b729cc1ec21a ("timers/migration: Fix another race between hotplug and idle entry/exit") Reported-by: Matt Fleming <mfleming(a)cloudflare.com> Signed-off-by: Frederic Weisbecker <frederic(a)kernel.org> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20250205160220.39467-1-frederic@kernel.org --- kernel/time/timer_migration.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/kernel/time/timer_migration.c b/kernel/time/timer_migration.c index 9cb9b65..2f63308 100644 --- a/kernel/time/timer_migration.c +++ b/kernel/time/timer_migration.c @@ -1675,6 +1675,9 @@ static int tmigr_setup_groups(unsigned int cpu, unsigned int node) } while (i < tmigr_hierarchy_levels); + /* Assert single root */ + WARN_ON_ONCE(!err && !group->parent && !list_is_singular(&tmigr_level_list[top])); + while (i > 0) { group = stack[--i]; @@ -1716,7 +1719,12 @@ static int tmigr_setup_groups(unsigned int cpu, unsigned int node) WARN_ON_ONCE(top == 0); lvllist = &tmigr_level_list[top]; - if (group->num_children == 1 && list_is_singular(lvllist)) { + + /* + * Newly created root level should have accounted the upcoming + * CPU's child group and pre-accounted the old root. + */ + if (group->num_children == 2 && list_is_singular(lvllist)) { /* * The target CPU must never do the prepare work, except * on early boot when the boot CPU is the target. Otherwise

2 weeks, 6 days

1
0
0 0

[PATCH v1 2/2] arm64: dts: qcom: ipq9574: Fix USB vdd info

by Varadarajan Narayanan

USB phys in ipq9574 use the 'L5' regulator. The commit ec4f047679d5 ("arm64: dts: qcom: ipq9574: Enable USB") incorrectly specified it as 'L2'. Because of this when the phy module turns off/on its regulators, 'L2' is turned off/on resulting in 2 issues, namely 'L5' is not turned off/on and the network module powered by the 'L2' is turned off/on. Cc: stable(a)vger.kernel.org Fixes: ec4f047679d5 ("arm64: dts: qcom: ipq9574: Enable USB") Signed-off-by: Varadarajan Narayanan <quic_varada(a)quicinc.com> --- arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi b/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi index ae12f069f26f..b24b795873d4 100644 --- a/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi +++ b/arch/arm64/boot/dts/qcom/ipq9574-rdp-common.dtsi @@ -111,6 +111,13 @@ mp5496_l2: l2 { regulator-always-on; regulator-boot-on; }; + + mp5496_l5: l5 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + }; }; }; @@ -146,7 +153,7 @@ &usb_0_dwc3 { }; &usb_0_qmpphy { - vdda-pll-supply = <&mp5496_l2>; + vdda-pll-supply = <&mp5496_l5>; vdda-phy-supply = <&regulator_fixed_0p925>; status = "okay"; @@ -154,7 +161,7 @@ &usb_0_qmpphy { &usb_0_qusbphy { vdd-supply = <&regulator_fixed_0p925>; - vdda-pll-supply = <&mp5496_l2>; + vdda-pll-supply = <&mp5496_l5>; vdda-phy-dpdm-supply = <&regulator_fixed_3p3>; status = "okay"; -- 2.34.1

2 weeks, 6 days

2
2
0 0

[PATCH net] rtnetlink: fix netns leak with rtnl_setlink()

by Nicolas Dichtel

A call to rtnl_nets_destroy() is needed to release references taken on netns put in rtnl_nets. CC: stable(a)vger.kernel.org Fixes: 636af13f213b ("rtnetlink: Register rtnl_dellink() and rtnl_setlink() with RTNL_FLAG_DOIT_PERNET_WIP.") Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> --- net/core/rtnetlink.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 1f4d4b5570ab..d1e559fce918 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -3432,6 +3432,7 @@ static int rtnl_setlink(struct sk_buff *skb, struct nlmsghdr *nlh, err = -ENODEV; rtnl_nets_unlock(&rtnl_nets); + rtnl_nets_destroy(&rtnl_nets); errout: return err; } -- 2.47.1

2 weeks, 6 days

3
2
0 0

[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>

2 weeks, 6 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

2 weeks, 6 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

2 weeks, 6 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

2 weeks, 6 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>

2 weeks, 6 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

2 weeks, 6 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

2 weeks, 6 days

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror