From 48bafc5915e6d6228eff5fdc3ced601835b190b3 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 8 Jul 2025 17:15:44 +0200 Subject: [PATCH] 6.6-stable patches added patches: cifs-all-initializations-for-tcon-should-happen-in-tcon_info_alloc.patch dma-buf-fix-timeout-handling-in-dma_resv_wait_timeout-v2.patch i2c-designware-fix-an-initialization-issue.patch iommu-rockchip-prevent-iommus-dead-loop-when-two-masters-share-one-iommu.patch logitech-c-270-even-more-broken.patch powercap-intel_rapl-do-not-change-clamping-bit-if-enable-bit-cannot-be-changed.patch smb-client-fix-readdir-returning-wrong-type-with-posix-extensions.patch --- ...con-should-happen-in-tcon_info_alloc.patch | 82 +++++++++++++++++++ ...handling-in-dma_resv_wait_timeout-v2.patch | 56 +++++++++++++ ...signware-fix-an-initialization-issue.patch | 39 +++++++++ ...oop-when-two-masters-share-one-iommu.patch | 46 +++++++++++ .../logitech-c-270-even-more-broken.patch | 32 ++++++++ ...-bit-if-enable-bit-cannot-be-changed.patch | 68 +++++++++++++++ queue-6.6/series | 7 ++ ...ing-wrong-type-with-posix-extensions.patch | 43 ++++++++++ 8 files changed, 373 insertions(+) create mode 100644 queue-6.6/cifs-all-initializations-for-tcon-should-happen-in-tcon_info_alloc.patch create mode 100644 queue-6.6/dma-buf-fix-timeout-handling-in-dma_resv_wait_timeout-v2.patch create mode 100644 queue-6.6/i2c-designware-fix-an-initialization-issue.patch create mode 100644 queue-6.6/iommu-rockchip-prevent-iommus-dead-loop-when-two-masters-share-one-iommu.patch create mode 100644 queue-6.6/logitech-c-270-even-more-broken.patch create mode 100644 queue-6.6/powercap-intel_rapl-do-not-change-clamping-bit-if-enable-bit-cannot-be-changed.patch create mode 100644 queue-6.6/smb-client-fix-readdir-returning-wrong-type-with-posix-extensions.patch diff --git a/queue-6.6/cifs-all-initializations-for-tcon-should-happen-in-tcon_info_alloc.patch b/queue-6.6/cifs-all-initializations-for-tcon-should-happen-in-tcon_info_alloc.patch new file mode 100644 index 0000000000..fa09f4f7fc --- /dev/null +++ b/queue-6.6/cifs-all-initializations-for-tcon-should-happen-in-tcon_info_alloc.patch @@ -0,0 +1,82 @@ +From 74ebd02163fde05baa23129e06dde4b8f0f2377a Mon Sep 17 00:00:00 2001 +From: Shyam Prasad N +Date: Mon, 30 Jun 2025 23:09:34 +0530 +Subject: cifs: all initializations for tcon should happen in tcon_info_alloc + +From: Shyam Prasad N + +commit 74ebd02163fde05baa23129e06dde4b8f0f2377a upstream. + +Today, a few work structs inside tcon are initialized inside +cifs_get_tcon and not in tcon_info_alloc. As a result, if a tcon +is obtained from tcon_info_alloc, but not called as a part of +cifs_get_tcon, we may trip over. + +Cc: +Signed-off-by: Shyam Prasad N +Reviewed-by: Paulo Alcantara (Red Hat) +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/cifsproto.h | 1 + + fs/smb/client/connect.c | 8 +------- + fs/smb/client/misc.c | 6 ++++++ + 3 files changed, 8 insertions(+), 7 deletions(-) + +--- a/fs/smb/client/cifsproto.h ++++ b/fs/smb/client/cifsproto.h +@@ -136,6 +136,7 @@ extern int SendReceiveBlockingLock(const + struct smb_hdr *out_buf, + int *bytes_returned); + ++void smb2_query_server_interfaces(struct work_struct *work); + void + cifs_signal_cifsd_for_reconnect(struct TCP_Server_Info *server, + bool all_channels); +--- a/fs/smb/client/connect.c ++++ b/fs/smb/client/connect.c +@@ -113,7 +113,7 @@ static int reconn_set_ipaddr_from_hostna + return rc; + } + +-static void smb2_query_server_interfaces(struct work_struct *work) ++void smb2_query_server_interfaces(struct work_struct *work) + { + int rc; + int xid; +@@ -2807,20 +2807,14 @@ cifs_get_tcon(struct cifs_ses *ses, stru + tcon->max_cached_dirs = ctx->max_cached_dirs; + tcon->nodelete = ctx->nodelete; + tcon->local_lease = ctx->local_lease; +- INIT_LIST_HEAD(&tcon->pending_opens); + tcon->status = TID_GOOD; + +- INIT_DELAYED_WORK(&tcon->query_interfaces, +- smb2_query_server_interfaces); + if (ses->server->dialect >= SMB30_PROT_ID && + (ses->server->capabilities & SMB2_GLOBAL_CAP_MULTI_CHANNEL)) { + /* schedule query interfaces poll */ + queue_delayed_work(cifsiod_wq, &tcon->query_interfaces, + (SMB_INTERFACE_POLL_INTERVAL * HZ)); + } +-#ifdef CONFIG_CIFS_DFS_UPCALL +- INIT_DELAYED_WORK(&tcon->dfs_cache_work, dfs_cache_refresh); +-#endif + spin_lock(&cifs_tcp_ses_lock); + list_add(&tcon->tcon_list, &ses->tcon_list); + spin_unlock(&cifs_tcp_ses_lock); +--- a/fs/smb/client/misc.c ++++ b/fs/smb/client/misc.c +@@ -1359,6 +1359,12 @@ int cifs_inval_name_dfs_link_error(const + return 0; + } + #endif ++ INIT_LIST_HEAD(&ret_buf->pending_opens); ++ INIT_DELAYED_WORK(&ret_buf->query_interfaces, ++ smb2_query_server_interfaces); ++#ifdef CONFIG_CIFS_DFS_UPCALL ++ INIT_DELAYED_WORK(&ret_buf->dfs_cache_work, dfs_cache_refresh); ++#endif + + int cifs_wait_for_server_reconnect(struct TCP_Server_Info *server, bool retry) + { diff --git a/queue-6.6/dma-buf-fix-timeout-handling-in-dma_resv_wait_timeout-v2.patch b/queue-6.6/dma-buf-fix-timeout-handling-in-dma_resv_wait_timeout-v2.patch new file mode 100644 index 0000000000..805e7ce696 --- /dev/null +++ b/queue-6.6/dma-buf-fix-timeout-handling-in-dma_resv_wait_timeout-v2.patch @@ -0,0 +1,56 @@ +From 2b95a7db6e0f75587bffddbb490399cbb87e4985 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20K=C3=B6nig?= +Date: Tue, 28 Jan 2025 10:47:48 +0100 +Subject: dma-buf: fix timeout handling in dma_resv_wait_timeout v2 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian König + +commit 2b95a7db6e0f75587bffddbb490399cbb87e4985 upstream. + +Even the kerneldoc says that with a zero timeout the function should not +wait for anything, but still return 1 to indicate that the fences are +signaled now. + +Unfortunately that isn't what was implemented, instead of only returning +1 we also waited for at least one jiffies. + +Fix that by adjusting the handling to what the function is actually +documented to do. + +v2: improve code readability + +Reported-by: Marek Olšák +Reported-by: Lucas Stach +Signed-off-by: Christian König +Reviewed-by: Lucas Stach +Cc: +Link: https://lore.kernel.org/r/20250129105841.1806-1-christian.koenig@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma-buf/dma-resv.c | 12 +++++++----- + 1 file changed, 7 insertions(+), 5 deletions(-) + +--- a/drivers/dma-buf/dma-resv.c ++++ b/drivers/dma-buf/dma-resv.c +@@ -678,11 +678,13 @@ long dma_resv_wait_timeout(struct dma_re + dma_resv_iter_begin(&cursor, obj, usage); + dma_resv_for_each_fence_unlocked(&cursor, fence) { + +- ret = dma_fence_wait_timeout(fence, intr, ret); +- if (ret <= 0) { +- dma_resv_iter_end(&cursor); +- return ret; +- } ++ ret = dma_fence_wait_timeout(fence, intr, timeout); ++ if (ret <= 0) ++ break; ++ ++ /* Even for zero timeout the return value is 1 */ ++ if (timeout) ++ timeout = ret; + } + dma_resv_iter_end(&cursor); + diff --git a/queue-6.6/i2c-designware-fix-an-initialization-issue.patch b/queue-6.6/i2c-designware-fix-an-initialization-issue.patch new file mode 100644 index 0000000000..0f9fffe68a --- /dev/null +++ b/queue-6.6/i2c-designware-fix-an-initialization-issue.patch @@ -0,0 +1,39 @@ +From 3d30048958e0d43425f6d4e76565e6249fa71050 Mon Sep 17 00:00:00 2001 +From: "Michael J. Ruhl" +Date: Fri, 27 Jun 2025 10:35:11 -0400 +Subject: i2c/designware: Fix an initialization issue + +From: Michael J. Ruhl + +commit 3d30048958e0d43425f6d4e76565e6249fa71050 upstream. + +The i2c_dw_xfer_init() function requires msgs and msg_write_idx from the +dev context to be initialized. + +amd_i2c_dw_xfer_quirk() inits msgs and msgs_num, but not msg_write_idx. + +This could allow an out of bounds access (of msgs). + +Initialize msg_write_idx before calling i2c_dw_xfer_init(). + +Reviewed-by: Andy Shevchenko +Fixes: 17631e8ca2d3 ("i2c: designware: Add driver support for AMD NAVI GPU") +Cc: # v5.13+ +Signed-off-by: Michael J. Ruhl +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/20250627143511.489570-1-michael.j.ruhl@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-designware-master.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/i2c/busses/i2c-designware-master.c ++++ b/drivers/i2c/busses/i2c-designware-master.c +@@ -327,6 +327,7 @@ static int amd_i2c_dw_xfer_quirk(struct + + dev->msgs = msgs; + dev->msgs_num = num_msgs; ++ dev->msg_write_idx = 0; + i2c_dw_xfer_init(dev); + regmap_write(dev->map, DW_IC_INTR_MASK, 0); + diff --git a/queue-6.6/iommu-rockchip-prevent-iommus-dead-loop-when-two-masters-share-one-iommu.patch b/queue-6.6/iommu-rockchip-prevent-iommus-dead-loop-when-two-masters-share-one-iommu.patch new file mode 100644 index 0000000000..70a7e64471 --- /dev/null +++ b/queue-6.6/iommu-rockchip-prevent-iommus-dead-loop-when-two-masters-share-one-iommu.patch @@ -0,0 +1,46 @@ +From 62e062a29ad5133f67c20b333ba0a952a99161ae Mon Sep 17 00:00:00 2001 +From: Simon Xue +Date: Mon, 23 Jun 2025 10:00:18 +0800 +Subject: iommu/rockchip: prevent iommus dead loop when two masters share one IOMMU + +From: Simon Xue + +commit 62e062a29ad5133f67c20b333ba0a952a99161ae upstream. + +When two masters share an IOMMU, calling ops->of_xlate during +the second master's driver init may overwrite iommu->domain set +by the first. This causes the check if (iommu->domain == domain) +in rk_iommu_attach_device() to fail, resulting in the same +iommu->node being added twice to &rk_domain->iommus, which can +lead to an infinite loop in subsequent &rk_domain->iommus operations. + +Cc: +Fixes: 25c2325575cc ("iommu/rockchip: Add missing set_platform_dma_ops callback") +Signed-off-by: Simon Xue +Reviewed-by: Robin Murphy +Link: https://lore.kernel.org/r/20250623020018.584802-1-xxm@rock-chips.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/rockchip-iommu.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/iommu/rockchip-iommu.c ++++ b/drivers/iommu/rockchip-iommu.c +@@ -1177,7 +1177,6 @@ static int rk_iommu_of_xlate(struct devi + iommu_dev = of_find_device_by_node(args->np); + + data->iommu = platform_get_drvdata(iommu_dev); +- data->iommu->domain = &rk_identity_domain; + dev_iommu_priv_set(dev, data); + + platform_device_put(iommu_dev); +@@ -1217,6 +1216,8 @@ static int rk_iommu_probe(struct platfor + if (!iommu) + return -ENOMEM; + ++ iommu->domain = &rk_identity_domain; ++ + platform_set_drvdata(pdev, iommu); + iommu->dev = dev; + iommu->num_mmu = 0; diff --git a/queue-6.6/logitech-c-270-even-more-broken.patch b/queue-6.6/logitech-c-270-even-more-broken.patch new file mode 100644 index 0000000000..b1ed04e6ac --- /dev/null +++ b/queue-6.6/logitech-c-270-even-more-broken.patch @@ -0,0 +1,32 @@ +From cee4392a57e14a799fbdee193bc4c0de65b29521 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Thu, 5 Jun 2025 14:28:45 +0200 +Subject: Logitech C-270 even more broken + +From: Oliver Neukum + +commit cee4392a57e14a799fbdee193bc4c0de65b29521 upstream. + +Some varieties of this device don't work with +RESET_RESUME alone. + +Signed-off-by: Oliver Neukum +Cc: stable +Link: https://lore.kernel.org/r/20250605122852.1440382-1-oneukum@suse.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/quirks.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/usb/core/quirks.c ++++ b/drivers/usb/core/quirks.c +@@ -227,7 +227,8 @@ static const struct usb_device_id usb_qu + { USB_DEVICE(0x046a, 0x0023), .driver_info = USB_QUIRK_RESET_RESUME }, + + /* Logitech HD Webcam C270 */ +- { USB_DEVICE(0x046d, 0x0825), .driver_info = USB_QUIRK_RESET_RESUME }, ++ { USB_DEVICE(0x046d, 0x0825), .driver_info = USB_QUIRK_RESET_RESUME | ++ USB_QUIRK_NO_LPM}, + + /* Logitech HD Pro Webcams C920, C920-C, C922, C925e and C930e */ + { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT }, diff --git a/queue-6.6/powercap-intel_rapl-do-not-change-clamping-bit-if-enable-bit-cannot-be-changed.patch b/queue-6.6/powercap-intel_rapl-do-not-change-clamping-bit-if-enable-bit-cannot-be-changed.patch new file mode 100644 index 0000000000..d72f48fd41 --- /dev/null +++ b/queue-6.6/powercap-intel_rapl-do-not-change-clamping-bit-if-enable-bit-cannot-be-changed.patch @@ -0,0 +1,68 @@ +From 964209202ebe1569c858337441e87ef0f9d71416 Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Thu, 19 Jun 2025 15:13:40 +0800 +Subject: powercap: intel_rapl: Do not change CLAMPING bit if ENABLE bit cannot be changed + +From: Zhang Rui + +commit 964209202ebe1569c858337441e87ef0f9d71416 upstream. + +PL1 cannot be disabled on some platforms. The ENABLE bit is still set +after software clears it. This behavior leads to a scenario where, upon +user request to disable the Power Limit through the powercap sysfs, the +ENABLE bit remains set while the CLAMPING bit is inadvertently cleared. + +According to the Intel Software Developer's Manual, the CLAMPING bit, +"When set, allows the processor to go below the OS requested P states in +order to maintain the power below specified Platform Power Limit value." + +Thus this means the system may operate at higher power levels than +intended on such platforms. + +Enhance the code to check ENABLE bit after writing to it, and stop +further processing if ENABLE bit cannot be changed. + +Reported-by: Srinivas Pandruvada +Fixes: 2d281d8196e3 ("PowerCap: Introduce Intel RAPL power capping driver") +Cc: All applicable +Signed-off-by: Zhang Rui +Link: https://patch.msgid.link/20250619071340.384782-1-rui.zhang@intel.com +[ rjw: Use str_enabled_disabled() instead of open-coded equivalent ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/powercap/intel_rapl_common.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/drivers/powercap/intel_rapl_common.c ++++ b/drivers/powercap/intel_rapl_common.c +@@ -338,12 +338,28 @@ static int set_domain_enable(struct powe + { + struct rapl_domain *rd = power_zone_to_rapl_domain(power_zone); + struct rapl_defaults *defaults = get_defaults(rd->rp); ++ u64 val; + int ret; + + cpus_read_lock(); + ret = rapl_write_pl_data(rd, POWER_LIMIT1, PL_ENABLE, mode); +- if (!ret && defaults->set_floor_freq) ++ if (ret) ++ goto end; ++ ++ ret = rapl_read_pl_data(rd, POWER_LIMIT1, PL_ENABLE, false, &val); ++ if (ret) ++ goto end; ++ ++ if (mode != val) { ++ pr_debug("%s cannot be %s\n", power_zone->name, ++ str_enabled_disabled(mode)); ++ goto end; ++ } ++ ++ if (defaults->set_floor_freq) + defaults->set_floor_freq(rd, mode); ++ ++end: + cpus_read_unlock(); + + return ret; diff --git a/queue-6.6/series b/queue-6.6/series index 19e5a7ed3a..e82132387f 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -114,3 +114,10 @@ input-xpad-support-acer-ngr-200-controller.patch input-iqs7222-explicitly-define-number-of-external-channels.patch usb-cdnsp-do-not-disable-slot-for-disabled-slot.patch usb-chipidea-udc-disconnect-reconnect-from-host-when-do-suspend-resume.patch +smb-client-fix-readdir-returning-wrong-type-with-posix-extensions.patch +cifs-all-initializations-for-tcon-should-happen-in-tcon_info_alloc.patch +dma-buf-fix-timeout-handling-in-dma_resv_wait_timeout-v2.patch +i2c-designware-fix-an-initialization-issue.patch +logitech-c-270-even-more-broken.patch +iommu-rockchip-prevent-iommus-dead-loop-when-two-masters-share-one-iommu.patch +powercap-intel_rapl-do-not-change-clamping-bit-if-enable-bit-cannot-be-changed.patch diff --git a/queue-6.6/smb-client-fix-readdir-returning-wrong-type-with-posix-extensions.patch b/queue-6.6/smb-client-fix-readdir-returning-wrong-type-with-posix-extensions.patch new file mode 100644 index 0000000000..4c4255d8b4 --- /dev/null +++ b/queue-6.6/smb-client-fix-readdir-returning-wrong-type-with-posix-extensions.patch @@ -0,0 +1,43 @@ +From b8f89cb723b9e66f5dbd7199e4036fee34fb0de0 Mon Sep 17 00:00:00 2001 +From: Philipp Kerling +Date: Sun, 29 Jun 2025 19:05:05 +0200 +Subject: smb: client: fix readdir returning wrong type with POSIX extensions + +From: Philipp Kerling + +commit b8f89cb723b9e66f5dbd7199e4036fee34fb0de0 upstream. + +When SMB 3.1.1 POSIX Extensions are negotiated, userspace applications +using readdir() or getdents() calls without stat() on each individual file +(such as a simple "ls" or "find") would misidentify file types and exhibit +strange behavior such as not descending into directories. The reason for +this behavior is an oversight in the cifs_posix_to_fattr conversion +function. Instead of extracting the entry type for cf_dtype from the +properly converted cf_mode field, it tries to extract the type from the +PDU. While the wire representation of the entry mode is similar in +structure to POSIX stat(), the assignments of the entry types are +different. Applying the S_DT macro to cf_mode instead yields the correct +result. This is also what the equivalent function +smb311_posix_info_to_fattr in inode.c already does for stat() etc.; which +is why "ls -l" would give the correct file type but "ls" would not (as +identified by the colors). + +Cc: stable@vger.kernel.org +Signed-off-by: Philipp Kerling +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/readdir.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/smb/client/readdir.c ++++ b/fs/smb/client/readdir.c +@@ -263,7 +263,7 @@ cifs_posix_to_fattr(struct cifs_fattr *f + /* The Mode field in the response can now include the file type as well */ + fattr->cf_mode = wire_mode_to_posix(le32_to_cpu(info->Mode), + fattr->cf_cifsattrs & ATTR_DIRECTORY); +- fattr->cf_dtype = S_DT(le32_to_cpu(info->Mode)); ++ fattr->cf_dtype = S_DT(fattr->cf_mode); + + switch (fattr->cf_mode & S_IFMT) { + case S_IFLNK: -- 2.47.2