March 2024 - Linux-stable-mirror

[PATCHi 6.6 0/1] Cherrypick one more commit to fix iwlwifi crash on BE200

by Aaron Ma

Hi Levin, On Stable 6.6.23 kernel, iwlwifi crashed with the following error: [ 290.279712] ------------[ cut here ]------------ [ 290.279726] Invalid rxb from HW 0 [ 290.279816] WARNING: CPU: 19 PID: 477 at drivers/net/wireless/intel/iwlwifi/pcie/rx.c:1489 iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.279885] Modules linked in: snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_realtek snd_hda_codec_generic rfcomm nvme_fabrics ccm cmac algif_hash algif_skcipher af_alg bnep uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videodev btusb btrtl btintel btbcm btmtk videobuf2_common bluetooth mc ecdh_generic ecc joydev snd_soc_dmic intel_uncore_frequency intel_uncore_frequency_common snd_sof_pci_intel_mtl snd_sof_intel_hda_common x86_pkg_temp_thermal soundwire_intel intel_powerclamp soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp coretemp snd_sof snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core kvm_intel snd_soc_acpi_intel_match snd_soc_acpi soundwire_bus kvm snd_soc_core irqbypass snd_compress crct10dif_pclmul ac97_bus crc32_pclmul snd_pcm_dmaengine polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 iwlmvm snd_hda_intel sha256_ssse3 binfmt_misc sha1_ssse3 i915 [ 290.279973] snd_intel_dspcfg drm_buddy aesni_intel snd_intel_sdw_acpi ttm mac80211 crypto_simd processor_thermal_device_pci snd_hda_codec drm_display_helper spi_nor hid_multitouch processor_thermal_device cryptd think_lmi pmt_telemetry hid_generic libarc4 mtd intel_rapl_msr pmt_class iwlwifi firmware_attributes_class wmi_bmof snd_hda_core cec processor_thermal_rfim rapl snd_hwdep psmouse thinkpad_acpi input_leds rc_core mei_me snd_seq_midi ucsi_acpi processor_thermal_mbox intel_cstate intel_lpss_pci snd_seq_midi_event typec_ucsi processor_thermal_rapl nvram i2c_i801 intel_lpss xhci_pci drm_kms_helper spi_intel_pci ledtrig_audio cfg80211 snd_pcm e1000e thunderbolt serio_raw platform_profile mei i2c_smbus spi_intel typec idma64 xhci_pci_renesas i2c_algo_bit intel_vsec intel_rapl_common snd_rawmidi mac_hid snd_seq snd_seq_device snd_timer i2c_hid_acpi i2c_hid hid snd soundcore video int3403_thermal int340x_thermal_zone wmi acpi_tad acpi_pad intel_pmc_core intel_hid int3400_thermal pinctrl_meteorlake sparse_keymap [ 290.280076] acpi_thermal_rel sch_fq_codel msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables autofs4 [ 290.280097] CPU: 19 PID: 477 Comm: irq/182-iwlwifi Not tainted 6.6.23 #75 [ 290.280104] Hardware name: LENOVO 21ML0SIT12/21ML0SIT12, BIOS N47ET13W (1.02 ) 02/17/2024 [ 290.280108] RIP: 0010:iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280156] Code: 8b 8d 6c ff ff ff 4c 89 f2 4c 89 e6 4c 89 ef e8 4a f4 ff ff e9 08 fe ff ff 4d 89 ef 89 d6 48 c7 c7 c5 6c bf c0 e8 44 1d 36 fb <0f> 0b 4c 89 ff e8 1a 48 ff ff e9 9e fe ff ff 0f 1f 44 00 00 e9 f6 [ 290.280161] RSP: 0018:ffffc900004e0de8 EFLAGS: 00010246 [ 290.280167] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 290.280170] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 290.280173] RBP: ffffc900004e0e98 R08: 0000000000000000 R09: 0000000000000000 [ 290.280176] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88811dd27f88 [ 290.280179] R13: ffff888119ae8028 R14: ffff88812c4a0000 R15: ffff888119ae8028 [ 290.280182] FS: 0000000000000000(0000) GS:ffff8882214c0000(0000) knlGS:0000000000000000 [ 290.280187] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 290.280191] CR2: 00007f914800ba8c CR3: 000000020e83a005 CR4: 0000000000770ee0 [ 290.280195] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 290.280198] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 290.280201] PKRU: 55555554 [ 290.280204] Call Trace: [ 290.280208] <IRQ> [ 290.280214] ? show_regs+0x72/0x90 [ 290.280225] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280269] ? __warn+0x8d/0x160 [ 290.280278] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280324] ? report_bug+0x1bb/0x1d0 [ 290.280335] ? console_unlock+0x77/0x130 [ 290.280346] ? handle_bug+0x46/0x90 [ 290.280354] ? exc_invalid_op+0x19/0x80 [ 290.280360] ? asm_exc_invalid_op+0x1b/0x20 [ 290.280369] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280412] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280457] iwl_pcie_napi_poll_msix+0x30/0x100 [iwlwifi] [ 290.280500] ? try_to_wake_up+0x278/0x6c0 [ 290.280507] __napi_poll+0x30/0x1f0 [ 290.280515] net_rx_action+0x190/0x300 [ 290.280521] ? __irq_wake_thread+0x42/0x50 [ 290.280529] __do_softirq+0xda/0x330 [ 290.280533] ? handle_edge_irq+0xda/0x250 [ 290.280540] ? __pfx_irq_thread_fn+0x10/0x10 [ 290.280547] do_softirq.part.0+0x41/0x80 [ 290.280557] </IRQ> [ 290.280559] <TASK> [ 290.280562] __local_bh_enable_ip+0x72/0x80 [ 290.280570] iwl_pcie_irq_rx_msix_handler+0xd7/0x1c0 [iwlwifi] [ 290.280644] irq_thread_fn+0x25/0x70 [ 290.280653] irq_thread+0xea/0x1c0 [ 290.280660] ? __pfx_irq_thread_dtor+0x10/0x10 [ 290.280668] ? __pfx_irq_thread+0x10/0x10 [ 290.280675] kthread+0xf4/0x130 [ 290.280683] ? __pfx_kthread+0x10/0x10 [ 290.280690] ret_from_fork+0x43/0x70 [ 290.280697] ? __pfx_kthread+0x10/0x10 [ 290.280704] ret_from_fork_asm+0x1b/0x30 [ 290.280712] </TASK> [ 290.280715] ---[ end trace 0000000000000000 ]--- [ 290.281118] iwlwifi 0000:09:00.0: Microcode SW error detected. Restarting 0x0. Found the first bad commit c1c1039135c3 ("wifi: iwlwifi: increase number of RX buffers for EHT devices") Another commit should be along with it: commit 9f9797c7de18 ("wifi: iwlwifi: pcie: fix RB status reading") BugLink: https://bugs.launchpad.net/bugs/2058808 Johannes Berg (1): wifi: iwlwifi: pcie: fix RB status reading drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 8 ++++---- drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 12 ++++-------- 3 files changed, 9 insertions(+), 13 deletions(-) -- 2.34.1

1 year, 6 months

2
2
0 0

Pull ASoC amd fixes into stable

by Luca Stefani

Hey stable folks, Can the following patches found in mainline [PATCH] ASoC: amd: yc: Revert "Fix non-functional mic on Lenovo 21J2" (861b341) [PATCH] ASoC: amd: yc: Revert "add new YC platform variant (0x63) support" (37bee18) be backported to linux-6.8.y? They're improperly assuming the 0x63 variant is part of the Yellow Carp family. This causes the microphone input device to not being properly probed on the device. Known broken devices: ThinkPad P16s Gen 2 (21K9CTO1WW) Thanks, Luca.

1 year, 6 months

2
1
0 0

Re: [PATCH 0/2] Revert "ASoC: amd: yc: add new YC platform variant (0x63) support"

by Luca Stefani

Hello everyone, Can those changes be pulled in stable? They're currently breaking mic input on my 21K9CTO1WW, ThinkPad P16s Gen 2, and probably more devices in the wild. Thanks, Luca. On 12/03/24 03:33, Jiawei Wang wrote: > Please revert my previous two commits: > > ASoC: amd: yc: add new YC platform variant (0x63) support > [ Upstream commit 316a784839b21b122e1761cdca54677bb19a47fa ] > > ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2 > [ Upstream commit ed00a6945dc32462c2d3744a3518d2316da66fcc ] > > PCI revision id 0x63 is the Pink Sardine (PS) platform, not Yellow > Carp (YC). Thanks to Mukunda Vijendar [1] for pointing out that. > > The mic on Lenovo 21J2 works after enabling the CONFIG_SND_SOC_AMD_PS > flag, which I had not enabled when I was writing these patches. 21J2 > does not need to be in this quirk table. > > I apologize for the inconvenience caused. > > Link: https://lore.kernel.org/linux-sound/023092e1-689c-4b00-b93f-4092c3724fb6@am… [1] > > Signed-off-by: Jiawei Wang <me(a)jwang.link> > > Jiawei Wang (2): > Revert "ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2" > Revert "ASoC: amd: yc: add new YC platform variant (0x63) support" > > sound/soc/amd/yc/acp6x-mach.c | 7 ------- > sound/soc/amd/yc/pci-acp6x.c | 1 - > 2 files changed, 8 deletions(-) >

1 year, 6 months

3
5
0 0

FAILED: Patch "x86/efistub: Call mixed mode boot services on the firmware's stack" failed to apply to 6.8-stable tree

by Sasha Levin

The patch below does not apply to the 6.8-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Thanks, Sasha ------------------ original commit in Linus's tree ------------------ From cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ardb(a)kernel.org> Date: Fri, 22 Mar 2024 17:03:58 +0200 Subject: [PATCH] x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. Cc: <stable(a)kernel.org> # v6.1+ Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- arch/x86/boot/compressed/efi_mixed.S | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/x86/boot/compressed/efi_mixed.S b/arch/x86/boot/compressed/efi_mixed.S index f4e22ef774ab6..719e939050cbf 100644 --- a/arch/x86/boot/compressed/efi_mixed.S +++ b/arch/x86/boot/compressed/efi_mixed.S @@ -49,6 +49,11 @@ SYM_FUNC_START(startup_64_mixed_mode) lea efi32_boot_args(%rip), %rdx mov 0(%rdx), %edi mov 4(%rdx), %esi + + /* Switch to the firmware's stack */ + movl efi32_boot_sp(%rip), %esp + andl $~7, %esp + #ifdef CONFIG_EFI_HANDOVER_PROTOCOL mov 8(%rdx), %edx // saved bootparams pointer test %edx, %edx @@ -254,6 +259,9 @@ SYM_FUNC_START_LOCAL(efi32_entry) /* Store firmware IDT descriptor */ sidtl (efi32_boot_idt - 1b)(%ebx) + /* Store firmware stack pointer */ + movl %esp, (efi32_boot_sp - 1b)(%ebx) + /* Store boot arguments */ leal (efi32_boot_args - 1b)(%ebx), %ebx movl %ecx, 0(%ebx) @@ -318,5 +326,6 @@ SYM_DATA_END(efi32_boot_idt) SYM_DATA_LOCAL(efi32_boot_cs, .word 0) SYM_DATA_LOCAL(efi32_boot_ds, .word 0) +SYM_DATA_LOCAL(efi32_boot_sp, .long 0) SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0, 0) SYM_DATA(efi_is64, .byte 1) -- 2.43.0

1 year, 6 months

3
5
0 0

[PATCH] tools/resolve_btfids: fix build with musl libc

by Natanael Copa

Include the header that defines u32. Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218647 Cc: stable(a)vger.kernel.org Signed-off-by: Natanael Copa <ncopa(a)alpinelinux.org> --- This fixes build of 6.6.23 and 6.1.83 kernels for Alpine Linux, which uses musl libc. I assume that GNU libc indirecly pulls in linux/types.h. tools/include/linux/btf_ids.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/include/linux/btf_ids.h b/tools/include/linux/btf_ids.h index 72535f00572f..72ea363d434d 100644 --- a/tools/include/linux/btf_ids.h +++ b/tools/include/linux/btf_ids.h @@ -3,6 +3,8 @@ #ifndef _LINUX_BTF_IDS_H #define _LINUX_BTF_IDS_H +#include <linux/types.h> /* for u32 */ + struct btf_id_set { u32 cnt; u32 ids[]; -- 2.44.0

1 year, 6 months

4
3
0 0

[PATCH v2] fs/proc/proc_sysctl.c: always initialize i_uid/i_gid

by Thomas Weißschuh

Commit e79c6a4fc923 ("net: make net namespace sysctls belong to container's owner") added default values for i_uid/i_gid. These however are only used when ctl_table_root->set_ownership is not implemented. But the callbacks themselves could fail to compute i_uid/i_gid and they all need to have the same fallback logic for this case. This is unnecessary code duplication and prone to errors. For example net_ctl_set_ownership() missed the fallback. Instead always initialize i_uid/i_gid inside the sysfs core so set_ownership() can safely skip setting them. Fixes: e79c6a4fc923 ("net: make net namespace sysctls belong to container's owner") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v2: - Move the fallback logic to the sysctl core - Link to v1: https://lore.kernel.org/r/20240315-sysctl-net-ownership-v1-1-2b465555a292@w… --- fs/proc/proc_sysctl.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c index 37cde0efee57..9e34ab9c21e4 100644 --- a/fs/proc/proc_sysctl.c +++ b/fs/proc/proc_sysctl.c @@ -479,12 +479,10 @@ static struct inode *proc_sys_make_inode(struct super_block *sb, make_empty_dir_inode(inode); } + inode->i_uid = GLOBAL_ROOT_UID; + inode->i_gid = GLOBAL_ROOT_GID; if (root->set_ownership) root->set_ownership(head, table, &inode->i_uid, &inode->i_gid); - else { - inode->i_uid = GLOBAL_ROOT_UID; - inode->i_gid = GLOBAL_ROOT_GID; - } return inode; } --- base-commit: ff9c18e435b042596c9d48badac7488e3fa76a55 change-id: 20240315-sysctl-net-ownership-bc4e17eaeea6 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

1 year, 6 months

3
2
0 0

[PATCH] drm/vkms: fix memory leak when drm_gem_handle_create() fails

by Salomatkina Elena

If drm_gem_handle_create() fails in vkms_gem_create(), then the vkms_gem_object is not freed. Fix it by adding a call to vkms_gem_free_object(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 0ea2ea42b31a ("drm/vkms: Hold gem object while still in-use") Cc: stable(a)vger.kernel.org#v5.10.212 #Co-developed-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Signed-off-by: Salomatkina Elena <elena.salomatkina.cmc(a)gmail.com> --- drivers/gpu/drm/vkms/vkms_gem.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c index a017fc59905e..cc6584767a1b 100644 --- a/drivers/gpu/drm/vkms/vkms_gem.c +++ b/drivers/gpu/drm/vkms/vkms_gem.c @@ -113,9 +113,10 @@ static struct drm_gem_object *vkms_gem_create(struct drm_device *dev, return ERR_CAST(obj); ret = drm_gem_handle_create(file, &obj->gem, handle); - if (ret) + if (ret) { + vkms_gem_free_object(&obj->gem); return ERR_PTR(ret); - + } return &obj->gem; } -- 2.34.1

1 year, 6 months

1
0
0 0

[PATCH RESEND 0/2] usb: typec: tipd: fix event checking in interrupt service routines

by Javier Carrasco

The ISRs of the tps25750 and tps6598x do not handle generated events properly under all circumstances. The tps6598x ISR does not read all bits of the INT_EVENTX registers, leaving events signaled with bits above 64 unattended. Moreover, these events are not cleared, leaving the interrupt enabled. The tps25750 reads all bits of the INT_EVENT1 register, but the event checking is not right because the same event is checked in two different regions of the same register by means of an OR operation. This series aims to fix both issues by reading all bits of the INT_EVENTX registers, and limiting the event checking to the region where the supported events are defined (currently they are limited to the first 64 bits of the registers, as the are defined as BIT_ULL()). If the need for events above the first 64 bits of the INT_EVENTX registers arises, a different mechanism might be required. But for the current needs, all definitions can be left as they are. Note: resend to add 'stable' mailing list (fixes in the series). Signed-off-by: Javier Carrasco <javier.carrasco(a)wolfvision.net> --- Javier Carrasco (2): usb: typec: tipd: fix event checking for tps25750 usb: typec: tipd: fix event checking for tps6598x drivers/usb/typec/tipd/core.c | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-) --- base-commit: 4cece764965020c22cff7665b18a012006359095 change-id: 20240328-tps6598x_fix_event_handling-8fff3a6018d9 Best regards, -- Javier Carrasco <javier.carrasco(a)wolfvision.net>

1 year, 6 months

3
5
0 0

[PATCH v2] media: ov2680: Clear the 'ret' variable on success

by Fabio Estevam

From: Fabio Estevam <festevam(a)denx.de> Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") even when the correct 'link-frequencies' property is passed in the devicetree, the driver fails to probe: ov2680 1-0036: probe with driver ov2680 failed with error -22 The reason is that the variable 'ret' may contain the -EINVAL value from a previous assignment: ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency", &rate); Fix the problem by clearing 'ret' on the successful path. Tested on imx7s-warp board with the following devicetree: port { ov2680_to_mipi: endpoint { remote-endpoint = <&mipi_from_sensor>; clock-lanes = <0>; data-lanes = <1>; link-frequencies = /bits/ 64 <330000000>; }; }; Cc: stable(a)vger.kernel.org Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") Suggested-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Changes since v1: - Use Hans' suggestion to clear 'ret'. drivers/media/i2c/ov2680.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c index 39d321e2b7f9..3e3b7c2b492c 100644 --- a/drivers/media/i2c/ov2680.c +++ b/drivers/media/i2c/ov2680.c @@ -1135,6 +1135,7 @@ static int ov2680_parse_dt(struct ov2680_dev *sensor) goto out_free_bus_cfg; } + ret = 0; out_free_bus_cfg: v4l2_fwnode_endpoint_free(&bus_cfg); return ret; -- 2.34.1

1 year, 6 months

2
1
0 0

Please backport commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs)

by Paul Menzel

Dear Linux folks, Please apply commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD EEPROMs) [1] to the stable series to get rid of a warning and to support more SPDs. That commit is present since v6.8-rc1. Kind regards, Paul [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…

1 year, 6 months

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024