From: Greg Kroah-Hartman Date: Sun, 14 Apr 2024 13:43:38 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v5.15.156~61 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c12e1142e312583bcecf8fc3e87c7bbf68d9eaf7;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: acpi-scan-do-not-increase-dep_unmet-for-already-met-dependencies.patch arm-dts-imx7s-warp-pass-ov2680-link-frequencies.patch arm64-tlb-fix-tlbi-range-operand.patch ata-libata-core-allow-command-duration-limits-detection-for-acs-4-drives.patch ata-libata-scsi-fix-ata_scsi_dev_rescan-error-path.patch batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch drm-amd-pm-fixes-a-random-hang-in-s4-for-smu-v13.0.4-11.patch media-cec-core-remove-length-check-of-timer-status.patch platform-chrome-cros_ec_uart-properly-fix-race-condition.patch pm-s2idle-make-sure-cpus-will-wakeup-directly-on-resume.patch raid1-fix-use-after-free-for-original-bio-in-raid1_write_request.patch ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch series smb3-fix-open-files-on-server-counter-going-negative.patch --- diff --git a/queue-6.6/acpi-scan-do-not-increase-dep_unmet-for-already-met-dependencies.patch b/queue-6.6/acpi-scan-do-not-increase-dep_unmet-for-already-met-dependencies.patch new file mode 100644 index 00000000000..0fbf7d8604d --- /dev/null +++ b/queue-6.6/acpi-scan-do-not-increase-dep_unmet-for-already-met-dependencies.patch @@ -0,0 +1,59 @@ +From d730192ff0246356a2d7e63ff5bd501060670eec Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Sat, 6 Apr 2024 13:40:52 +0200 +Subject: ACPI: scan: Do not increase dep_unmet for already met dependencies + +From: Hans de Goede + +commit d730192ff0246356a2d7e63ff5bd501060670eec upstream. + +On the Toshiba Encore WT10-A tablet the BATC battery ACPI device depends +on 3 other devices: + + Name (_DEP, Package (0x03) // _DEP: Dependencies + { + I2C1, + GPO2, + GPO0 + }) + +acpi_scan_check_dep() adds all 3 of these to the acpi_dep_list and then +before an acpi_device is created for the BATC handle (and thus before +acpi_scan_dep_init() runs) acpi_scan_clear_dep() gets called for both +GPIO depenencies, with free_when_met not set for the dependencies. + +Since there is no adev for BATC yet, there also is no dep_unmet to +decrement. The only result of acpi_scan_clear_dep() in this case is +dep->met getting set. + +Soon after acpi_scan_clear_dep() has been called for the GPIO dependencies +the acpi_device gets created for the BATC handle and acpi_scan_dep_init() +runs, this sees 3 dependencies on the acpi_dep_list and initializes +unmet_dep to 3. Later when the dependency for I2C1 is met unmet_dep +becomes 2, but since the 2 GPIO deps where already met it never becomes 0 +causing battery monitoring to not work. + +Fix this by modifying acpi_scan_dep_init() to not increase dep_met for +dependencies which have already been marked as being met. + +Fixes: 3ba12d8de3fa ("ACPI: scan: Reduce overhead related to devices with dependencies") +Signed-off-by: Hans de Goede +Cc: 6.5+ # 6.5+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/scan.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/acpi/scan.c ++++ b/drivers/acpi/scan.c +@@ -1798,7 +1798,8 @@ static void acpi_scan_dep_init(struct ac + if (dep->honor_dep) + adev->flags.honor_deps = 1; + +- adev->dep_unmet++; ++ if (!dep->met) ++ adev->dep_unmet++; + } + } + } diff --git a/queue-6.6/arm-dts-imx7s-warp-pass-ov2680-link-frequencies.patch b/queue-6.6/arm-dts-imx7s-warp-pass-ov2680-link-frequencies.patch new file mode 100644 index 00000000000..e0864828e57 --- /dev/null +++ b/queue-6.6/arm-dts-imx7s-warp-pass-ov2680-link-frequencies.patch @@ -0,0 +1,39 @@ +From 135f218255b28c5bbf71e9e32a49e5c734cabbe5 Mon Sep 17 00:00:00 2001 +From: Fabio Estevam +Date: Thu, 28 Mar 2024 12:19:54 -0300 +Subject: ARM: dts: imx7s-warp: Pass OV2680 link-frequencies + +From: Fabio Estevam + +commit 135f218255b28c5bbf71e9e32a49e5c734cabbe5 upstream. + +Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint +property verification") the ov2680 no longer probes on a imx7s-warp7: + +ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found +ov2680 1-0036: probe with driver ov2680 failed with error -22 + +Fix it by passing the required 'link-frequencies' property as +recommended by: + +https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks + +Cc: stable@vger.kernel.org +Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") +Signed-off-by: Fabio Estevam +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/nxp/imx/imx7s-warp.dts | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm/boot/dts/nxp/imx/imx7s-warp.dts ++++ b/arch/arm/boot/dts/nxp/imx/imx7s-warp.dts +@@ -210,6 +210,7 @@ + remote-endpoint = <&mipi_from_sensor>; + clock-lanes = <0>; + data-lanes = <1>; ++ link-frequencies = /bits/ 64 <330000000>; + }; + }; + }; diff --git a/queue-6.6/arm64-tlb-fix-tlbi-range-operand.patch b/queue-6.6/arm64-tlb-fix-tlbi-range-operand.patch new file mode 100644 index 00000000000..8ea6e13f54f --- /dev/null +++ b/queue-6.6/arm64-tlb-fix-tlbi-range-operand.patch @@ -0,0 +1,91 @@ +From e3ba51ab24fddef79fc212f9840de54db8fd1685 Mon Sep 17 00:00:00 2001 +From: Gavin Shan +Date: Fri, 5 Apr 2024 13:58:50 +1000 +Subject: arm64: tlb: Fix TLBI RANGE operand + +From: Gavin Shan + +commit e3ba51ab24fddef79fc212f9840de54db8fd1685 upstream. + +KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty +pages are collected by VMM and the page table entries become write +protected during live migration. Unfortunately, the operand passed +to the TLBI RANGE instruction isn't correctly sorted out due to the +commit 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()"). +It leads to crash on the destination VM after live migration because +TLBs aren't flushed completely and some of the dirty pages are missed. + +For example, I have a VM where 8GB memory is assigned, starting from +0x40000000 (1GB). Note that the host has 4KB as the base page size. +In the middile of migration, kvm_tlb_flush_vmid_range() is executed +to flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to +__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3 +and NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported +by __TLBI_RANGE_NUM(). In this specific case, -1 has been returned +from __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop +in the __flush_tlb_range_op() until the variable @scale underflows +and becomes -9, 0xffff708000040000 is set as the operand. The operand +is wrong since it's sorted out by __TLBI_VADDR_RANGE() according to +invalid @scale and @num. + +Fix it by extending __TLBI_RANGE_NUM() to support the combination of +SCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can +be returned from the macro, meaning the TLBs for 0x200000 pages in the +above example can be flushed in one shoot with SCALE#3 and NUM#31. The +macro TLBI_RANGE_MASK is dropped since no one uses it any more. The +comments are also adjusted accordingly. + +Fixes: 117940aa6e5f ("KVM: arm64: Define kvm_tlb_flush_vmid_range()") +Cc: stable@kernel.org # v6.6+ +Reported-by: Yihuang Yu +Suggested-by: Marc Zyngier +Signed-off-by: Gavin Shan +Reviewed-by: Catalin Marinas +Reviewed-by: Ryan Roberts +Reviewed-by: Anshuman Khandual +Reviewed-by: Shaoqin Huang +Link: https://lore.kernel.org/r/20240405035852.1532010-2-gshan@redhat.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/tlbflush.h | 22 ++++++++++++---------- + 1 file changed, 12 insertions(+), 10 deletions(-) + +--- a/arch/arm64/include/asm/tlbflush.h ++++ b/arch/arm64/include/asm/tlbflush.h +@@ -152,12 +152,18 @@ static inline unsigned long get_trans_gr + #define MAX_TLBI_RANGE_PAGES __TLBI_RANGE_PAGES(31, 3) + + /* +- * Generate 'num' values from -1 to 30 with -1 rejected by the +- * __flush_tlb_range() loop below. +- */ +-#define TLBI_RANGE_MASK GENMASK_ULL(4, 0) +-#define __TLBI_RANGE_NUM(pages, scale) \ +- ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1) ++ * Generate 'num' values from -1 to 31 with -1 rejected by the ++ * __flush_tlb_range() loop below. Its return value is only ++ * significant for a maximum of MAX_TLBI_RANGE_PAGES pages. If ++ * 'pages' is more than that, you must iterate over the overall ++ * range. ++ */ ++#define __TLBI_RANGE_NUM(pages, scale) \ ++ ({ \ ++ int __pages = min((pages), \ ++ __TLBI_RANGE_PAGES(31, (scale))); \ ++ (__pages >> (5 * (scale) + 1)) - 1; \ ++ }) + + /* + * TLB Invalidation +@@ -359,10 +365,6 @@ static inline void arch_tlbbatch_flush(s + * Start from scale = 0, flush the corresponding number of pages + * ((num+1)*2^(5*scale+1) starting from 'addr'), then increase it + * until no pages left. +- * +- * Note that certain ranges can be represented by either num = 31 and +- * scale or num = 0 and scale + 1. The loop below favours the latter +- * since num is limited to 30 by the __TLBI_RANGE_NUM() macro. + */ + #define __flush_tlb_range_op(op, start, pages, stride, \ + asid, tlb_level, tlbi_user) \ diff --git a/queue-6.6/ata-libata-core-allow-command-duration-limits-detection-for-acs-4-drives.patch b/queue-6.6/ata-libata-core-allow-command-duration-limits-detection-for-acs-4-drives.patch new file mode 100644 index 00000000000..6eb2a3d079b --- /dev/null +++ b/queue-6.6/ata-libata-core-allow-command-duration-limits-detection-for-acs-4-drives.patch @@ -0,0 +1,37 @@ +From c0297e7dd50795d559f3534887a6de1756b35d0f Mon Sep 17 00:00:00 2001 +From: Igor Pylypiv +Date: Thu, 11 Apr 2024 20:12:24 +0000 +Subject: ata: libata-core: Allow command duration limits detection for ACS-4 drives + +From: Igor Pylypiv + +commit c0297e7dd50795d559f3534887a6de1756b35d0f upstream. + +Even though the command duration limits (CDL) feature was first added +in ACS-5 (major version 12), there are some ACS-4 (major version 11) +drives that implement CDL as well. + +IDENTIFY_DEVICE, SUPPORTED_CAPABILITIES, and CURRENT_SETTINGS log pages +are mandatory in the ACS-4 standard so it should be safe to read these +log pages on older drives implementing the ACS-4 standard. + +Fixes: 62e4a60e0cdb ("scsi: ata: libata: Detect support for command duration limits") +Cc: stable@vger.kernel.org +Signed-off-by: Igor Pylypiv +Signed-off-by: Damien Le Moal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/libata-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/ata/libata-core.c ++++ b/drivers/ata/libata-core.c +@@ -2493,7 +2493,7 @@ static void ata_dev_config_cdl(struct at + bool cdl_enabled; + u64 val; + +- if (ata_id_major_version(dev->id) < 12) ++ if (ata_id_major_version(dev->id) < 11) + goto not_supported; + + if (!ata_log_supported(dev, ATA_LOG_IDENTIFY_DEVICE) || diff --git a/queue-6.6/ata-libata-scsi-fix-ata_scsi_dev_rescan-error-path.patch b/queue-6.6/ata-libata-scsi-fix-ata_scsi_dev_rescan-error-path.patch new file mode 100644 index 00000000000..f48d12e03dc --- /dev/null +++ b/queue-6.6/ata-libata-scsi-fix-ata_scsi_dev_rescan-error-path.patch @@ -0,0 +1,67 @@ +From 79336504781e7fee5ddaf046dcc186c8dfdf60b1 Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Fri, 12 Apr 2024 08:41:15 +0900 +Subject: ata: libata-scsi: Fix ata_scsi_dev_rescan() error path + +From: Damien Le Moal + +commit 79336504781e7fee5ddaf046dcc186c8dfdf60b1 upstream. + +Commit 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume") +incorrectly handles failures of scsi_resume_device() in +ata_scsi_dev_rescan(), leading to a double call to +spin_unlock_irqrestore() to unlock a device port. Fix this by redefining +the goto labels used in case of errors and only unlock the port +scsi_scan_mutex when scsi_resume_device() fails. + +Bug found with the Smatch static checker warning: + + drivers/ata/libata-scsi.c:4774 ata_scsi_dev_rescan() + error: double unlocked 'ap->lock' (orig line 4757) + +Reported-by: Dan Carpenter +Fixes: 0c76106cb975 ("scsi: sd: Fix TCG OPAL unlock on system resume") +Cc: stable@vger.kernel.org +Signed-off-by: Damien Le Moal +Reviewed-by: Niklas Cassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/libata-scsi.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/ata/libata-scsi.c ++++ b/drivers/ata/libata-scsi.c +@@ -4780,7 +4780,7 @@ void ata_scsi_dev_rescan(struct work_str + * bail out. + */ + if (ap->pflags & ATA_PFLAG_SUSPENDED) +- goto unlock; ++ goto unlock_ap; + + if (!sdev) + continue; +@@ -4793,7 +4793,7 @@ void ata_scsi_dev_rescan(struct work_str + if (do_resume) { + ret = scsi_resume_device(sdev); + if (ret == -EWOULDBLOCK) +- goto unlock; ++ goto unlock_scan; + dev->flags &= ~ATA_DFLAG_RESUMING; + } + ret = scsi_rescan_device(sdev); +@@ -4801,12 +4801,13 @@ void ata_scsi_dev_rescan(struct work_str + spin_lock_irqsave(ap->lock, flags); + + if (ret) +- goto unlock; ++ goto unlock_ap; + } + } + +-unlock: ++unlock_ap: + spin_unlock_irqrestore(ap->lock, flags); ++unlock_scan: + mutex_unlock(&ap->scsi_scan_mutex); + + /* Reschedule with a delay if scsi_rescan_device() returned an error */ diff --git a/queue-6.6/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch b/queue-6.6/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch new file mode 100644 index 00000000000..8d599c3602b --- /dev/null +++ b/queue-6.6/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch @@ -0,0 +1,68 @@ +From b1f532a3b1e6d2e5559c7ace49322922637a28aa Mon Sep 17 00:00:00 2001 +From: Sven Eckelmann +Date: Mon, 12 Feb 2024 13:58:33 +0100 +Subject: batman-adv: Avoid infinite loop trying to resize local TT + +From: Sven Eckelmann + +commit b1f532a3b1e6d2e5559c7ace49322922637a28aa upstream. + +If the MTU of one of an attached interface becomes too small to transmit +the local translation table then it must be resized to fit inside all +fragments (when enabled) or a single packet. + +But if the MTU becomes too low to transmit even the header + the VLAN +specific part then the resizing of the local TT will never succeed. This +can for example happen when the usable space is 110 bytes and 11 VLANs are +on top of batman-adv. In this case, at least 116 byte would be needed. +There will just be an endless spam of + + batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) + +in the log but the function will never finish. Problem here is that the +timeout will be halved all the time and will then stagnate at 0 and +therefore never be able to reduce the table even more. + +There are other scenarios possible with a similar result. The number of +BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too +high to fit inside a packet. Such a scenario can therefore happen also with +only a single VLAN + 7 non-purgable addresses - requiring at least 120 +bytes. + +While this should be handled proactively when: + +* interface with too low MTU is added +* VLAN is added +* non-purgeable local mac is added +* MTU of an attached interface is reduced +* fragmentation setting gets disabled (which most likely requires dropping + attached interfaces) + +not all of these scenarios can be prevented because batman-adv is only +consuming events without the the possibility to prevent these actions +(non-purgable MAC address added, MTU of an attached interface is reduced). +It is therefore necessary to also make sure that the code is able to handle +also the situations when there were already incompatible system +configuration are present. + +Cc: stable@vger.kernel.org +Fixes: a19d3d85e1b8 ("batman-adv: limit local translation table max size") +Reported-by: syzbot+a6a4b5bb3da165594cff@syzkaller.appspotmail.com +Signed-off-by: Sven Eckelmann +Signed-off-by: Simon Wunderlich +Signed-off-by: Greg Kroah-Hartman +--- + net/batman-adv/translation-table.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/batman-adv/translation-table.c ++++ b/net/batman-adv/translation-table.c +@@ -3948,7 +3948,7 @@ void batadv_tt_local_resize_to_mtu(struc + + spin_lock_bh(&bat_priv->tt.commit_lock); + +- while (true) { ++ while (timeout) { + table_size = batadv_tt_local_table_transmit_size(bat_priv); + if (packet_size_max >= table_size) + break; diff --git a/queue-6.6/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch b/queue-6.6/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch new file mode 100644 index 00000000000..45c73f096b4 --- /dev/null +++ b/queue-6.6/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch @@ -0,0 +1,37 @@ +From 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 Mon Sep 17 00:00:00 2001 +From: Dmitry Antipov +Date: Tue, 2 Apr 2024 14:32:05 +0300 +Subject: Bluetooth: Fix memory leak in hci_req_sync_complete() + +From: Dmitry Antipov + +commit 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 upstream. + +In 'hci_req_sync_complete()', always free the previous sync +request state before assigning reference to a new one. + +Reported-by: syzbot+39ec16ff6cc18b1d066d@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=39ec16ff6cc18b1d066d +Cc: stable@vger.kernel.org +Fixes: f60cb30579d3 ("Bluetooth: Convert hci_req_sync family of function to new request API") +Signed-off-by: Dmitry Antipov +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_request.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/net/bluetooth/hci_request.c ++++ b/net/bluetooth/hci_request.c +@@ -105,8 +105,10 @@ void hci_req_sync_complete(struct hci_de + if (hdev->req_status == HCI_REQ_PEND) { + hdev->req_result = result; + hdev->req_status = HCI_REQ_DONE; +- if (skb) ++ if (skb) { ++ kfree_skb(hdev->req_skb); + hdev->req_skb = skb_get(skb); ++ } + wake_up_interruptible(&hdev->req_wait_q); + } + } diff --git a/queue-6.6/drm-amd-pm-fixes-a-random-hang-in-s4-for-smu-v13.0.4-11.patch b/queue-6.6/drm-amd-pm-fixes-a-random-hang-in-s4-for-smu-v13.0.4-11.patch new file mode 100644 index 00000000000..04a10759c13 --- /dev/null +++ b/queue-6.6/drm-amd-pm-fixes-a-random-hang-in-s4-for-smu-v13.0.4-11.patch @@ -0,0 +1,46 @@ +From 31729e8c21ecfd671458e02b6511eb68c2225113 Mon Sep 17 00:00:00 2001 +From: Tim Huang +Date: Wed, 27 Mar 2024 13:10:37 +0800 +Subject: drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11 + +From: Tim Huang + +commit 31729e8c21ecfd671458e02b6511eb68c2225113 upstream. + +While doing multiple S4 stress tests, GC/RLC/PMFW get into +an invalid state resulting into hard hangs. + +Adding a GFX reset as workaround just before sending the +MP1_UNLOAD message avoids this failure. + +Signed-off-by: Tim Huang +Acked-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: Mario Limonciello +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c +@@ -226,8 +226,18 @@ static int smu_v13_0_4_system_features_c + struct amdgpu_device *adev = smu->adev; + int ret = 0; + +- if (!en && !adev->in_s0ix) ++ if (!en && !adev->in_s0ix) { ++ /* Adds a GFX reset as workaround just before sending the ++ * MP1_UNLOAD message to prevent GC/RLC/PMFW from entering ++ * an invalid state. ++ */ ++ ret = smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_GfxDeviceDriverReset, ++ SMU_RESET_MODE_2, NULL); ++ if (ret) ++ return ret; ++ + ret = smu_cmn_send_smc_msg(smu, SMU_MSG_PrepareMp1ForUnload, NULL); ++ } + + return ret; + } diff --git a/queue-6.6/media-cec-core-remove-length-check-of-timer-status.patch b/queue-6.6/media-cec-core-remove-length-check-of-timer-status.patch new file mode 100644 index 00000000000..a02c1c5a50b --- /dev/null +++ b/queue-6.6/media-cec-core-remove-length-check-of-timer-status.patch @@ -0,0 +1,52 @@ +From ce5d241c3ad4568c12842168288993234345c0eb Mon Sep 17 00:00:00 2001 +From: Nini Song +Date: Thu, 25 Jan 2024 21:28:45 +0800 +Subject: media: cec: core: remove length check of Timer Status + +From: Nini Song + +commit ce5d241c3ad4568c12842168288993234345c0eb upstream. + +The valid_la is used to check the length requirements, +including special cases of Timer Status. If the length is +shorter than 5, that means no Duration Available is returned, +the message will be forced to be invalid. + +However, the description of Duration Available in the spec +is that this parameter may be returned when these cases, or +that it can be optionally return when these cases. The key +words in the spec description are flexible choices. + +Remove the special length check of Timer Status to fit the +spec which is not compulsory about that. + +Signed-off-by: Nini Song +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/cec/core/cec-adap.c | 14 -------------- + 1 file changed, 14 deletions(-) + +--- a/drivers/media/cec/core/cec-adap.c ++++ b/drivers/media/cec/core/cec-adap.c +@@ -1124,20 +1124,6 @@ void cec_received_msg_ts(struct cec_adap + if (valid_la && min_len) { + /* These messages have special length requirements */ + switch (cmd) { +- case CEC_MSG_TIMER_STATUS: +- if (msg->msg[2] & 0x10) { +- switch (msg->msg[2] & 0xf) { +- case CEC_OP_PROG_INFO_NOT_ENOUGH_SPACE: +- case CEC_OP_PROG_INFO_MIGHT_NOT_BE_ENOUGH_SPACE: +- if (msg->len < 5) +- valid_la = false; +- break; +- } +- } else if ((msg->msg[2] & 0xf) == CEC_OP_PROG_ERROR_DUPLICATE) { +- if (msg->len < 5) +- valid_la = false; +- } +- break; + case CEC_MSG_RECORD_ON: + switch (msg->msg[2]) { + case CEC_OP_RECORD_SRC_OWN: diff --git a/queue-6.6/platform-chrome-cros_ec_uart-properly-fix-race-condition.patch b/queue-6.6/platform-chrome-cros_ec_uart-properly-fix-race-condition.patch new file mode 100644 index 00000000000..70e97128ff0 --- /dev/null +++ b/queue-6.6/platform-chrome-cros_ec_uart-properly-fix-race-condition.patch @@ -0,0 +1,110 @@ +From 5e700b384ec13f5bcac9855cb28fcc674f1d3593 Mon Sep 17 00:00:00 2001 +From: Noah Loomans +Date: Wed, 10 Apr 2024 20:26:19 +0200 +Subject: platform/chrome: cros_ec_uart: properly fix race condition + +From: Noah Loomans + +commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream. + +The cros_ec_uart_probe() function calls devm_serdev_device_open() before +it calls serdev_device_set_client_ops(). This can trigger a NULL pointer +dereference: + + BUG: kernel NULL pointer dereference, address: 0000000000000000 + ... + Call Trace: + + ... + ? ttyport_receive_buf + +A simplified version of crashing code is as follows: + + static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, + const u8 *data, + size_t count) + { + struct serdev_device *serdev = ctrl->serdev; + + if (!serdev || !serdev->ops->receive_buf) // CRASH! + return 0; + + return serdev->ops->receive_buf(serdev, data, count); + } + +It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops +will also exist. This conflicts with the existing cros_ec_uart_probe() +logic, as it first calls devm_serdev_device_open() (which sets +SERPORT_ACTIVE), and only later sets serdev->ops via +serdev_device_set_client_ops(). + +Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race +condition") attempted to fix a similar race condition, but while doing +so, made the window of error for this race condition to happen much +wider. + +Attempt to fix the race condition again, making sure we fully setup +before calling devm_serdev_device_open(). + +Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") +Cc: stable@vger.kernel.org +Signed-off-by: Noah Loomans +Reviewed-by: Guenter Roeck +Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com +Signed-off-by: Tzung-Bi Shih +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/chrome/cros_ec_uart.c | 28 ++++++++++++++-------------- + 1 file changed, 14 insertions(+), 14 deletions(-) + +--- a/drivers/platform/chrome/cros_ec_uart.c ++++ b/drivers/platform/chrome/cros_ec_uart.c +@@ -264,12 +264,6 @@ static int cros_ec_uart_probe(struct ser + if (!ec_dev) + return -ENOMEM; + +- ret = devm_serdev_device_open(dev, serdev); +- if (ret) { +- dev_err(dev, "Unable to open UART device"); +- return ret; +- } +- + serdev_device_set_drvdata(serdev, ec_dev); + init_waitqueue_head(&ec_uart->response.wait_queue); + +@@ -281,14 +275,6 @@ static int cros_ec_uart_probe(struct ser + return ret; + } + +- ret = serdev_device_set_baudrate(serdev, ec_uart->baudrate); +- if (ret < 0) { +- dev_err(dev, "Failed to set up host baud rate (%d)", ret); +- return ret; +- } +- +- serdev_device_set_flow_control(serdev, ec_uart->flowcontrol); +- + /* Initialize ec_dev for cros_ec */ + ec_dev->phys_name = dev_name(dev); + ec_dev->dev = dev; +@@ -302,6 +288,20 @@ static int cros_ec_uart_probe(struct ser + + serdev_device_set_client_ops(serdev, &cros_ec_uart_client_ops); + ++ ret = devm_serdev_device_open(dev, serdev); ++ if (ret) { ++ dev_err(dev, "Unable to open UART device"); ++ return ret; ++ } ++ ++ ret = serdev_device_set_baudrate(serdev, ec_uart->baudrate); ++ if (ret < 0) { ++ dev_err(dev, "Failed to set up host baud rate (%d)", ret); ++ return ret; ++ } ++ ++ serdev_device_set_flow_control(serdev, ec_uart->flowcontrol); ++ + return cros_ec_register(ec_dev); + } + diff --git a/queue-6.6/pm-s2idle-make-sure-cpus-will-wakeup-directly-on-resume.patch b/queue-6.6/pm-s2idle-make-sure-cpus-will-wakeup-directly-on-resume.patch new file mode 100644 index 00000000000..2ee84b98675 --- /dev/null +++ b/queue-6.6/pm-s2idle-make-sure-cpus-will-wakeup-directly-on-resume.patch @@ -0,0 +1,83 @@ +From 3c89a068bfd0698a5478f4cf39493595ef757d5e Mon Sep 17 00:00:00 2001 +From: Anna-Maria Behnsen +Date: Mon, 8 Apr 2024 09:02:23 +0200 +Subject: PM: s2idle: Make sure CPUs will wakeup directly on resume + +From: Anna-Maria Behnsen + +commit 3c89a068bfd0698a5478f4cf39493595ef757d5e upstream. + +s2idle works like a regular suspend with freezing processes and freezing +devices. All CPUs except the control CPU go into idle. Once this is +completed the control CPU kicks all other CPUs out of idle, so that they +reenter the idle loop and then enter s2idle state. The control CPU then +issues an swait() on the suspend state and therefore enters the idle loop +as well. + +Due to being kicked out of idle, the other CPUs leave their NOHZ states, +which means the tick is active and the corresponding hrtimer is programmed +to the next jiffie. + +On entering s2idle the CPUs shut down their local clockevent device to +prevent wakeups. The last CPU which enters s2idle shuts down its local +clockevent and freezes timekeeping. + +On resume, one of the CPUs receives the wakeup interrupt, unfreezes +timekeeping and its local clockevent and starts the resume process. At that +point all other CPUs are still in s2idle with their clockevents switched +off. They only resume when they are kicked by another CPU or after resuming +devices and then receiving a device interrupt. + +That means there is no guarantee that all CPUs will wakeup directly on +resume. As a consequence there is no guarantee that timers which are queued +on those CPUs and should expire directly after resume, are handled. Also +timer list timers which are remotely queued to one of those CPUs after +resume will not result in a reprogramming IPI as the tick is +active. Queueing a hrtimer will also not result in a reprogramming IPI +because the first hrtimer event is already in the past. + +The recent introduction of the timer pull model (7ee988770326 ("timers: +Implement the hierarchical pull model")) amplifies this problem, if the +current migrator is one of the non woken up CPUs. When a non pinned timer +list timer is queued and the queuing CPU goes idle, it relies on the still +suspended migrator CPU to expire the timer which will happen by chance. + +The problem exists since commit 8d89835b0467 ("PM: suspend: Do not pause +cpuidle in the suspend-to-idle path"). There the cpuidle_pause() call which +in turn invoked a wakeup for all idle CPUs was moved to a later point in +the resume process. This might not be reached or reached very late because +it waits on a timer of a still suspended CPU. + +Address this by kicking all CPUs out of idle after the control CPU returns +from swait() so that they resume their timers and restore consistent system +state. + +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218641 +Fixes: 8d89835b0467 ("PM: suspend: Do not pause cpuidle in the suspend-to-idle path") +Signed-off-by: Anna-Maria Behnsen +Reviewed-by: Thomas Gleixner +Tested-by: Mario Limonciello +Cc: 5.16+ # 5.16+ +Acked-by: Peter Zijlstra (Intel) +Reviewed-by: Ulf Hansson +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + kernel/power/suspend.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/kernel/power/suspend.c ++++ b/kernel/power/suspend.c +@@ -106,6 +106,12 @@ static void s2idle_enter(void) + swait_event_exclusive(s2idle_wait_head, + s2idle_state == S2IDLE_STATE_WAKE); + ++ /* ++ * Kick all CPUs to ensure that they resume their timers and restore ++ * consistent system state. ++ */ ++ wake_up_all_idle_cpus(); ++ + cpus_read_unlock(); + + raw_spin_lock_irq(&s2idle_lock); diff --git a/queue-6.6/raid1-fix-use-after-free-for-original-bio-in-raid1_write_request.patch b/queue-6.6/raid1-fix-use-after-free-for-original-bio-in-raid1_write_request.patch new file mode 100644 index 00000000000..db8f70350fa --- /dev/null +++ b/queue-6.6/raid1-fix-use-after-free-for-original-bio-in-raid1_write_request.patch @@ -0,0 +1,98 @@ +From fcf3f7e2fc8a53a6140beee46ec782a4c88e4744 Mon Sep 17 00:00:00 2001 +From: Yu Kuai +Date: Fri, 8 Mar 2024 17:37:26 +0800 +Subject: raid1: fix use-after-free for original bio in raid1_write_request() + +From: Yu Kuai + +commit fcf3f7e2fc8a53a6140beee46ec782a4c88e4744 upstream. + +r1_bio->bios[] is used to record new bios that will be issued to +underlying disks, however, in raid1_write_request(), r1_bio->bios[] +will set to the original bio temporarily. Meanwhile, if blocked rdev +is set, free_r1bio() will be called causing that all r1_bio->bios[] +to be freed: + +raid1_write_request() + r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL + for (i = 0; i < disks; i++) -> for each rdev in conf + // first rdev is normal + r1_bio->bios[0] = bio; -> set to original bio + // second rdev is blocked + if (test_bit(Blocked, &rdev->flags)) + break + + if (blocked_rdev) + free_r1bio() + put_all_bios() + bio_put(r1_bio->bios[0]) -> original bio is freed + +Test scripts: + +mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean +fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \ + -iodepth=128 -name=test -direct=1 +echo blocked > /sys/block/md0/md/rd2/state + +Test result: + +BUG bio-264 (Not tainted): Object already free +----------------------------------------------------------------------------- + +Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 + kmem_cache_alloc+0x324/0x480 + mempool_alloc_slab+0x24/0x50 + mempool_alloc+0x6e/0x220 + bio_alloc_bioset+0x1af/0x4d0 + blkdev_direct_IO+0x164/0x8a0 + blkdev_write_iter+0x309/0x440 + aio_write+0x139/0x2f0 + io_submit_one+0x5ca/0xb70 + __do_sys_io_submit+0x86/0x270 + __x64_sys_io_submit+0x22/0x30 + do_syscall_64+0xb1/0x210 + entry_SYSCALL_64_after_hwframe+0x6c/0x74 +Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869 + kmem_cache_free+0x28c/0x550 + mempool_free_slab+0x1f/0x30 + mempool_free+0x40/0x100 + bio_free+0x59/0x80 + bio_put+0xf0/0x220 + free_r1bio+0x74/0xb0 + raid1_make_request+0xadf/0x1150 + md_handle_request+0xc7/0x3b0 + md_submit_bio+0x76/0x130 + __submit_bio+0xd8/0x1d0 + submit_bio_noacct_nocheck+0x1eb/0x5c0 + submit_bio_noacct+0x169/0xd40 + submit_bio+0xee/0x1d0 + blkdev_direct_IO+0x322/0x8a0 + blkdev_write_iter+0x309/0x440 + aio_write+0x139/0x2f0 + +Since that bios for underlying disks are not allocated yet, fix this +problem by using mempool_free() directly to free the r1_bio. + +Fixes: 992db13a4aee ("md/raid1: free the r1bio before waiting for blocked rdev") +Cc: stable@vger.kernel.org # v6.6+ +Reported-by: Coly Li +Signed-off-by: Yu Kuai +Tested-by: Coly Li +Signed-off-by: Song Liu +Link: https://lore.kernel.org/r/20240308093726.1047420-1-yukuai1@huaweicloud.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid1.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/md/raid1.c ++++ b/drivers/md/raid1.c +@@ -1473,7 +1473,7 @@ static void raid1_write_request(struct m + for (j = 0; j < i; j++) + if (r1_bio->bios[j]) + rdev_dec_pending(conf->mirrors[j].rdev, mddev); +- free_r1bio(r1_bio); ++ mempool_free(r1_bio, &conf->r1bio_pool); + allow_barrier(conf, bio->bi_iter.bi_sector); + + if (bio->bi_opf & REQ_NOWAIT) { diff --git a/queue-6.6/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch b/queue-6.6/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch new file mode 100644 index 00000000000..9988bd81f53 --- /dev/null +++ b/queue-6.6/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch @@ -0,0 +1,83 @@ +From ffe3986fece696cf65e0ef99e74c75f848be8e30 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Tue, 9 Apr 2024 15:13:09 -0400 +Subject: ring-buffer: Only update pages_touched when a new page is touched + +From: Steven Rostedt (Google) + +commit ffe3986fece696cf65e0ef99e74c75f848be8e30 upstream. + +The "buffer_percent" logic that is used by the ring buffer splice code to +only wake up the tasks when there's no data after the buffer is filled to +the percentage of the "buffer_percent" file is dependent on three +variables that determine the amount of data that is in the ring buffer: + + 1) pages_read - incremented whenever a new sub-buffer is consumed + 2) pages_lost - incremented every time a writer overwrites a sub-buffer + 3) pages_touched - incremented when a write goes to a new sub-buffer + +The percentage is the calculation of: + + (pages_touched - (pages_lost + pages_read)) / nr_pages + +Basically, the amount of data is the total number of sub-bufs that have been +touched, minus the number of sub-bufs lost and sub-bufs consumed. This is +divided by the total count to give the buffer percentage. When the +percentage is greater than the value in the "buffer_percent" file, it +wakes up splice readers waiting for that amount. + +It was observed that over time, the amount read from the splice was +constantly decreasing the longer the trace was running. That is, if one +asked for 60%, it would read over 60% when it first starts tracing, but +then it would be woken up at under 60% and would slowly decrease the +amount of data read after being woken up, where the amount becomes much +less than the buffer percent. + +This was due to an accounting of the pages_touched incrementation. This +value is incremented whenever a writer transfers to a new sub-buffer. But +the place where it was incremented was incorrect. If a writer overflowed +the current sub-buffer it would go to the next one. If it gets preempted +by an interrupt at that time, and the interrupt performs a trace, it too +will end up going to the next sub-buffer. But only one should increment +the counter. Unfortunately, that was not the case. + +Change the cmpxchg() that does the real switch of the tail-page into a +try_cmpxchg(), and on success, perform the increment of pages_touched. This +will only increment the counter once for when the writer moves to a new +sub-buffer, and not when there's a race and is incremented for when a +writer and its preempting writer both move to the same new sub-buffer. + +Link: https://lore.kernel.org/linux-trace-kernel/20240409151309.0d0e5056@gandalf.local.home + +Cc: stable@vger.kernel.org +Cc: Mathieu Desnoyers +Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader") +Acked-by: Masami Hiramatsu (Google) +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ring_buffer.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -1536,7 +1536,6 @@ static void rb_tail_page_update(struct r + old_write = local_add_return(RB_WRITE_INTCNT, &next_page->write); + old_entries = local_add_return(RB_WRITE_INTCNT, &next_page->entries); + +- local_inc(&cpu_buffer->pages_touched); + /* + * Just make sure we have seen our old_write and synchronize + * with any interrupts that come in. +@@ -1573,8 +1572,9 @@ static void rb_tail_page_update(struct r + */ + local_set(&next_page->page->commit, 0); + +- /* Again, either we update tail_page or an interrupt does */ +- (void)cmpxchg(&cpu_buffer->tail_page, tail_page, next_page); ++ /* Either we update tail_page or an interrupt does */ ++ if (try_cmpxchg(&cpu_buffer->tail_page, &tail_page, next_page)) ++ local_inc(&cpu_buffer->pages_touched); + } + } + diff --git a/queue-6.6/series b/queue-6.6/series new file mode 100644 index 00000000000..74aa647d236 --- /dev/null +++ b/queue-6.6/series @@ -0,0 +1,14 @@ +smb3-fix-open-files-on-server-counter-going-negative.patch +ata-libata-core-allow-command-duration-limits-detection-for-acs-4-drives.patch +ata-libata-scsi-fix-ata_scsi_dev_rescan-error-path.patch +batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch +arm64-tlb-fix-tlbi-range-operand.patch +arm-dts-imx7s-warp-pass-ov2680-link-frequencies.patch +raid1-fix-use-after-free-for-original-bio-in-raid1_write_request.patch +ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch +bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch +drm-amd-pm-fixes-a-random-hang-in-s4-for-smu-v13.0.4-11.patch +platform-chrome-cros_ec_uart-properly-fix-race-condition.patch +acpi-scan-do-not-increase-dep_unmet-for-already-met-dependencies.patch +pm-s2idle-make-sure-cpus-will-wakeup-directly-on-resume.patch +media-cec-core-remove-length-check-of-timer-status.patch diff --git a/queue-6.6/smb3-fix-open-files-on-server-counter-going-negative.patch b/queue-6.6/smb3-fix-open-files-on-server-counter-going-negative.patch new file mode 100644 index 00000000000..bf4c91d5f47 --- /dev/null +++ b/queue-6.6/smb3-fix-open-files-on-server-counter-going-negative.patch @@ -0,0 +1,34 @@ +From 28e0947651ce6a2200b9a7eceb93282e97d7e51a Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Sat, 6 Apr 2024 23:16:08 -0500 +Subject: smb3: fix Open files on server counter going negative + +From: Steve French + +commit 28e0947651ce6a2200b9a7eceb93282e97d7e51a upstream. + +We were decrementing the count of open files on server twice +for the case where we were closing cached directories. + +Fixes: 8e843bf38f7b ("cifs: return a single-use cfid if we did not get a lease") +Cc: stable@vger.kernel.org +Acked-by: Bharath SM +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/cached_dir.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/smb/client/cached_dir.c ++++ b/fs/smb/client/cached_dir.c +@@ -417,8 +417,8 @@ smb2_close_cached_fid(struct kref *ref) + if (cfid->is_open) { + rc = SMB2_close(0, cfid->tcon, cfid->fid.persistent_fid, + cfid->fid.volatile_fid); +- if (rc != -EBUSY && rc != -EAGAIN) +- atomic_dec(&cfid->tcon->num_remote_opens); ++ if (rc) /* should we retry on -EBUSY or -EAGAIN? */ ++ cifs_dbg(VFS, "close cached dir rc %d\n", rc); + } + + free_cached_dir(cfid);