September 2023 - Linux-stable-mirror

[Revert] Re: Possible nvme regression in 6.4.11

by Jade Lovelace

This regression affects all copies of the Dell XPS 15 9560 and Dell Precision 5520 with any SSD including aftermarket ones. Per the bugzilla discussion here: https://bugzilla.kernel.org/show_bug.cgi?id=217802 this regression has been confirmed to also affect 6.5.2 and 6.6-rc1, and affects several distros. Known affected branches: 6.1, 6.4, 6.5, 6.6. It has already been reverted by OpenSUSE and is soon to be reverted in NixOS. A patch follows, hopefully with the right metadata tags. I have compiled a kernel 6.1 with the revert and confirmed it now boots again. p.s. this is my first time pointing git-send-email at this particular list, so I'm sorry if I got anything wrong. Jade

2 years, 2 months

1
0
0 0

[PATCH AUTOSEL 6.4 01/25] media: mdp3: Fix resource leaks in of_find_device_by_node

by Sasha Levin

From: Lu Hongfei <luhongfei(a)vivo.com> [ Upstream commit 35ca8ce495366909b4c2e701d1356570dd40c4e2 ] Use put_device to release the object get through of_find_device_by_node, avoiding resource leaks. Signed-off-by: Lu Hongfei <luhongfei(a)vivo.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c index 19a4a085f73a1..1fe10a21e395a 100644 --- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c +++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c @@ -892,11 +892,13 @@ static int mdp_get_subsys_id(struct mdp_dev *mdp, struct device *dev, ret = cmdq_dev_get_client_reg(&comp_pdev->dev, &cmdq_reg, index); if (ret != 0) { dev_err(&comp_pdev->dev, "cmdq_dev_get_subsys fail!\n"); + put_device(&comp_pdev->dev); return -EINVAL; } comp->subsys_id = cmdq_reg.subsys; dev_dbg(&comp_pdev->dev, "subsys id=%d\n", cmdq_reg.subsys); + put_device(&comp_pdev->dev); return 0; } -- 2.40.1

2 years, 2 months

4
29
0 0

[PATCH v6] driver core: platform: set numa_node before platform_device_add()

by Jinhui Guo

Setting the devices' numa_node needs to be done in platform_device_register_full(), because that's where the platform device object is allocated. Fixes: 4a60406d3592 ("driver core: platform: expose numa_node to users in sysfs") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309122309.mbxAnAIe-lkp@intel.com/ Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Reviewed-by: Rafael J. Wysocki <rafael(a)kernel.org> Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- V5 -> V6: 1. Update subject to correct function name platform_device_add(). 2. Provide a more clear and accurate description of the changes made in commit (suggested by Rafael J. Wysocki). 3. Add reviewer name. V4 -> V5: Add Cc: stable line and changes from the previous submited patches. V3 -> V4: Refactor code to be an ACPI function call. V2 -> V3: Fix Signed-off name. V1 -> V2: Fix compile error without enabling CONFIG_ACPI. --- drivers/acpi/acpi_platform.c | 4 +--- drivers/base/platform.c | 1 + include/linux/acpi.h | 5 +++++ 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 48d15dd785f6..adcbfbdc343f 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -178,11 +178,9 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev, if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); - else { - set_dev_node(&pdev->dev, acpi_get_node(adev->handle)); + else dev_dbg(&adev->dev, "created platform device %s\n", dev_name(&pdev->dev)); - } kfree(resources); diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 76bfcba25003..35c891075d95 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -841,6 +841,7 @@ struct platform_device *platform_device_register_full( goto err; } + set_dev_node(&pdev->dev, ACPI_NODE_GET(ACPI_COMPANION(&pdev->dev))); ret = platform_device_add(pdev); if (ret) { err: diff --git a/include/linux/acpi.h b/include/linux/acpi.h index a73246c3c35e..6a349d53f19e 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -477,6 +477,10 @@ static inline int acpi_get_node(acpi_handle handle) return 0; } #endif + +#define ACPI_NODE_GET(adev) ((adev) && (adev)->handle ? \ + acpi_get_node((adev)->handle) : NUMA_NO_NODE) + extern int pnpacpi_disabled; #define PXM_INVAL (-1) @@ -770,6 +774,7 @@ const char *acpi_get_subsystem_id(acpi_handle handle); #define ACPI_COMPANION_SET(dev, adev) do { } while (0) #define ACPI_HANDLE(dev) (NULL) #define ACPI_HANDLE_FWNODE(fwnode) (NULL) +#define ACPI_NODE_GET(adev) NUMA_NO_NODE #include <acpi/acpi_numa.h> -- 2.20.1

2 years, 2 months

3
5
0 0

[PATCH v5] driver core: platform: set numa_node before platform_add_device()

by Jinhui Guo

platform_add_device() creates the numa_node attribute of sysfs according to whether dev_to_node(dev) is equal to NUMA_NO_NODE. So set the numa node of device before creating numa_node attribute of sysfs. Fixes: 4a60406d3592 ("driver core: platform: expose numa_node to users in sysfs") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202309122309.mbxAnAIe-lkp@intel.com/ Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- V4 -> V5: Add Cc: stable line and changes from the previous submited patches V3 -> V4: Refactor code to be an ACPI function call V2 -> V3: Fix Signed-off name V1 -> V2: Fix compile error without enabling CONFIG_ACPI drivers/acpi/acpi_platform.c | 4 +--- drivers/base/platform.c | 1 + include/linux/acpi.h | 5 +++++ 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 48d15dd785f6..adcbfbdc343f 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -178,11 +178,9 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev, if (IS_ERR(pdev)) dev_err(&adev->dev, "platform device creation failed: %ld\n", PTR_ERR(pdev)); - else { - set_dev_node(&pdev->dev, acpi_get_node(adev->handle)); + else dev_dbg(&adev->dev, "created platform device %s\n", dev_name(&pdev->dev)); - } kfree(resources); diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 76bfcba25003..35c891075d95 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -841,6 +841,7 @@ struct platform_device *platform_device_register_full( goto err; } + set_dev_node(&pdev->dev, ACPI_NODE_GET(ACPI_COMPANION(&pdev->dev))); ret = platform_device_add(pdev); if (ret) { err: diff --git a/include/linux/acpi.h b/include/linux/acpi.h index a73246c3c35e..6a349d53f19e 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -477,6 +477,10 @@ static inline int acpi_get_node(acpi_handle handle) return 0; } #endif + +#define ACPI_NODE_GET(adev) ((adev) && (adev)->handle ? \ + acpi_get_node((adev)->handle) : NUMA_NO_NODE) + extern int pnpacpi_disabled; #define PXM_INVAL (-1) @@ -770,6 +774,7 @@ const char *acpi_get_subsystem_id(acpi_handle handle); #define ACPI_COMPANION_SET(dev, adev) do { } while (0) #define ACPI_HANDLE(dev) (NULL) #define ACPI_HANDLE_FWNODE(fwnode) (NULL) +#define ACPI_NODE_GET(adev) NUMA_NO_NODE #include <acpi/acpi_numa.h> -- 2.20.1

2 years, 2 months

2
3
0 0

[PATCH] iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

by Nicolin Chen

When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too since arm_smmu_mm_invalidate_range() is typically called next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_invalidate_range { arm_smmu_mm_invalidate_range { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. Fixes: 51d113c3be09 ("iommu/arm-smmu-v3: Make BTM optional for SVA") Cc: stable(a)vger.kernel.org Signed-off-by: Nicolin Chen <nicolinc(a)nvidia.com> --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 11 ++++++++--- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 9 +++++++++ 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c index a5a63b1c947e..7ec3f5219250 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c @@ -201,9 +201,14 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn, */ size = end - start; - if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) - arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid, - PAGE_SIZE, false, smmu_domain); + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_BTM)) { + if (!(smmu_domain->smmu->features & ARM_SMMU_FEAT_RANGE_INV) && + size >= CMDQ_MAX_TLBI_OPS * PAGE_SIZE) + arm_smmu_tlb_inv_asid(smmu_domain->smmu, smmu_mn->cd->asid); + else + arm_smmu_tlb_inv_range_asid(start, size, smmu_mn->cd->asid, + PAGE_SIZE, false, smmu_domain); + } arm_smmu_atc_inv_domain(smmu_domain, mm->pasid, start, size); } diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h index dcab85698a4e..79a81eed1dcc 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h @@ -326,6 +326,15 @@ */ #define CMDQ_BATCH_ENTRIES BITS_PER_LONG +/* + * Cloned from the MAX_TLBI_OPS in arch/arm64/include/asm/tlbflush.h, this + * is used as a threshold to replace per-page TLBI commands to issue in the + * command queue with an address-space TLBI command, when SMMU w/o a range + * invalidation feature handles too many per-page TLBI commands, which will + * otherwise result in a soft lockup. + */ +#define CMDQ_MAX_TLBI_OPS (1 << (PAGE_SHIFT - 3)) + #define CMDQ_0_OP GENMASK_ULL(7, 0) #define CMDQ_0_SSV (1UL << 11) -- 2.42.0

2 years, 2 months

3
6
0 0

usb: typec: ucsi: Clear EVENT_PENDING bit if ucsi_send_command fails

by Prashanth K

Currently if ucsi_send_command() fails, then we bail out without clearing EVENT_PENDING flag. So when the next connector change event comes, ucsi_connector_change() won't queue the con->work, because of which none of the new events will be processed. Fix this by clearing EVENT_PENDING flag if ucsi_send_command() fails. Cc: <stable(a)vger.kernel.org> # 5.16 Fixes: 512df95b9432 ("usb: typec: ucsi: Better fix for missing unplug events issue") Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> --- drivers/usb/typec/ucsi/ucsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index c6dfe3d..509c67c 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -884,6 +884,7 @@ static void ucsi_handle_connector_change(struct work_struct *work) if (ret < 0) { dev_err(ucsi->dev, "%s: GET_CONNECTOR_STATUS failed (%d)\n", __func__, ret); + clear_bit(EVENT_PENDING, &con->ucsi->flags); goto out_unlock; } -- 2.7.4

2 years, 2 months

2
9
0 0

linux-stable 6.1.53 kernel crash on COLOR_ID_MULTI handling change

by Da Xue

Hi Pavel, We have running systems that use COLOR_ID_MULTI. The GPIO toggles between two colors and we have used the identifier. RGB is not a good fit since it is not a RGB LED. Please provide guidance. This patch causes the system to not start: f741121a2251 leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false It was also backported to stable causing previously booting systems to no longer boot. Best, Da Xue

2 years, 2 months

3
2
0 0

[PATCH v2] wifi: brcmfmac: Replace 1-element arrays with flexible arrays

by Juerg Haefliger

Since commit 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC"), UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. Walking 'element' and 'channel_list' will trigger warnings, so make them proper flexible arrays. False positive warnings were: UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:6984:20 index 1 is out of range for type '__le32 [1]' UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1126:27 index 1 is out of range for type '__le16 [1]' for these lines of code: 6884 ch.chspec = (u16)le32_to_cpu(list->element[i]); 1126 params_le->channel_list[i] = cpu_to_le16(chanspec); Cc: stable(a)vger.kernel.org # 6.5+ Signed-off-by: Juerg Haefliger <juerg.haefliger(a)canonical.com> --- v2: - Use element[] instead of DFA() in brcmf_chanspec_list. - Add Cc: stable tag --- .../wireless/broadcom/brcm80211/brcmfmac/fwil_types.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h index bece26741d3a..611d1a6aabb9 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h @@ -442,7 +442,12 @@ struct brcmf_scan_params_v2_le { * fixed parameter portion is assumed, otherwise * ssid in the fixed portion is ignored */ - __le16 channel_list[1]; /* list of chanspecs */ + union { + __le16 padding; /* Reserve space for at least 1 entry for abort + * which uses an on stack brcmf_scan_params_v2_le + */ + DECLARE_FLEX_ARRAY(__le16, channel_list); /* chanspecs */ + }; }; struct brcmf_scan_results { @@ -702,7 +707,7 @@ struct brcmf_sta_info_le { struct brcmf_chanspec_list { __le32 count; /* # of entries */ - __le32 element[1]; /* variable length uint32 list */ + __le32 element[]; /* variable length uint32 list */ }; /* -- 2.39.2

2 years, 2 months

4
3
0 0

[PATCH -stable,4.19 0/2] netfilter stable fixes for 4.19

by Pablo Neira Ayuso

Hi Greg, Sasha, This batch contains a fixes for 4.19: 1) Missing fix in 4.19, you can cherry-pick it from 8ca79606cdfd ("netfilter: nft_flow_offload: fix underflow in flowtable reference counter") 2) Oneliner that includes missing chunk in 4.19 backport. Fixes: 1df28fde1270 ("netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain") in 4.19 This patch you have to manually apply it. Thanks. Pablo Neira Ayuso (1): netfilter: nf_tables: missing NFT_TRANS_PREPARE_ERROR in flowtable deactivatation wenxu (1): netfilter: nft_flow_offload: fix underflow in flowtable reference counter net/netfilter/nf_tables_api.c | 1 + net/netfilter/nft_flow_offload.c | 3 --- 2 files changed, 1 insertion(+), 3 deletions(-) -- 2.30.2

2 years, 2 months

2
3
0 0

[PATCH net 0/5] mptcp: fix stalled connections

by Matthieu Baerts

Daire reported a few issues with MPTCP where some connections were stalled in different states. Paolo did a great job fixing them. Patch 1 fixes bogus receive window shrinkage with multiple subflows. Due to a race condition and unlucky circumstances, that may lead to TCP-level window shrinkage, and the connection being stalled on the sender end. Patch 2 is a preparation for patch 3 which processes pending subflow errors on close. Without that and under specific circumstances, the MPTCP-level socket might not switch to the CLOSE state and stall. Patch 4 is also a preparation patch for the next one. Patch 5 fixes MPTCP connections not switching to the CLOSE state when all subflows have been closed but no DATA_FIN have been exchanged to explicitly close the MPTCP connection. Now connections in such state will switch to the CLOSE state after a timeout, still allowing the "make-after-break" feature but making sure connections don't stall forever. It will be possible to modify this timeout -- currently matching TCP TIMEWAIT value (60 seconds) -- in a future version. Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> --- Paolo Abeni (5): mptcp: fix bogus receive window shrinkage with multiple subflows mptcp: move __mptcp_error_report in protocol.c mptcp: process pending subflow error on close mptcp: rename timer related helper to less confusing names mptcp: fix dangling connection hang-up net/mptcp/options.c | 5 +- net/mptcp/protocol.c | 165 +++++++++++++++++++++++++++++++-------------------- net/mptcp/protocol.h | 24 +++++++- net/mptcp/subflow.c | 39 +----------- 4 files changed, 130 insertions(+), 103 deletions(-) --- base-commit: 615efed8b63f60ddd69c0b8f32f7783859034fc2 change-id: 20230915-upstream-net-20230915-mptcp-hanging-conn-0609338b1728 Best regards, -- Matthieu Baerts <matthieu.baerts(a)tessares.net>

2 years, 2 months

2
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2023