March 2024 - Linux-stable-mirror

[PATCH v3 3/5] Bluetooth: qca: fix device-address endianness

by Johan Hovold

The WCN6855 firmware on the Lenovo ThinkPad X13s expects the Bluetooth device address in big-endian order when setting it using the EDL_WRITE_BD_ADDR_OPCODE command. Presumably, this is the case for all non-ROME devices which all use the EDL_WRITE_BD_ADDR_OPCODE command for this (unlike the ROME devices which use a different command and expect the address in little-endian order). Reverse the little-endian address before setting it to make sure that the address can be configured using tools like btmgmt or using the 'local-bd-address' devicetree property. Note that this can potentially break systems with boot firmware which has started relying on the broken behaviour and is incorrectly passing the address via devicetree in big-endian order. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Cc: stable(a)vger.kernel.org # 5.1 Cc: Balakrishna Godavarthi <quic_bgodavar(a)quicinc.com> Cc: Matthias Kaehlcke <mka(a)chromium.org> Tested-by: Nikita Travkin <nikita(a)trvn.ru> # sc7180 Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/btqca.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index b40b32fa7f1c..19cfc342fc7b 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -826,11 +826,15 @@ EXPORT_SYMBOL_GPL(qca_uart_setup); int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr) { + bdaddr_t bdaddr_swapped; struct sk_buff *skb; int err; - skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, bdaddr, - HCI_EV_VENDOR, HCI_INIT_TIMEOUT); + baswap(&bdaddr_swapped, bdaddr); + + skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, + &bdaddr_swapped, HCI_EV_VENDOR, + HCI_INIT_TIMEOUT); if (IS_ERR(skb)) { err = PTR_ERR(skb); bt_dev_err(hdev, "QCA Change address cmd failed (%d)", err); -- 2.43.2

11 months, 3 weeks

3
5
0 0

[PATCH v3 5/5] arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as broken

by Johan Hovold

Several Qualcomm Bluetooth controllers lack persistent storage for the device address and instead one can be provided by the boot firmware using the 'local-bd-address' devicetree property. The Bluetooth bindings clearly states that the address should be specified in little-endian order, but due to a long-standing bug in the Qualcomm driver which reversed the address some boot firmware has been providing the address in big-endian order instead. The boot firmware in SC7180 Trogdor Chromebooks is known to be affected so mark the 'local-bd-address' property as broken to maintain backwards compatibility with older firmware when fixing the underlying driver bug. Note that ChromeOS always updates the kernel and devicetree in lockstep so that there is no need to handle backwards compatibility with older devicetrees. Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt") Cc: stable(a)vger.kernel.org # 5.10 Cc: Rob Clark <robdclark(a)chromium.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi index 46aaeba28604..ebe37678102f 100644 --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi @@ -943,6 +943,8 @@ bluetooth: bluetooth { vddrf-supply = <&pp1300_l2c>; vddch0-supply = <&pp3300_l10c>; max-speed = <3200000>; + + qcom,local-bd-address-broken; }; }; -- 2.43.2

11 months, 3 weeks

2
1
0 0

[PATCH 2/2] Bluetooth: qca: fix NULL-deref on non-serdev setup

by Johan Hovold

Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when setup() is called for a non-serdev controller. Fixes: e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") Cc: stable(a)vger.kernel.org # 6.2 Cc: Zhengping Jiang <jiangzp(a)google.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/hci_qca.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 84f728943962..6a69a7f9ef64 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1960,8 +1960,10 @@ static int qca_setup(struct hci_uart *hu) qca_debugfs_init(hdev); hu->hdev->hw_error = qca_hw_error; hu->hdev->cmd_timeout = qca_cmd_timeout; - if (device_can_wakeup(hu->serdev->ctrl->dev.parent)) - hu->hdev->wakeup = qca_wakeup; + if (hu->serdev) { + if (device_can_wakeup(hu->serdev->ctrl->dev.parent)) + hu->hdev->wakeup = qca_wakeup; + } } else if (ret == -ENOENT) { /* No patch/nvm-config found, run with original fw/config */ set_bit(QCA_ROM_FW, &qca->flags); -- 2.43.2

11 months, 3 weeks

1
0
0 0

[PATCH 1/2] Bluetooth: qca: fix NULL-deref on non-serdev suspend

by Johan Hovold

Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time. Fixes: c1a74160eaf1 ("Bluetooth: hci_qca: Add device_may_wakeup support") Cc: stable(a)vger.kernel.org # 5.13 Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index c73481c57741..84f728943962 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1672,6 +1672,9 @@ static bool qca_wakeup(struct hci_dev *hdev) struct hci_uart *hu = hci_get_drvdata(hdev); bool wakeup; + if (!hu->serdev) + return true; + /* BT SoC attached through the serial bus is handled by the serdev driver. * So we need to use the device handle of the serdev driver to get the * status of device may wakeup. -- 2.43.2

11 months, 3 weeks

1
0
0 0

[PATCH v3 4/5] Bluetooth: qca: add workaround for broken address properties

by Johan Hovold

Due to a long-standing bug in the Qualcomm Bluetooth driver, the device address has so far been reversed when configuring non-ROME controllers. This, in turn, has led to one vendor reversing the address that the boot firmware provides using the 'local-bd-address' devicetree property. The only device affected by this should be the WCN3991 used in some Chromebooks. As ChromeOS updates the kernel and devicetree in lockstep, the new 'qcom,local-bd-address-broken' property can be used to determine if the firmware is buggy so that the underlying driver bug can be fixed without breaking backwards compatibility. Set the HCI_QUIRK_BDADDR_PROPERTY_BROKEN quirk for such platforms so that the address is reversed when parsing the address property. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Cc: stable(a)vger.kernel.org # 5.1 Cc: Balakrishna Godavarthi <quic_bgodavar(a)quicinc.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/hci_qca.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index f989c05f8177..c73481c57741 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -225,6 +225,7 @@ struct qca_serdev { struct qca_power *bt_power; u32 init_speed; u32 oper_speed; + bool bdaddr_property_broken; const char *firmware_name; }; @@ -1842,6 +1843,7 @@ static int qca_setup(struct hci_uart *hu) const char *firmware_name = qca_get_firmware_name(hu); int ret; struct qca_btsoc_version ver; + struct qca_serdev *qcadev; const char *soc_name; ret = qca_check_speeds(hu); @@ -1904,6 +1906,11 @@ static int qca_setup(struct hci_uart *hu) case QCA_WCN6855: case QCA_WCN7850: set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); + + qcadev = serdev_device_get_drvdata(hu->serdev); + if (qcadev->bdaddr_property_broken) + set_bit(HCI_QUIRK_BDADDR_PROPERTY_BROKEN, &hdev->quirks); + hci_set_aosp_capable(hdev); ret = qca_read_soc_version(hdev, &ver, soc_type); @@ -2284,6 +2291,9 @@ static int qca_serdev_probe(struct serdev_device *serdev) if (!qcadev->oper_speed) BT_DBG("UART will pick default operating speed"); + qcadev->bdaddr_property_broken = device_property_read_bool(&serdev->dev, + "qcom,local-bd-address-broken"); + if (data) qcadev->btsoc_type = data->soc_type; else -- 2.43.2

11 months, 3 weeks

1
0
0 0

Re: Patch "selftests: mptcp: explicitly trigger the listener diag code-path" has been added to the 6.7-stable tree

by Matthieu Baerts

Hi Sasha, On 19/03/2024 00:00, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > selftests: mptcp: explicitly trigger the listener diag code-path > > to the 6.7-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > selftests-mptcp-explicitly-trigger-the-listener-diag.patch > and it can be found in the queue-6.7 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. I do :) > commit 02dc7e7327bc1a3551665745a40029cf96d6a8e6 > Author: Paolo Abeni <pabeni(a)redhat.com> > Date: Fri Feb 23 17:14:20 2024 +0100 > > selftests: mptcp: explicitly trigger the listener diag code-path > > [ Upstream commit b4b51d36bbaa3ddb93b3e1ca3a1ef0aa629d6521 ] I think something went wrong: this patch was not supposed to be added to both 6.6 and 6.7 queues: https://lore.kernel.org/stable/Zfg36tcGXUsZnJCh@sashalap/ Do you mind dropping them from both queues, please? Cheers, Matt -- Sponsored by the NGI0 Core fund.

11 months, 3 weeks

2
1
0 0

[PATCH v3 1/1] driver core: Keep the supplier fwnode consistent with the device

by Herve Codina

The commit 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") introduces the possibility to use the supplier's parent device instead of the supplier itself. In that case the supplier fwnode used is not updated and is no more consistent with the supplier device used. Use the fwnode consistent with the supplier device when checking flags. Fixes: 3a2dbc510c43 ("driver core: fw_devlink: Don't purge child fwnode's consumer links") Cc: stable(a)vger.kernel.org Signed-off-by: Herve Codina <herve.codina(a)bootlin.com> --- Changes v2 -> v3: Do not update the supplier handle in order to keep the original handle for debug traces. Changes v1 -> v2: Remove sup_handle check and related pr_debug() call as sup_handle cannot be invalid if sup_dev is valid. drivers/base/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 4d8b315c48a1..440b52ec027f 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2082,7 +2082,7 @@ static int fw_devlink_create_devlink(struct device *con, * supplier device indefinitely. */ if (sup_dev->links.status == DL_DEV_NO_DRIVER && - sup_handle->flags & FWNODE_FLAG_INITIALIZED) { + sup_dev->fwnode->flags & FWNODE_FLAG_INITIALIZED) { dev_dbg(con, "Not linking %pfwf - dev might never probe\n", sup_handle); -- 2.41.0

11 months, 3 weeks

2
3
0 0

[REGRESSION] 6.7.1: md: raid5 hang and unresponsive system; successfully bisected

by Dan Moulding

After upgrading from 6.7.0 to 6.7.1 a couple of my systems with md RAID-5 arrays started experiencing hangs. It starts with some processes which write to the array getting stuck. The whole system eventually becomes unresponsive and unclean shutdown must be performed (poweroff and reboot don't work). While trying to diagnose the issue, I noticed that the md0_raid5 kernel thread consumes 100% CPU after the issue occurs. No relevant warnings or errors were found in dmesg. On 6.7.1, I can reproduce the issue somewhat reliably by copying a large amount of data to the array. I am unable to reproduce the issue at all on 6.7.0. The bisection was a bit difficult since I don't have a 100% reliable method to reproduce the problem, but with some perseverence I eventually managed to whittle it down to commit 0de40f76d567 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"). After reverting that commit (i.e. reapplying the reverted commit) on top of 6.7.1 I can no longer reproduce the problem at all. Some details that might be relevant: - Both systems are running MD RAID-5 with a journal device. - mdadm in monitor mode is always running on both systems. - Both systems were previously running 6.7.0 and earlier just fine. - The older of the two systems has been running a raid5 array without incident for many years (kernel going back to at least 5.1) -- this is the first raid5 issue it has encountered. Please let me know if there is any other helpful information that I might be able to provide. -- Dan #regzbot introduced: 0de40f76d567133b871cd6ad46bb87afbce46983

11 months, 3 weeks

9
52
0 0

[PATCH] ahci: asm1064: asm1166: don't limit reported ports

by Conrad Kostecki

Previously, patches have been added to limit the reported count of SATA ports for asm1064 and asm1166 SATA controllers, as those controllers do report more ports than physical having. Unfortunately, this causes trouble for users, which are using SATA controllers, which provide more ports through SATA PMP (Port-MultiPlier) and are now not any more recognized. This happens, as asm1064 and 1166 are handling SATA PMP transparently, so all non-physical ports needs to be enabled to use that feature. This patch reverts both patches for asm1064 and asm1166, so old behavior is restored and SATA PMP will work again, so all physical and non-physical ports will work again. Fixes: 0077a504e1a4 ("ahci: asm1166: correct count of reported ports") Fixes: 9815e3961754 ("ahci: asm1064: correct count of reported ports") Cc: stable(a)vger.kernel.org Reported-by: Matt <cryptearth(a)googlemail.com> Signed-off-by: Conrad Kostecki <conikost(a)gentoo.org> --- drivers/ata/ahci.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index 78570684ff68..562302e2e57c 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -669,19 +669,6 @@ MODULE_PARM_DESC(mobile_lpm_policy, "Default LPM policy for mobile chipsets"); static void ahci_pci_save_initial_config(struct pci_dev *pdev, struct ahci_host_priv *hpriv) { - if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA) { - switch (pdev->device) { - case 0x1166: - dev_info(&pdev->dev, "ASM1166 has only six ports\n"); - hpriv->saved_port_map = 0x3f; - break; - case 0x1064: - dev_info(&pdev->dev, "ASM1064 has only four ports\n"); - hpriv->saved_port_map = 0xf; - break; - } - } - if (pdev->vendor == PCI_VENDOR_ID_JMICRON && pdev->device == 0x2361) { dev_info(&pdev->dev, "JMB361 has only one port\n"); hpriv->saved_port_map = 1; -- 2.44.0

11 months, 3 weeks

3
2
0 0

[PATCH v4 4/9] ext4: fix slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists()

by Baokun Li

We can trigger a slab-out-of-bounds with the following commands: mkfs.ext4 -F /dev/$disk 10G mount /dev/$disk /tmp/test echo 2147483647 > /sys/fs/ext4/$disk/mb_group_prealloc echo test > /tmp/test/file && sync ================================================================== BUG: KASAN: slab-out-of-bounds in ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] Read of size 8 at addr ffff888121b9d0f0 by task kworker/u2:0/11 CPU: 0 PID: 11 Comm: kworker/u2:0 Tainted: GL 6.7.0-next-20240118 #521 Call Trace: dump_stack_lvl+0x2c/0x50 kasan_report+0xb6/0xf0 ext4_mb_find_good_group_avg_frag_lists+0x8a/0x200 [ext4] ext4_mb_regular_allocator+0x19e9/0x2370 [ext4] ext4_mb_new_blocks+0x88a/0x1370 [ext4] ext4_ext_map_blocks+0x14f7/0x2390 [ext4] ext4_map_blocks+0x569/0xea0 [ext4] ext4_do_writepages+0x10f6/0x1bc0 [ext4] [...] ================================================================== The flow of issue triggering is as follows: // Set s_mb_group_prealloc to 2147483647 via sysfs ext4_mb_new_blocks ext4_mb_normalize_request ext4_mb_normalize_group_request ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc ext4_mb_regular_allocator ext4_mb_choose_next_group ext4_mb_choose_next_group_best_avail mb_avg_fragment_size_order order = fls(len) - 2 = 29 ext4_mb_find_good_group_avg_frag_lists frag_list = &sbi->s_mb_avg_fragment_size[order] if (list_empty(frag_list)) // Trigger SOOB! At 4k block size, the length of the s_mb_avg_fragment_size list is 14, but an oversized s_mb_group_prealloc is set, causing slab-out-of-bounds to be triggered by an attempt to access an element at index 29. Add a new attr_id attr_clusters_in_group with values in the range [0, sbi->s_clusters_per_group] and declare mb_group_prealloc as that type to fix the issue. In addition avoid returning an order from mb_avg_fragment_size_order() greater than MB_NUM_ORDERS(sb) and reduce some useless loops. Fixes: 7e170922f06b ("ext4: Add allocation criteria 1.5 (CR1_5)") CC: stable(a)vger.kernel.org Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Ojaswin Mujoo <ojaswin(a)linux.ibm.com> --- fs/ext4/mballoc.c | 4 ++++ fs/ext4/sysfs.c | 13 ++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 12b3f196010b..dbf04f91516c 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -831,6 +831,8 @@ static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len) return 0; if (order == MB_NUM_ORDERS(sb)) order--; + if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb))) + order = MB_NUM_ORDERS(sb) - 1; return order; } @@ -1008,6 +1010,8 @@ static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context * goal length. */ order = fls(ac->ac_g_ex.fe_len) - 1; + if (WARN_ON_ONCE(order - 1 > MB_NUM_ORDERS(ac->ac_sb))) + order = MB_NUM_ORDERS(ac->ac_sb); min_order = order - sbi->s_mb_best_avail_max_trim_order; if (min_order < 0) min_order = 0; diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c index 7f455b5f22c0..ddd71673176c 100644 --- a/fs/ext4/sysfs.c +++ b/fs/ext4/sysfs.c @@ -29,6 +29,7 @@ typedef enum { attr_trigger_test_error, attr_first_error_time, attr_last_error_time, + attr_clusters_in_group, attr_feature, attr_pointer_ui, attr_pointer_ul, @@ -207,13 +208,14 @@ EXT4_ATTR_FUNC(sra_exceeded_retry_limit, 0444); EXT4_ATTR_OFFSET(inode_readahead_blks, 0644, inode_readahead, ext4_sb_info, s_inode_readahead_blks); +EXT4_ATTR_OFFSET(mb_group_prealloc, 0644, clusters_in_group, + ext4_sb_info, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(inode_goal, s_inode_goal); EXT4_RW_ATTR_SBI_UI(mb_stats, s_mb_stats); EXT4_RW_ATTR_SBI_UI(mb_max_to_scan, s_mb_max_to_scan); EXT4_RW_ATTR_SBI_UI(mb_min_to_scan, s_mb_min_to_scan); EXT4_RW_ATTR_SBI_UI(mb_order2_req, s_mb_order2_reqs); EXT4_RW_ATTR_SBI_UI(mb_stream_req, s_mb_stream_request); -EXT4_RW_ATTR_SBI_UI(mb_group_prealloc, s_mb_group_prealloc); EXT4_RW_ATTR_SBI_UI(mb_max_linear_groups, s_mb_max_linear_groups); EXT4_RW_ATTR_SBI_UI(extent_max_zeroout_kb, s_extent_max_zeroout_kb); EXT4_ATTR(trigger_fs_error, 0200, trigger_test_error); @@ -376,6 +378,7 @@ static ssize_t ext4_generic_attr_show(struct ext4_attr *a, switch (a->attr_id) { case attr_inode_readahead: + case attr_clusters_in_group: case attr_pointer_ui: if (a->attr_ptr == ptr_ext4_super_block_offset) return sysfs_emit(buf, "%u\n", le32_to_cpup(ptr)); @@ -455,6 +458,14 @@ static ssize_t ext4_generic_attr_store(struct ext4_attr *a, else *((unsigned int *) ptr) = t; return len; + case attr_clusters_in_group: + ret = kstrtouint(skip_spaces(buf), 0, &t); + if (ret) + return ret; + if (t > sbi->s_clusters_per_group) + return -EINVAL; + *((unsigned int *) ptr) = t; + return len; case attr_pointer_ul: ret = kstrtoul(skip_spaces(buf), 0, &lt); if (ret) -- 2.31.1

11 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024