From d811f1b209b0f0b56a0b2af5563996928efdb7dd Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 21 Jul 2023 16:30:35 +0200 Subject: [PATCH] 6.1-stable patches added patches: bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch ceph-add-a-dedicated-private-data-for-netfs-rreq.patch ceph-don-t-let-check_caps-skip-sending-responses-for-revoke-msgs.patch ceph-fix-blindly-expanding-the-readahead-windows.patch cifs-if-deferred-close-is-disabled-then-close-files-immediately.patch dm-verity-loadpin-add-null-pointer-check-for-bdev-parameter.patch drm-amd-pm-conditionally-disable-pcie-lane-speed-switching-for-smu13.patch drm-amd-pm-share-the-code-around-smu13-pcie-parameters-update.patch ftrace-fix-possible-warning-on-checking-all-pages-used-in-ftrace_process_locs.patch libceph-harden-msgr2.1-frame-segment-length-checks.patch meson-saradc-fix-clock-divider-mask-length.patch net-ena-fix-shift-out-of-bounds-in-exponential-backoff.patch nvme-don-t-reject-probe-due-to-duplicate-ids-for-single-ported-pcie-devices.patch opp-fix-use-after-free-in-lazy_opp_tables-after-probe-deferral.patch perf-risc-v-remove-perf_hes_stopped-flag-checking-in-riscv_pmu_start.patch perf-x86-fix-lockdep-warning-in-for_each_sibling_event-on-spr.patch pm-qos-restore-support-for-default-value-on-frequency-qos.patch pwm-meson-fix-handling-of-period-duty-if-greater-than-uint_max.patch pwm-meson-modify-and-simplify-calculation-in-meson_pwm_get_state.patch regmap-irq-fix-out-of-bounds-access-when-allocating-config-buffers.patch revert-8250-add-support-for-asix-devices-with-a-fifo-bug.patch ring-buffer-fix-deadloop-issue-on-reading-trace_pipe.patch s390-decompressor-fix-misaligned-symbol-build-error.patch samples-ftrace-save-required-argument-registers-in-sample-trampolines.patch soundwire-qcom-fix-storing-port-config-out-of-bounds.patch tracing-fix-memory-leak-of-iter-temp-when-reading-trace_pipe.patch tracing-histograms-add-histograms-to-hist_vars-if-they-have-referenced-variables.patch xhci-fix-resume-issue-of-some-zhaoxin-hosts.patch xhci-fix-trb-prefetch-issue-of-zhaoxin-hosts.patch xhci-show-zhaoxin-xhci-root-hub-speed-correctly.patch xtensa-iss-fix-call-to-split_if_spec.patch --- .../bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch | 40 ++++ ...edicated-private-data-for-netfs-rreq.patch | 131 ++++++++++++++ ...ip-sending-responses-for-revoke-msgs.patch | 47 +++++ ...ndly-expanding-the-readahead-windows.patch | 87 +++++++++ ...isabled-then-close-files-immediately.patch | 36 ++++ ...ull-pointer-check-for-bdev-parameter.patch | 44 +++++ ...-pcie-lane-speed-switching-for-smu13.patch | 93 ++++++++++ ...-around-smu13-pcie-parameters-update.patch | 171 ++++++++++++++++++ ...ll-pages-used-in-ftrace_process_locs.patch | 131 ++++++++++++++ ...-msgr2.1-frame-segment-length-checks.patch | 100 ++++++++++ ...saradc-fix-clock-divider-mask-length.patch | 37 ++++ ...out-of-bounds-in-exponential-backoff.patch | 81 +++++++++ ...e-ids-for-single-ported-pcie-devices.patch | 77 ++++++++ ...lazy_opp_tables-after-probe-deferral.patch | 54 ++++++ ...ped-flag-checking-in-riscv_pmu_start.patch | 90 +++++++++ ...ing-in-for_each_sibling_event-on-spr.patch | 67 +++++++ ...t-for-default-value-on-frequency-qos.patch | 68 +++++++ ...period-duty-if-greater-than-uint_max.patch | 80 ++++++++ ...y-calculation-in-meson_pwm_get_state.patch | 55 ++++++ ...ccess-when-allocating-config-buffers.patch | 66 +++++++ ...ort-for-asix-devices-with-a-fifo-bug.patch | 139 ++++++++++++++ ...deadloop-issue-on-reading-trace_pipe.patch | 128 +++++++++++++ ...or-fix-misaligned-symbol-build-error.patch | 53 ++++++ ...ment-registers-in-sample-trampolines.patch | 68 +++++++ queue-6.1/series | 31 ++++ ...ix-storing-port-config-out-of-bounds.patch | 43 +++++ ...of-iter-temp-when-reading-trace_pipe.patch | 52 ++++++ ...rs-if-they-have-referenced-variables.patch | 127 +++++++++++++ ...x-resume-issue-of-some-zhaoxin-hosts.patch | 38 ++++ ...-trb-prefetch-issue-of-zhaoxin-hosts.patch | 71 ++++++++ ...haoxin-xhci-root-hub-speed-correctly.patch | 127 +++++++++++++ ...xtensa-iss-fix-call-to-split_if_spec.patch | 34 ++++ 32 files changed, 2466 insertions(+) create mode 100644 queue-6.1/bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch create mode 100644 queue-6.1/ceph-add-a-dedicated-private-data-for-netfs-rreq.patch create mode 100644 queue-6.1/ceph-don-t-let-check_caps-skip-sending-responses-for-revoke-msgs.patch create mode 100644 queue-6.1/ceph-fix-blindly-expanding-the-readahead-windows.patch create mode 100644 queue-6.1/cifs-if-deferred-close-is-disabled-then-close-files-immediately.patch create mode 100644 queue-6.1/dm-verity-loadpin-add-null-pointer-check-for-bdev-parameter.patch create mode 100644 queue-6.1/drm-amd-pm-conditionally-disable-pcie-lane-speed-switching-for-smu13.patch create mode 100644 queue-6.1/drm-amd-pm-share-the-code-around-smu13-pcie-parameters-update.patch create mode 100644 queue-6.1/ftrace-fix-possible-warning-on-checking-all-pages-used-in-ftrace_process_locs.patch create mode 100644 queue-6.1/libceph-harden-msgr2.1-frame-segment-length-checks.patch create mode 100644 queue-6.1/meson-saradc-fix-clock-divider-mask-length.patch create mode 100644 queue-6.1/net-ena-fix-shift-out-of-bounds-in-exponential-backoff.patch create mode 100644 queue-6.1/nvme-don-t-reject-probe-due-to-duplicate-ids-for-single-ported-pcie-devices.patch create mode 100644 queue-6.1/opp-fix-use-after-free-in-lazy_opp_tables-after-probe-deferral.patch create mode 100644 queue-6.1/perf-risc-v-remove-perf_hes_stopped-flag-checking-in-riscv_pmu_start.patch create mode 100644 queue-6.1/perf-x86-fix-lockdep-warning-in-for_each_sibling_event-on-spr.patch create mode 100644 queue-6.1/pm-qos-restore-support-for-default-value-on-frequency-qos.patch create mode 100644 queue-6.1/pwm-meson-fix-handling-of-period-duty-if-greater-than-uint_max.patch create mode 100644 queue-6.1/pwm-meson-modify-and-simplify-calculation-in-meson_pwm_get_state.patch create mode 100644 queue-6.1/regmap-irq-fix-out-of-bounds-access-when-allocating-config-buffers.patch create mode 100644 queue-6.1/revert-8250-add-support-for-asix-devices-with-a-fifo-bug.patch create mode 100644 queue-6.1/ring-buffer-fix-deadloop-issue-on-reading-trace_pipe.patch create mode 100644 queue-6.1/s390-decompressor-fix-misaligned-symbol-build-error.patch create mode 100644 queue-6.1/samples-ftrace-save-required-argument-registers-in-sample-trampolines.patch create mode 100644 queue-6.1/soundwire-qcom-fix-storing-port-config-out-of-bounds.patch create mode 100644 queue-6.1/tracing-fix-memory-leak-of-iter-temp-when-reading-trace_pipe.patch create mode 100644 queue-6.1/tracing-histograms-add-histograms-to-hist_vars-if-they-have-referenced-variables.patch create mode 100644 queue-6.1/xhci-fix-resume-issue-of-some-zhaoxin-hosts.patch create mode 100644 queue-6.1/xhci-fix-trb-prefetch-issue-of-zhaoxin-hosts.patch create mode 100644 queue-6.1/xhci-show-zhaoxin-xhci-root-hub-speed-correctly.patch create mode 100644 queue-6.1/xtensa-iss-fix-call-to-split_if_spec.patch diff --git a/queue-6.1/bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch b/queue-6.1/bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch new file mode 100644 index 00000000000..07e6920883a --- /dev/null +++ b/queue-6.1/bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch @@ -0,0 +1,40 @@ +From 6722e46513e0af8e2fff4698f7cb78bc50a9f13f Mon Sep 17 00:00:00 2001 +From: Jonas Gorski +Date: Sat, 24 Jun 2023 14:21:39 +0200 +Subject: bus: ixp4xx: fix IXP4XX_EXP_T1_MASK + +From: Jonas Gorski + +commit 6722e46513e0af8e2fff4698f7cb78bc50a9f13f upstream. + +The IXP4XX_EXP_T1_MASK was shifted one bit to the right, overlapping +IXP4XX_EXP_T2_MASK and leaving bit 29 unused. The offset being wrong is +also confirmed at least by the datasheet of IXP45X/46X [1]. + +Fix this by aligning it to IXP4XX_EXP_T1_SHIFT. + +[1] https://www.intel.com/content/dam/www/public/us/en/documents/manuals/ixp45x-ixp46x-developers-manual.pdf + +Cc: stable@vger.kernel.org +Fixes: 1c953bda90ca ("bus: ixp4xx: Add a driver for IXP4xx expansion bus") +Signed-off-by: Jonas Gorski +Link: https://lore.kernel.org/r/20230624112958.27727-1-jonas.gorski@gmail.com +Signed-off-by: Linus Walleij +Link: https://lore.kernel.org/r/20230624122139.3229642-1-linus.walleij@linaro.org +Signed-off-by: Arnd Bergmann +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bus/intel-ixp4xx-eb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/bus/intel-ixp4xx-eb.c ++++ b/drivers/bus/intel-ixp4xx-eb.c +@@ -33,7 +33,7 @@ + #define IXP4XX_EXP_TIMING_STRIDE 0x04 + #define IXP4XX_EXP_CS_EN BIT(31) + #define IXP456_EXP_PAR_EN BIT(30) /* Only on IXP45x and IXP46x */ +-#define IXP4XX_EXP_T1_MASK GENMASK(28, 27) ++#define IXP4XX_EXP_T1_MASK GENMASK(29, 28) + #define IXP4XX_EXP_T1_SHIFT 28 + #define IXP4XX_EXP_T2_MASK GENMASK(27, 26) + #define IXP4XX_EXP_T2_SHIFT 26 diff --git a/queue-6.1/ceph-add-a-dedicated-private-data-for-netfs-rreq.patch b/queue-6.1/ceph-add-a-dedicated-private-data-for-netfs-rreq.patch new file mode 100644 index 00000000000..4c1db4d99ea --- /dev/null +++ b/queue-6.1/ceph-add-a-dedicated-private-data-for-netfs-rreq.patch @@ -0,0 +1,131 @@ +From 23ee27dce30e7d3091d6c3143b79f48dab6f9a3e Mon Sep 17 00:00:00 2001 +From: Xiubo Li +Date: Wed, 10 May 2023 19:55:46 +0800 +Subject: ceph: add a dedicated private data for netfs rreq + +From: Xiubo Li + +commit 23ee27dce30e7d3091d6c3143b79f48dab6f9a3e upstream. + +We need to save the 'f_ra.ra_pages' to expand the readahead window +later. + +Cc: stable@vger.kernel.org +Fixes: 49870056005c ("ceph: convert ceph_readpages to ceph_readahead") +Link: https://lore.kernel.org/ceph-devel/20230504082510.247-1-sehuww@mail.scut.edu.cn +Link: https://www.spinics.net/lists/ceph-users/msg76183.html +Signed-off-by: Xiubo Li +Reviewed-and-tested-by: Hu Weiwen +Reviewed-by: Milind Changire +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/addr.c | 45 ++++++++++++++++++++++++++++++++++----------- + fs/ceph/super.h | 13 +++++++++++++ + 2 files changed, 47 insertions(+), 11 deletions(-) + +--- a/fs/ceph/addr.c ++++ b/fs/ceph/addr.c +@@ -362,18 +362,28 @@ static int ceph_init_request(struct netf + { + struct inode *inode = rreq->inode; + int got = 0, want = CEPH_CAP_FILE_CACHE; ++ struct ceph_netfs_request_data *priv; + int ret = 0; + + if (rreq->origin != NETFS_READAHEAD) + return 0; + ++ priv = kzalloc(sizeof(*priv), GFP_NOFS); ++ if (!priv) ++ return -ENOMEM; ++ + if (file) { + struct ceph_rw_context *rw_ctx; + struct ceph_file_info *fi = file->private_data; + ++ priv->file_ra_pages = file->f_ra.ra_pages; ++ priv->file_ra_disabled = file->f_mode & FMODE_RANDOM; ++ + rw_ctx = ceph_find_rw_context(fi); +- if (rw_ctx) ++ if (rw_ctx) { ++ rreq->netfs_priv = priv; + return 0; ++ } + } + + /* +@@ -383,27 +393,40 @@ static int ceph_init_request(struct netf + ret = ceph_try_get_caps(inode, CEPH_CAP_FILE_RD, want, true, &got); + if (ret < 0) { + dout("start_read %p, error getting cap\n", inode); +- return ret; ++ goto out; + } + + if (!(got & want)) { + dout("start_read %p, no cache cap\n", inode); +- return -EACCES; ++ ret = -EACCES; ++ goto out; ++ } ++ if (ret == 0) { ++ ret = -EACCES; ++ goto out; + } +- if (ret == 0) +- return -EACCES; + +- rreq->netfs_priv = (void *)(uintptr_t)got; +- return 0; ++ priv->caps = got; ++ rreq->netfs_priv = priv; ++ ++out: ++ if (ret < 0) ++ kfree(priv); ++ ++ return ret; + } + + static void ceph_netfs_free_request(struct netfs_io_request *rreq) + { +- struct ceph_inode_info *ci = ceph_inode(rreq->inode); +- int got = (uintptr_t)rreq->netfs_priv; ++ struct ceph_netfs_request_data *priv = rreq->netfs_priv; ++ ++ if (!priv) ++ return; + +- if (got) +- ceph_put_cap_refs(ci, got); ++ if (priv->caps) ++ ceph_put_cap_refs(ceph_inode(rreq->inode), priv->caps); ++ kfree(priv); ++ rreq->netfs_priv = NULL; + } + + const struct netfs_request_ops ceph_netfs_ops = { +--- a/fs/ceph/super.h ++++ b/fs/ceph/super.h +@@ -451,6 +451,19 @@ struct ceph_inode_info { + unsigned long i_work_mask; + }; + ++struct ceph_netfs_request_data { ++ int caps; ++ ++ /* ++ * Maximum size of a file readahead request. ++ * The fadvise could update the bdi's default ra_pages. ++ */ ++ unsigned int file_ra_pages; ++ ++ /* Set it if fadvise disables file readahead entirely */ ++ bool file_ra_disabled; ++}; ++ + static inline struct ceph_inode_info * + ceph_inode(const struct inode *inode) + { diff --git a/queue-6.1/ceph-don-t-let-check_caps-skip-sending-responses-for-revoke-msgs.patch b/queue-6.1/ceph-don-t-let-check_caps-skip-sending-responses-for-revoke-msgs.patch new file mode 100644 index 00000000000..cf7081e2294 --- /dev/null +++ b/queue-6.1/ceph-don-t-let-check_caps-skip-sending-responses-for-revoke-msgs.patch @@ -0,0 +1,47 @@ +From 257e6172ab36ebbe295a6c9ee9a9dd0fe54c1dc2 Mon Sep 17 00:00:00 2001 +From: Xiubo Li +Date: Wed, 28 Jun 2023 07:57:09 +0800 +Subject: ceph: don't let check_caps skip sending responses for revoke msgs + +From: Xiubo Li + +commit 257e6172ab36ebbe295a6c9ee9a9dd0fe54c1dc2 upstream. + +If a client sends out a cap update dropping caps with the prior 'seq' +just before an incoming cap revoke request, then the client may drop +the revoke because it believes it's already released the requested +capabilities. + +This causes the MDS to wait indefinitely for the client to respond +to the revoke. It's therefore always a good idea to ack the cap +revoke request with the bumped up 'seq'. + +Cc: stable@vger.kernel.org +Link: https://tracker.ceph.com/issues/61782 +Signed-off-by: Xiubo Li +Reviewed-by: Milind Changire +Reviewed-by: Patrick Donnelly +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/caps.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/fs/ceph/caps.c ++++ b/fs/ceph/caps.c +@@ -3561,6 +3561,15 @@ static void handle_cap_grant(struct inod + } + BUG_ON(cap->issued & ~cap->implemented); + ++ /* don't let check_caps skip sending a response to MDS for revoke msgs */ ++ if (le32_to_cpu(grant->op) == CEPH_CAP_OP_REVOKE) { ++ cap->mds_wanted = 0; ++ if (cap == ci->i_auth_cap) ++ check_caps = 1; /* check auth cap only */ ++ else ++ check_caps = 2; /* check all caps */ ++ } ++ + if (extra_info->inline_version > 0 && + extra_info->inline_version >= ci->i_inline_version) { + ci->i_inline_version = extra_info->inline_version; diff --git a/queue-6.1/ceph-fix-blindly-expanding-the-readahead-windows.patch b/queue-6.1/ceph-fix-blindly-expanding-the-readahead-windows.patch new file mode 100644 index 00000000000..86d826adca1 --- /dev/null +++ b/queue-6.1/ceph-fix-blindly-expanding-the-readahead-windows.patch @@ -0,0 +1,87 @@ +From dc94bb8f271c079f69583d0f12a489aaf5202751 Mon Sep 17 00:00:00 2001 +From: Xiubo Li +Date: Thu, 4 May 2023 19:00:42 +0800 +Subject: ceph: fix blindly expanding the readahead windows + +From: Xiubo Li + +commit dc94bb8f271c079f69583d0f12a489aaf5202751 upstream. + +Blindly expanding the readahead windows will cause unneccessary +pagecache thrashing and also will introduce the network workload. +We should disable expanding the windows if the readahead is disabled +and also shouldn't expand the windows too much. + +Expanding forward firstly instead of expanding backward for possible +sequential reads. + +Bound `rreq->len` to the actual file size to restore the previous page +cache usage. + +The posix_fadvise may change the maximum size of a file readahead. + +Cc: stable@vger.kernel.org +Fixes: 49870056005c ("ceph: convert ceph_readpages to ceph_readahead") +Link: https://lore.kernel.org/ceph-devel/20230504082510.247-1-sehuww@mail.scut.edu.cn +Link: https://www.spinics.net/lists/ceph-users/msg76183.html +Signed-off-by: Xiubo Li +Reviewed-and-tested-by: Hu Weiwen +Reviewed-by: Milind Changire +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/addr.c | 40 +++++++++++++++++++++++++++++++++------- + 1 file changed, 33 insertions(+), 7 deletions(-) + +--- a/fs/ceph/addr.c ++++ b/fs/ceph/addr.c +@@ -187,16 +187,42 @@ static void ceph_netfs_expand_readahead( + struct inode *inode = rreq->inode; + struct ceph_inode_info *ci = ceph_inode(inode); + struct ceph_file_layout *lo = &ci->i_layout; ++ unsigned long max_pages = inode->i_sb->s_bdi->ra_pages; ++ loff_t end = rreq->start + rreq->len, new_end; ++ struct ceph_netfs_request_data *priv = rreq->netfs_priv; ++ unsigned long max_len; + u32 blockoff; +- u64 blockno; + +- /* Expand the start downward */ +- blockno = div_u64_rem(rreq->start, lo->stripe_unit, &blockoff); +- rreq->start = blockno * lo->stripe_unit; +- rreq->len += blockoff; ++ if (priv) { ++ /* Readahead is disabled by posix_fadvise POSIX_FADV_RANDOM */ ++ if (priv->file_ra_disabled) ++ max_pages = 0; ++ else ++ max_pages = priv->file_ra_pages; + +- /* Now, round up the length to the next block */ +- rreq->len = roundup(rreq->len, lo->stripe_unit); ++ } ++ ++ /* Readahead is disabled */ ++ if (!max_pages) ++ return; ++ ++ max_len = max_pages << PAGE_SHIFT; ++ ++ /* ++ * Try to expand the length forward by rounding up it to the next ++ * block, but do not exceed the file size, unless the original ++ * request already exceeds it. ++ */ ++ new_end = min(round_up(end, lo->stripe_unit), rreq->i_size); ++ if (new_end > end && new_end <= rreq->start + max_len) ++ rreq->len = new_end - rreq->start; ++ ++ /* Try to expand the start downward */ ++ div_u64_rem(rreq->start, lo->stripe_unit, &blockoff); ++ if (rreq->len + blockoff <= max_len) { ++ rreq->start -= blockoff; ++ rreq->len += blockoff; ++ } + } + + static bool ceph_netfs_clamp_length(struct netfs_io_subrequest *subreq) diff --git a/queue-6.1/cifs-if-deferred-close-is-disabled-then-close-files-immediately.patch b/queue-6.1/cifs-if-deferred-close-is-disabled-then-close-files-immediately.patch new file mode 100644 index 00000000000..474d27fbe33 --- /dev/null +++ b/queue-6.1/cifs-if-deferred-close-is-disabled-then-close-files-immediately.patch @@ -0,0 +1,36 @@ +From df9d70c18616760c6504b97fec66b6379c172dbb Mon Sep 17 00:00:00 2001 +From: Bharath SM +Date: Fri, 7 Jul 2023 15:29:01 +0000 +Subject: cifs: if deferred close is disabled then close files immediately + +From: Bharath SM + +commit df9d70c18616760c6504b97fec66b6379c172dbb upstream. + +If defer close timeout value is set to 0, then there is no +need to include files in the deferred close list and utilize +the delayed worker for closing. Instead, we can close them +immediately. + +Signed-off-by: Bharath SM +Reviewed-by: Shyam Prasad N +Cc: stable@vger.kernel.org +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/file.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/smb/client/file.c ++++ b/fs/smb/client/file.c +@@ -954,8 +954,8 @@ int cifs_close(struct inode *inode, stru + cfile = file->private_data; + file->private_data = NULL; + dclose = kmalloc(sizeof(struct cifs_deferred_close), GFP_KERNEL); +- if ((cinode->oplock == CIFS_CACHE_RHW_FLG) && +- cinode->lease_granted && ++ if ((cifs_sb->ctx->closetimeo && cinode->oplock == CIFS_CACHE_RHW_FLG) ++ && cinode->lease_granted && + !test_bit(CIFS_INO_CLOSE_ON_LOCK, &cinode->flags) && + dclose) { + if (test_and_clear_bit(CIFS_INO_MODIFIED_ATTR, &cinode->flags)) { diff --git a/queue-6.1/dm-verity-loadpin-add-null-pointer-check-for-bdev-parameter.patch b/queue-6.1/dm-verity-loadpin-add-null-pointer-check-for-bdev-parameter.patch new file mode 100644 index 00000000000..2ccff5b6b58 --- /dev/null +++ b/queue-6.1/dm-verity-loadpin-add-null-pointer-check-for-bdev-parameter.patch @@ -0,0 +1,44 @@ +From 47f04616f2c9b2f4f0c9127e30ca515a078db591 Mon Sep 17 00:00:00 2001 +From: Matthias Kaehlcke +Date: Tue, 27 Jun 2023 20:28:01 +0000 +Subject: dm: verity-loadpin: Add NULL pointer check for 'bdev' parameter + +From: Matthias Kaehlcke + +commit 47f04616f2c9b2f4f0c9127e30ca515a078db591 upstream. + +Add a NULL check for the 'bdev' parameter of +dm_verity_loadpin_is_bdev_trusted(). The function is called +by loadpin_check(), which passes the block device that +corresponds to the super block of the file system from which +a file is being loaded. Generally a super_block structure has +an associated block device, however that is not always the +case (e.g. tmpfs). + +Cc: stable@vger.kernel.org # v6.0+ +Fixes: b6c1c5745ccc ("dm: Add verity helpers for LoadPin") +Signed-off-by: Matthias Kaehlcke +Link: https://lore.kernel.org/r/20230627202800.1.Id63f7f59536d20f1ab83e1abdc1fda1471c7d031@changeid +Signed-off-by: Kees Cook +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-verity-loadpin.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/md/dm-verity-loadpin.c b/drivers/md/dm-verity-loadpin.c +index 4f78cc55c251..0666699b6858 100644 +--- a/drivers/md/dm-verity-loadpin.c ++++ b/drivers/md/dm-verity-loadpin.c +@@ -58,6 +58,9 @@ bool dm_verity_loadpin_is_bdev_trusted(struct block_device *bdev) + int srcu_idx; + bool trusted = false; + ++ if (bdev == NULL) ++ return false; ++ + if (list_empty(&dm_verity_loadpin_trusted_root_digests)) + return false; + +-- +2.41.0 + diff --git a/queue-6.1/drm-amd-pm-conditionally-disable-pcie-lane-speed-switching-for-smu13.patch b/queue-6.1/drm-amd-pm-conditionally-disable-pcie-lane-speed-switching-for-smu13.patch new file mode 100644 index 00000000000..417de19b15c --- /dev/null +++ b/queue-6.1/drm-amd-pm-conditionally-disable-pcie-lane-speed-switching-for-smu13.patch @@ -0,0 +1,93 @@ +From 31c7a3b378a136adc63296a2ff17645896fcf303 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Fri, 7 Jul 2023 14:31:35 -0500 +Subject: drm/amd/pm: conditionally disable pcie lane/speed switching for SMU13 + +From: Mario Limonciello + +commit 31c7a3b378a136adc63296a2ff17645896fcf303 upstream. + +Intel platforms such as Sapphire Rapids and Raptor Lake don't support +dynamic pcie lane or speed switching. + +This limitation seems to carry over from one generation to another. +To be safer, disable dynamic pcie lane width and speed switching when +running on an Intel platform. + +Link: https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processors-datasheet-volume-1-of-2/005/pci-express-support/ +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2663 +Co-developed-by: Evan Quan +Signed-off-by: Evan Quan +Signed-off-by: Mario Limonciello +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org # 6.1.x +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 42 +++++++++++++++++++++++-- + 1 file changed, 39 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c +@@ -2490,6 +2490,25 @@ int smu_v13_0_mode1_reset(struct smu_con + return ret; + } + ++/* ++ * Intel hosts such as Raptor Lake and Sapphire Rapids don't support dynamic ++ * speed switching. Until we have confirmation from Intel that a specific host ++ * supports it, it's safer that we keep it disabled for all. ++ * ++ * https://edc.intel.com/content/www/us/en/design/products/platforms/details/raptor-lake-s/13th-generation-core-processors-datasheet-volume-1-of-2/005/pci-express-support/ ++ * https://gitlab.freedesktop.org/drm/amd/-/issues/2663 ++ */ ++static bool smu_v13_0_is_pcie_dynamic_switching_supported(void) ++{ ++#if IS_ENABLED(CONFIG_X86) ++ struct cpuinfo_x86 *c = &cpu_data(0); ++ ++ if (c->x86_vendor == X86_VENDOR_INTEL) ++ return false; ++#endif ++ return true; ++} ++ + int smu_v13_0_update_pcie_parameters(struct smu_context *smu, + uint32_t pcie_gen_cap, + uint32_t pcie_width_cap) +@@ -2497,15 +2516,32 @@ int smu_v13_0_update_pcie_parameters(str + struct smu_13_0_dpm_context *dpm_context = smu->smu_dpm.dpm_context; + struct smu_13_0_pcie_table *pcie_table = + &dpm_context->dpm_tables.pcie_table; ++ int num_of_levels = pcie_table->num_of_link_levels; + uint32_t smu_pcie_arg; + int ret, i; + +- for (i = 0; i < pcie_table->num_of_link_levels; i++) { +- if (pcie_table->pcie_gen[i] > pcie_gen_cap) ++ if (!smu_v13_0_is_pcie_dynamic_switching_supported()) { ++ if (pcie_table->pcie_gen[num_of_levels - 1] < pcie_gen_cap) ++ pcie_gen_cap = pcie_table->pcie_gen[num_of_levels - 1]; ++ ++ if (pcie_table->pcie_lane[num_of_levels - 1] < pcie_width_cap) ++ pcie_width_cap = pcie_table->pcie_lane[num_of_levels - 1]; ++ ++ /* Force all levels to use the same settings */ ++ for (i = 0; i < num_of_levels; i++) { + pcie_table->pcie_gen[i] = pcie_gen_cap; +- if (pcie_table->pcie_lane[i] > pcie_width_cap) + pcie_table->pcie_lane[i] = pcie_width_cap; ++ } ++ } else { ++ for (i = 0; i < num_of_levels; i++) { ++ if (pcie_table->pcie_gen[i] > pcie_gen_cap) ++ pcie_table->pcie_gen[i] = pcie_gen_cap; ++ if (pcie_table->pcie_lane[i] > pcie_width_cap) ++ pcie_table->pcie_lane[i] = pcie_width_cap; ++ } ++ } + ++ for (i = 0; i < num_of_levels; i++) { + smu_pcie_arg = i << 16; + smu_pcie_arg |= pcie_table->pcie_gen[i] << 8; + smu_pcie_arg |= pcie_table->pcie_lane[i]; diff --git a/queue-6.1/drm-amd-pm-share-the-code-around-smu13-pcie-parameters-update.patch b/queue-6.1/drm-amd-pm-share-the-code-around-smu13-pcie-parameters-update.patch new file mode 100644 index 00000000000..01ed84ab0fb --- /dev/null +++ b/queue-6.1/drm-amd-pm-share-the-code-around-smu13-pcie-parameters-update.patch @@ -0,0 +1,171 @@ +From dcb489bae65d92cfd26da22c7a0d6665b06ecc63 Mon Sep 17 00:00:00 2001 +From: Evan Quan +Date: Fri, 7 Jul 2023 14:31:34 -0500 +Subject: drm/amd/pm: share the code around SMU13 pcie parameters update + +From: Evan Quan + +commit dcb489bae65d92cfd26da22c7a0d6665b06ecc63 upstream. + +So that SMU13.0.0 and SMU13.0.7 do not need to have one copy each. + +Signed-off-by: Evan Quan +Signed-off-by: Mario Limonciello +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org # 6.1.x +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 4 ++ + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 31 +++++++++++++++++ + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 33 ------------------- + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 33 ------------------- + 4 files changed, 37 insertions(+), 64 deletions(-) + +--- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h ++++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h +@@ -297,5 +297,9 @@ int smu_v13_0_get_pptable_from_firmware( + uint32_t *size, + uint32_t pptable_id); + ++int smu_v13_0_update_pcie_parameters(struct smu_context *smu, ++ uint32_t pcie_gen_cap, ++ uint32_t pcie_width_cap); ++ + #endif + #endif +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c +@@ -2489,3 +2489,34 @@ int smu_v13_0_mode1_reset(struct smu_con + + return ret; + } ++ ++int smu_v13_0_update_pcie_parameters(struct smu_context *smu, ++ uint32_t pcie_gen_cap, ++ uint32_t pcie_width_cap) ++{ ++ struct smu_13_0_dpm_context *dpm_context = smu->smu_dpm.dpm_context; ++ struct smu_13_0_pcie_table *pcie_table = ++ &dpm_context->dpm_tables.pcie_table; ++ uint32_t smu_pcie_arg; ++ int ret, i; ++ ++ for (i = 0; i < pcie_table->num_of_link_levels; i++) { ++ if (pcie_table->pcie_gen[i] > pcie_gen_cap) ++ pcie_table->pcie_gen[i] = pcie_gen_cap; ++ if (pcie_table->pcie_lane[i] > pcie_width_cap) ++ pcie_table->pcie_lane[i] = pcie_width_cap; ++ ++ smu_pcie_arg = i << 16; ++ smu_pcie_arg |= pcie_table->pcie_gen[i] << 8; ++ smu_pcie_arg |= pcie_table->pcie_lane[i]; ++ ++ ret = smu_cmn_send_smc_msg_with_param(smu, ++ SMU_MSG_OverridePcieParameters, ++ smu_pcie_arg, ++ NULL); ++ if (ret) ++ return ret; ++ } ++ ++ return 0; ++} +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c +@@ -1216,37 +1216,6 @@ static int smu_v13_0_0_force_clk_levels( + return ret; + } + +-static int smu_v13_0_0_update_pcie_parameters(struct smu_context *smu, +- uint32_t pcie_gen_cap, +- uint32_t pcie_width_cap) +-{ +- struct smu_13_0_dpm_context *dpm_context = smu->smu_dpm.dpm_context; +- struct smu_13_0_pcie_table *pcie_table = +- &dpm_context->dpm_tables.pcie_table; +- uint32_t smu_pcie_arg; +- int ret, i; +- +- for (i = 0; i < pcie_table->num_of_link_levels; i++) { +- if (pcie_table->pcie_gen[i] > pcie_gen_cap) +- pcie_table->pcie_gen[i] = pcie_gen_cap; +- if (pcie_table->pcie_lane[i] > pcie_width_cap) +- pcie_table->pcie_lane[i] = pcie_width_cap; +- +- smu_pcie_arg = i << 16; +- smu_pcie_arg |= pcie_table->pcie_gen[i] << 8; +- smu_pcie_arg |= pcie_table->pcie_lane[i]; +- +- ret = smu_cmn_send_smc_msg_with_param(smu, +- SMU_MSG_OverridePcieParameters, +- smu_pcie_arg, +- NULL); +- if (ret) +- return ret; +- } +- +- return 0; +-} +- + static const struct smu_temperature_range smu13_thermal_policy[] = { + {-273150, 99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000}, + { 120000, 120000, 120000, 120000, 120000, 120000, 120000, 120000, 120000}, +@@ -2033,7 +2002,7 @@ static const struct pptable_funcs smu_v1 + .feature_is_enabled = smu_cmn_feature_is_enabled, + .print_clk_levels = smu_v13_0_0_print_clk_levels, + .force_clk_levels = smu_v13_0_0_force_clk_levels, +- .update_pcie_parameters = smu_v13_0_0_update_pcie_parameters, ++ .update_pcie_parameters = smu_v13_0_update_pcie_parameters, + .get_thermal_temperature_range = smu_v13_0_0_get_thermal_temperature_range, + .register_irq_handler = smu_v13_0_register_irq_handler, + .enable_thermal_alert = smu_v13_0_enable_thermal_alert, +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c +@@ -1225,37 +1225,6 @@ static int smu_v13_0_7_force_clk_levels( + return ret; + } + +-static int smu_v13_0_7_update_pcie_parameters(struct smu_context *smu, +- uint32_t pcie_gen_cap, +- uint32_t pcie_width_cap) +-{ +- struct smu_13_0_dpm_context *dpm_context = smu->smu_dpm.dpm_context; +- struct smu_13_0_pcie_table *pcie_table = +- &dpm_context->dpm_tables.pcie_table; +- uint32_t smu_pcie_arg; +- int ret, i; +- +- for (i = 0; i < pcie_table->num_of_link_levels; i++) { +- if (pcie_table->pcie_gen[i] > pcie_gen_cap) +- pcie_table->pcie_gen[i] = pcie_gen_cap; +- if (pcie_table->pcie_lane[i] > pcie_width_cap) +- pcie_table->pcie_lane[i] = pcie_width_cap; +- +- smu_pcie_arg = i << 16; +- smu_pcie_arg |= pcie_table->pcie_gen[i] << 8; +- smu_pcie_arg |= pcie_table->pcie_lane[i]; +- +- ret = smu_cmn_send_smc_msg_with_param(smu, +- SMU_MSG_OverridePcieParameters, +- smu_pcie_arg, +- NULL); +- if (ret) +- return ret; +- } +- +- return 0; +-} +- + static const struct smu_temperature_range smu13_thermal_policy[] = + { + {-273150, 99000, 99000, -273150, 99000, 99000, -273150, 99000, 99000}, +@@ -1750,7 +1719,7 @@ static const struct pptable_funcs smu_v1 + .feature_is_enabled = smu_cmn_feature_is_enabled, + .print_clk_levels = smu_v13_0_7_print_clk_levels, + .force_clk_levels = smu_v13_0_7_force_clk_levels, +- .update_pcie_parameters = smu_v13_0_7_update_pcie_parameters, ++ .update_pcie_parameters = smu_v13_0_update_pcie_parameters, + .get_thermal_temperature_range = smu_v13_0_7_get_thermal_temperature_range, + .register_irq_handler = smu_v13_0_register_irq_handler, + .enable_thermal_alert = smu_v13_0_enable_thermal_alert, diff --git a/queue-6.1/ftrace-fix-possible-warning-on-checking-all-pages-used-in-ftrace_process_locs.patch b/queue-6.1/ftrace-fix-possible-warning-on-checking-all-pages-used-in-ftrace_process_locs.patch new file mode 100644 index 00000000000..98968f058b8 --- /dev/null +++ b/queue-6.1/ftrace-fix-possible-warning-on-checking-all-pages-used-in-ftrace_process_locs.patch @@ -0,0 +1,131 @@ +From 26efd79c4624294e553aeaa3439c646729bad084 Mon Sep 17 00:00:00 2001 +From: Zheng Yejian +Date: Wed, 12 Jul 2023 14:04:52 +0800 +Subject: ftrace: Fix possible warning on checking all pages used in ftrace_process_locs() + +From: Zheng Yejian + +commit 26efd79c4624294e553aeaa3439c646729bad084 upstream. + +As comments in ftrace_process_locs(), there may be NULL pointers in +mcount_loc section: + > Some architecture linkers will pad between + > the different mcount_loc sections of different + > object files to satisfy alignments. + > Skip any NULL pointers. + +After commit 20e5227e9f55 ("ftrace: allow NULL pointers in mcount_loc"), +NULL pointers will be accounted when allocating ftrace pages but skipped +before adding into ftrace pages, this may result in some pages not being +used. Then after commit 706c81f87f84 ("ftrace: Remove extra helper +functions"), warning may occur at: + WARN_ON(pg->next); + +To fix it, only warn for case that no pointers skipped but pages not used +up, then free those unused pages after releasing ftrace_lock. + +Link: https://lore.kernel.org/linux-trace-kernel/20230712060452.3175675-1-zhengyejian1@huawei.com + +Cc: stable@vger.kernel.org +Fixes: 706c81f87f84 ("ftrace: Remove extra helper functions") +Suggested-by: Steven Rostedt +Signed-off-by: Zheng Yejian +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ftrace.c | 45 +++++++++++++++++++++++++++++++-------------- + 1 file changed, 31 insertions(+), 14 deletions(-) + +--- a/kernel/trace/ftrace.c ++++ b/kernel/trace/ftrace.c +@@ -3213,6 +3213,22 @@ static int ftrace_allocate_records(struc + return cnt; + } + ++static void ftrace_free_pages(struct ftrace_page *pages) ++{ ++ struct ftrace_page *pg = pages; ++ ++ while (pg) { ++ if (pg->records) { ++ free_pages((unsigned long)pg->records, pg->order); ++ ftrace_number_of_pages -= 1 << pg->order; ++ } ++ pages = pg->next; ++ kfree(pg); ++ pg = pages; ++ ftrace_number_of_groups--; ++ } ++} ++ + static struct ftrace_page * + ftrace_allocate_pages(unsigned long num_to_init) + { +@@ -3251,17 +3267,7 @@ ftrace_allocate_pages(unsigned long num_ + return start_pg; + + free_pages: +- pg = start_pg; +- while (pg) { +- if (pg->records) { +- free_pages((unsigned long)pg->records, pg->order); +- ftrace_number_of_pages -= 1 << pg->order; +- } +- start_pg = pg->next; +- kfree(pg); +- pg = start_pg; +- ftrace_number_of_groups--; +- } ++ ftrace_free_pages(start_pg); + pr_info("ftrace: FAILED to allocate memory for functions\n"); + return NULL; + } +@@ -6666,9 +6672,11 @@ static int ftrace_process_locs(struct mo + unsigned long *start, + unsigned long *end) + { ++ struct ftrace_page *pg_unuse = NULL; + struct ftrace_page *start_pg; + struct ftrace_page *pg; + struct dyn_ftrace *rec; ++ unsigned long skipped = 0; + unsigned long count; + unsigned long *p; + unsigned long addr; +@@ -6731,8 +6739,10 @@ static int ftrace_process_locs(struct mo + * object files to satisfy alignments. + * Skip any NULL pointers. + */ +- if (!addr) ++ if (!addr) { ++ skipped++; + continue; ++ } + + end_offset = (pg->index+1) * sizeof(pg->records[0]); + if (end_offset > PAGE_SIZE << pg->order) { +@@ -6746,8 +6756,10 @@ static int ftrace_process_locs(struct mo + rec->ip = addr; + } + +- /* We should have used all pages */ +- WARN_ON(pg->next); ++ if (pg->next) { ++ pg_unuse = pg->next; ++ pg->next = NULL; ++ } + + /* Assign the last page to ftrace_pages */ + ftrace_pages = pg; +@@ -6769,6 +6781,11 @@ static int ftrace_process_locs(struct mo + out: + mutex_unlock(&ftrace_lock); + ++ /* We should have used all pages unless we skipped some */ ++ if (pg_unuse) { ++ WARN_ON(!skipped); ++ ftrace_free_pages(pg_unuse); ++ } + return ret; + } + diff --git a/queue-6.1/libceph-harden-msgr2.1-frame-segment-length-checks.patch b/queue-6.1/libceph-harden-msgr2.1-frame-segment-length-checks.patch new file mode 100644 index 00000000000..b9a627a6965 --- /dev/null +++ b/queue-6.1/libceph-harden-msgr2.1-frame-segment-length-checks.patch @@ -0,0 +1,100 @@ +From a282a2f10539dce2aa619e71e1817570d557fc97 Mon Sep 17 00:00:00 2001 +From: Ilya Dryomov +Date: Mon, 10 Jul 2023 20:39:29 +0200 +Subject: libceph: harden msgr2.1 frame segment length checks + +From: Ilya Dryomov + +commit a282a2f10539dce2aa619e71e1817570d557fc97 upstream. + +ceph_frame_desc::fd_lens is an int array. decode_preamble() thus +effectively casts u32 -> int but the checks for segment lengths are +written as if on unsigned values. While reading in HELLO or one of the +AUTH frames (before authentication is completed), arithmetic in +head_onwire_len() can get duped by negative ctrl_len and produce +head_len which is less than CEPH_PREAMBLE_LEN but still positive. +This would lead to a buffer overrun in prepare_read_control() as the +preamble gets copied to the newly allocated buffer of size head_len. + +Cc: stable@vger.kernel.org +Fixes: cd1a677cad99 ("libceph, ceph: implement msgr2.1 protocol (crc and secure modes)") +Reported-by: Thelford Williams +Signed-off-by: Ilya Dryomov +Reviewed-by: Xiubo Li +Signed-off-by: Greg Kroah-Hartman +--- + net/ceph/messenger_v2.c | 41 ++++++++++++++++++++++++++--------------- + 1 file changed, 26 insertions(+), 15 deletions(-) + +--- a/net/ceph/messenger_v2.c ++++ b/net/ceph/messenger_v2.c +@@ -392,6 +392,8 @@ static int head_onwire_len(int ctrl_len, + int head_len; + int rem_len; + ++ BUG_ON(ctrl_len < 0 || ctrl_len > CEPH_MSG_MAX_CONTROL_LEN); ++ + if (secure) { + head_len = CEPH_PREAMBLE_SECURE_LEN; + if (ctrl_len > CEPH_PREAMBLE_INLINE_LEN) { +@@ -410,6 +412,10 @@ static int head_onwire_len(int ctrl_len, + static int __tail_onwire_len(int front_len, int middle_len, int data_len, + bool secure) + { ++ BUG_ON(front_len < 0 || front_len > CEPH_MSG_MAX_FRONT_LEN || ++ middle_len < 0 || middle_len > CEPH_MSG_MAX_MIDDLE_LEN || ++ data_len < 0 || data_len > CEPH_MSG_MAX_DATA_LEN); ++ + if (!front_len && !middle_len && !data_len) + return 0; + +@@ -522,29 +528,34 @@ static int decode_preamble(void *p, stru + desc->fd_aligns[i] = ceph_decode_16(&p); + } + +- /* +- * This would fire for FRAME_TAG_WAIT (it has one empty +- * segment), but we should never get it as client. +- */ +- if (!desc->fd_lens[desc->fd_seg_cnt - 1]) { +- pr_err("last segment empty\n"); ++ if (desc->fd_lens[0] < 0 || ++ desc->fd_lens[0] > CEPH_MSG_MAX_CONTROL_LEN) { ++ pr_err("bad control segment length %d\n", desc->fd_lens[0]); + return -EINVAL; + } +- +- if (desc->fd_lens[0] > CEPH_MSG_MAX_CONTROL_LEN) { +- pr_err("control segment too big %d\n", desc->fd_lens[0]); ++ if (desc->fd_lens[1] < 0 || ++ desc->fd_lens[1] > CEPH_MSG_MAX_FRONT_LEN) { ++ pr_err("bad front segment length %d\n", desc->fd_lens[1]); + return -EINVAL; + } +- if (desc->fd_lens[1] > CEPH_MSG_MAX_FRONT_LEN) { +- pr_err("front segment too big %d\n", desc->fd_lens[1]); ++ if (desc->fd_lens[2] < 0 || ++ desc->fd_lens[2] > CEPH_MSG_MAX_MIDDLE_LEN) { ++ pr_err("bad middle segment length %d\n", desc->fd_lens[2]); + return -EINVAL; + } +- if (desc->fd_lens[2] > CEPH_MSG_MAX_MIDDLE_LEN) { +- pr_err("middle segment too big %d\n", desc->fd_lens[2]); ++ if (desc->fd_lens[3] < 0 || ++ desc->fd_lens[3] > CEPH_MSG_MAX_DATA_LEN) { ++ pr_err("bad data segment length %d\n", desc->fd_lens[3]); + return -EINVAL; + } +- if (desc->fd_lens[3] > CEPH_MSG_MAX_DATA_LEN) { +- pr_err("data segment too big %d\n", desc->fd_lens[3]); ++ ++ /* ++ * This would fire for FRAME_TAG_WAIT (it has one empty ++ * segment), but we should never get it as client. ++ */ ++ if (!desc->fd_lens[desc->fd_seg_cnt - 1]) { ++ pr_err("last segment empty, segment count %d\n", ++ desc->fd_seg_cnt); + return -EINVAL; + } + diff --git a/queue-6.1/meson-saradc-fix-clock-divider-mask-length.patch b/queue-6.1/meson-saradc-fix-clock-divider-mask-length.patch new file mode 100644 index 00000000000..7a45af73f99 --- /dev/null +++ b/queue-6.1/meson-saradc-fix-clock-divider-mask-length.patch @@ -0,0 +1,37 @@ +From c57fa0037024c92c2ca34243e79e857da5d2c0a9 Mon Sep 17 00:00:00 2001 +From: George Stark +Date: Tue, 6 Jun 2023 19:53:57 +0300 +Subject: meson saradc: fix clock divider mask length + +From: George Stark + +commit c57fa0037024c92c2ca34243e79e857da5d2c0a9 upstream. + +According to the datasheets of supported meson SoCs length of ADC_CLK_DIV +field is 6-bit. Although all supported SoCs have the register +with that field documented later SoCs use external clock rather than +ADC internal clock so this patch affects only meson8 family (S8* SoCs). + +Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs") +Signed-off-by: George Stark +Reviewed-by: Andy Shevchenko +Reviewed-by: Martin Blumenstingl +Link: https://lore.kernel.org/r/20230606165357.42417-1-gnstark@sberdevices.ru +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/meson_saradc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/adc/meson_saradc.c ++++ b/drivers/iio/adc/meson_saradc.c +@@ -71,7 +71,7 @@ + #define MESON_SAR_ADC_REG3_PANEL_DETECT_COUNT_MASK GENMASK(20, 18) + #define MESON_SAR_ADC_REG3_PANEL_DETECT_FILTER_TB_MASK GENMASK(17, 16) + #define MESON_SAR_ADC_REG3_ADC_CLK_DIV_SHIFT 10 +- #define MESON_SAR_ADC_REG3_ADC_CLK_DIV_WIDTH 5 ++ #define MESON_SAR_ADC_REG3_ADC_CLK_DIV_WIDTH 6 + #define MESON_SAR_ADC_REG3_BLOCK_DLY_SEL_MASK GENMASK(9, 8) + #define MESON_SAR_ADC_REG3_BLOCK_DLY_MASK GENMASK(7, 0) + diff --git a/queue-6.1/net-ena-fix-shift-out-of-bounds-in-exponential-backoff.patch b/queue-6.1/net-ena-fix-shift-out-of-bounds-in-exponential-backoff.patch new file mode 100644 index 00000000000..5fc987da359 --- /dev/null +++ b/queue-6.1/net-ena-fix-shift-out-of-bounds-in-exponential-backoff.patch @@ -0,0 +1,81 @@ +From 1e9cb763e9bacf0c932aa948f50dcfca6f519a26 Mon Sep 17 00:00:00 2001 +From: Krister Johansen +Date: Mon, 10 Jul 2023 18:36:21 -0700 +Subject: net: ena: fix shift-out-of-bounds in exponential backoff + +From: Krister Johansen + +commit 1e9cb763e9bacf0c932aa948f50dcfca6f519a26 upstream. + +The ENA adapters on our instances occasionally reset. Once recently +logged a UBSAN failure to console in the process: + + UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13 + shift exponent 32 is too large for 32-bit type 'unsigned int' + CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 + Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 + Workqueue: ena ena_fw_reset_device [ena] + Call Trace: + + dump_stack_lvl+0x4a/0x63 + dump_stack+0x10/0x16 + ubsan_epilogue+0x9/0x36 + __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e + ? __const_udelay+0x43/0x50 + ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena] + wait_for_reset_state+0x54/0xa0 [ena] + ena_com_dev_reset+0xc8/0x110 [ena] + ena_down+0x3fe/0x480 [ena] + ena_destroy_device+0xeb/0xf0 [ena] + ena_fw_reset_device+0x30/0x50 [ena] + process_one_work+0x22b/0x3d0 + worker_thread+0x4d/0x3f0 + ? process_one_work+0x3d0/0x3d0 + kthread+0x12a/0x150 + ? set_kthread_struct+0x50/0x50 + ret_from_fork+0x22/0x30 + + +Apparently, the reset delays are getting so large they can trigger a +UBSAN panic. + +Looking at the code, the current timeout is capped at 5000us. Using a +base value of 100us, the current code will overflow after (1<<29). Even +at values before 32, this function wraps around, perhaps +unintentionally. + +Cap the value of the exponent used for this backoff at (1<<16) which is +larger than currently necessary, but large enough to support bigger +values in the future. + +Cc: stable@vger.kernel.org +Fixes: 4bb7f4cf60e3 ("net: ena: reduce driver load time") +Signed-off-by: Krister Johansen +Reviewed-by: Leon Romanovsky +Reviewed-by: Shay Agroskin +Link: https://lore.kernel.org/r/20230711013621.GE1926@templeofstupid.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/amazon/ena/ena_com.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/net/ethernet/amazon/ena/ena_com.c ++++ b/drivers/net/ethernet/amazon/ena/ena_com.c +@@ -35,6 +35,8 @@ + + #define ENA_REGS_ADMIN_INTR_MASK 1 + ++#define ENA_MAX_BACKOFF_DELAY_EXP 16U ++ + #define ENA_MIN_ADMIN_POLL_US 100 + + #define ENA_MAX_ADMIN_POLL_US 5000 +@@ -536,6 +538,7 @@ static int ena_com_comp_status_to_errno( + + static void ena_delay_exponential_backoff_us(u32 exp, u32 delay_us) + { ++ exp = min_t(u32, exp, ENA_MAX_BACKOFF_DELAY_EXP); + delay_us = max_t(u32, ENA_MIN_ADMIN_POLL_US, delay_us); + delay_us = min_t(u32, delay_us * (1U << exp), ENA_MAX_ADMIN_POLL_US); + usleep_range(delay_us, 2 * delay_us); diff --git a/queue-6.1/nvme-don-t-reject-probe-due-to-duplicate-ids-for-single-ported-pcie-devices.patch b/queue-6.1/nvme-don-t-reject-probe-due-to-duplicate-ids-for-single-ported-pcie-devices.patch new file mode 100644 index 00000000000..8c480e3dbf7 --- /dev/null +++ b/queue-6.1/nvme-don-t-reject-probe-due-to-duplicate-ids-for-single-ported-pcie-devices.patch @@ -0,0 +1,77 @@ +From ac522fc6c3165fd0daa2f8da7e07d5f800586daa Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Thu, 13 Jul 2023 15:30:42 +0200 +Subject: nvme: don't reject probe due to duplicate IDs for single-ported PCIe devices + +From: Christoph Hellwig + +commit ac522fc6c3165fd0daa2f8da7e07d5f800586daa upstream. + +While duplicate IDs are still very harmful, including the potential to easily +see changing devices in /dev/disk/by-id, it turn out they are extremely +common for cheap end user NVMe devices. + +Relax our check for them for so that it doesn't reject the probe on +single-ported PCIe devices, but prints a big warning instead. In doubt +we'd still like to see quirk entries to disable the potential for +changing supposed stable device identifier links, but this will at least +allow users how have two (or more) of these devices to use them without +having to manually add a new PCI ID entry with the quirk through sysfs or +by patching the kernel. + +Fixes: 2079f41ec6ff ("nvme: check that EUI/GUID/UUID are globally unique") +Cc: stable@vger.kernel.org # 6.0+ +Co-developed-by: Sagi Grimberg +Signed-off-by: Christoph Hellwig +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/core.c | 36 +++++++++++++++++++++++++++++++++--- + 1 file changed, 33 insertions(+), 3 deletions(-) + +--- a/drivers/nvme/host/core.c ++++ b/drivers/nvme/host/core.c +@@ -4175,10 +4175,40 @@ static int nvme_init_ns_head(struct nvme + + ret = nvme_global_check_duplicate_ids(ctrl->subsys, &info->ids); + if (ret) { +- dev_err(ctrl->device, +- "globally duplicate IDs for nsid %d\n", info->nsid); ++ /* ++ * We've found two different namespaces on two different ++ * subsystems that report the same ID. This is pretty nasty ++ * for anything that actually requires unique device ++ * identification. In the kernel we need this for multipathing, ++ * and in user space the /dev/disk/by-id/ links rely on it. ++ * ++ * If the device also claims to be multi-path capable back off ++ * here now and refuse the probe the second device as this is a ++ * recipe for data corruption. If not this is probably a ++ * cheap consumer device if on the PCIe bus, so let the user ++ * proceed and use the shiny toy, but warn that with changing ++ * probing order (which due to our async probing could just be ++ * device taking longer to startup) the other device could show ++ * up at any time. ++ */ + nvme_print_device_info(ctrl); +- return ret; ++ if ((ns->ctrl->ops->flags & NVME_F_FABRICS) || /* !PCIe */ ++ ((ns->ctrl->subsys->cmic & NVME_CTRL_CMIC_MULTI_CTRL) && ++ info->is_shared)) { ++ dev_err(ctrl->device, ++ "ignoring nsid %d because of duplicate IDs\n", ++ info->nsid); ++ return ret; ++ } ++ ++ dev_err(ctrl->device, ++ "clearing duplicate IDs for nsid %d\n", info->nsid); ++ dev_err(ctrl->device, ++ "use of /dev/disk/by-id/ may cause data corruption\n"); ++ memset(&info->ids.nguid, 0, sizeof(info->ids.nguid)); ++ memset(&info->ids.uuid, 0, sizeof(info->ids.uuid)); ++ memset(&info->ids.eui64, 0, sizeof(info->ids.eui64)); ++ ctrl->quirks |= NVME_QUIRK_BOGUS_NID; + } + + mutex_lock(&ctrl->subsys->lock); diff --git a/queue-6.1/opp-fix-use-after-free-in-lazy_opp_tables-after-probe-deferral.patch b/queue-6.1/opp-fix-use-after-free-in-lazy_opp_tables-after-probe-deferral.patch new file mode 100644 index 00000000000..a08539a994b --- /dev/null +++ b/queue-6.1/opp-fix-use-after-free-in-lazy_opp_tables-after-probe-deferral.patch @@ -0,0 +1,54 @@ +From b2a2ab039bd58f51355e33d7d3fc64605d7f870d Mon Sep 17 00:00:00 2001 +From: Stephan Gerhold +Date: Tue, 30 May 2023 17:54:46 +0200 +Subject: opp: Fix use-after-free in lazy_opp_tables after probe deferral + +From: Stephan Gerhold + +commit b2a2ab039bd58f51355e33d7d3fc64605d7f870d upstream. + +When dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns +-EPROBE_DEFER, the opp_table is freed again, to wait until all the +interconnect paths are available. + +However, if the OPP table is using required-opps then it may already +have been added to the global lazy_opp_tables list. The error path +does not remove the opp_table from the list again. + +This can cause crashes later when the provider of the required-opps +is added, since we will iterate over OPP tables that have already been +freed. E.g.: + + Unable to handle kernel NULL pointer dereference when read + CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3 + PC is at _of_add_opp_table_v2 (include/linux/of.h:949 + drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404 + drivers/opp/of.c:1032) -> lazy_link_required_opp_table() + +Fix this by calling _of_clear_opp_table() to remove the opp_table from +the list and clear other allocated resources. While at it, also add the +missing mutex_destroy() calls in the error path. + +Cc: stable@vger.kernel.org +Suggested-by: Viresh Kumar +Fixes: 7eba0c7641b0 ("opp: Allow lazy-linking of required-opps") +Signed-off-by: Stephan Gerhold +Signed-off-by: Viresh Kumar +Signed-off-by: Greg Kroah-Hartman +--- + drivers/opp/core.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/opp/core.c ++++ b/drivers/opp/core.c +@@ -1348,7 +1348,10 @@ static struct opp_table *_allocate_opp_t + return opp_table; + + remove_opp_dev: ++ _of_clear_opp_table(opp_table); + _remove_opp_dev(opp_dev, opp_table); ++ mutex_destroy(&opp_table->genpd_virt_dev_lock); ++ mutex_destroy(&opp_table->lock); + err: + kfree(opp_table); + return ERR_PTR(ret); diff --git a/queue-6.1/perf-risc-v-remove-perf_hes_stopped-flag-checking-in-riscv_pmu_start.patch b/queue-6.1/perf-risc-v-remove-perf_hes_stopped-flag-checking-in-riscv_pmu_start.patch new file mode 100644 index 00000000000..3c71b0918d0 --- /dev/null +++ b/queue-6.1/perf-risc-v-remove-perf_hes_stopped-flag-checking-in-riscv_pmu_start.patch @@ -0,0 +1,90 @@ +From 66843b14fb71825fdd73ab12f6594f2243b402be Mon Sep 17 00:00:00 2001 +From: Eric Lin +Date: Mon, 10 Jul 2023 15:43:28 +0000 +Subject: perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start() + +From: Eric Lin + +commit 66843b14fb71825fdd73ab12f6594f2243b402be upstream. + +Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the +perf_sample_event_took() function was added to report time spent in +overflow interrupts. If the interrupt takes too long, the perf framework +will lower the sysctl_perf_event_sample_rate and max_samples_per_tick. +When hwc->interrupts is larger than max_samples_per_tick, the +hwc->interrupts will be set to MAX_INTERRUPTS, and events will be +throttled within the __perf_event_account_interrupt() function. + +However, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the +PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler() +function to avoid throttling. When the perf framework unthrottled the event +in the timer interrupt handler, it triggers riscv_pmu_start() function +and causes a WARN_ON_ONCE() warning, as shown below: + + ------------[ cut here ]------------ + WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e + Modules linked in: + CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1 + Hardware name: SiFive (DT) + epc : riscv_pmu_start+0x7c/0x8e + ra : riscv_pmu_start+0x28/0x8e + epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0 + gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0 + t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720 + s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000 + a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000 + a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030 + s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00 + s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000 + s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340 + s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796 + t5 : 0000000700000000 t6 : ffffaf8005269870 + status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 + [] riscv_pmu_start+0x7c/0x8e + [] perf_adjust_freq_unthr_context+0x15e/0x174 + [] perf_event_task_tick+0x88/0x9c + [] scheduler_tick+0xfe/0x27c + [] update_process_times+0x9a/0xba + [] tick_sched_handle+0x32/0x66 + [] tick_sched_timer+0x64/0xb0 + [] __hrtimer_run_queues+0x156/0x2f4 + [] hrtimer_interrupt+0xe2/0x1fe + [] riscv_timer_interrupt+0x38/0x42 + [] handle_percpu_devid_irq+0x90/0x1d2 + [] generic_handle_domain_irq+0x28/0x36 + +After referring other PMU drivers like Arm, Loongarch, Csky, and Mips, +they don't call *_pmu_stop() to update with PERF_HES_STOPPED flag +after perf_event_overflow() function nor do they add PERF_HES_STOPPED +flag checking in *_pmu_start() which don't cause this warning. + +Thus, it's recommended to remove this unnecessary check in +riscv_pmu_start() function to prevent this warning. + +Signed-off-by: Eric Lin +Link: https://lore.kernel.org/r/20230710154328.19574-1-eric.lin@sifive.com +Fixes: 096b52fd2bb4 ("perf: RISC-V: throttle perf events") +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + drivers/perf/riscv_pmu.c | 3 --- + 1 file changed, 3 deletions(-) + +diff --git a/drivers/perf/riscv_pmu.c b/drivers/perf/riscv_pmu.c +index ebca5eab9c9b..56897d4d4fd3 100644 +--- a/drivers/perf/riscv_pmu.c ++++ b/drivers/perf/riscv_pmu.c +@@ -181,9 +181,6 @@ void riscv_pmu_start(struct perf_event *event, int flags) + uint64_t max_period = riscv_pmu_ctr_get_width_mask(event); + u64 init_val; + +- if (WARN_ON_ONCE(!(event->hw.state & PERF_HES_STOPPED))) +- return; +- + if (flags & PERF_EF_RELOAD) + WARN_ON_ONCE(!(event->hw.state & PERF_HES_UPTODATE)); + +-- +2.41.0 + diff --git a/queue-6.1/perf-x86-fix-lockdep-warning-in-for_each_sibling_event-on-spr.patch b/queue-6.1/perf-x86-fix-lockdep-warning-in-for_each_sibling_event-on-spr.patch new file mode 100644 index 00000000000..0abd5d033b9 --- /dev/null +++ b/queue-6.1/perf-x86-fix-lockdep-warning-in-for_each_sibling_event-on-spr.patch @@ -0,0 +1,67 @@ +From 27c68c216ee1f1b086e789a64486e6511e380b8a Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Tue, 4 Jul 2023 11:15:15 -0700 +Subject: perf/x86: Fix lockdep warning in for_each_sibling_event() on SPR + +From: Namhyung Kim + +commit 27c68c216ee1f1b086e789a64486e6511e380b8a upstream. + +On SPR, the load latency event needs an auxiliary event in the same +group to work properly. There's a check in intel_pmu_hw_config() +for this to iterate sibling events and find a mem-loads-aux event. + +The for_each_sibling_event() has a lockdep assert to make sure if it +disabled hardirq or hold leader->ctx->mutex. This works well if the +given event has a separate leader event since perf_try_init_event() +grabs the leader->ctx->mutex to protect the sibling list. But it can +cause a problem when the event itself is a leader since the event is +not initialized yet and there's no ctx for the event. + +Actually I got a lockdep warning when I run the below command on SPR, +but I guess it could be a NULL pointer dereference. + + $ perf record -d -e cpu/mem-loads/uP true + +The code path to the warning is: + + sys_perf_event_open() + perf_event_alloc() + perf_init_event() + perf_try_init_event() + x86_pmu_event_init() + hsw_hw_config() + intel_pmu_hw_config() + for_each_sibling_event() + lockdep_assert_event_ctx() + +We don't need for_each_sibling_event() when it's a standalone event. +Let's return the error code directly. + +Fixes: f3c0eba28704 ("perf: Add a few assertions") +Reported-by: Greg Thelen +Signed-off-by: Namhyung Kim +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20230704181516.3293665-1-namhyung@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/intel/core.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/arch/x86/events/intel/core.c ++++ b/arch/x86/events/intel/core.c +@@ -3975,6 +3975,13 @@ static int intel_pmu_hw_config(struct pe + struct perf_event *leader = event->group_leader; + struct perf_event *sibling = NULL; + ++ /* ++ * When this memload event is also the first event (no group ++ * exists yet), then there is no aux event before it. ++ */ ++ if (leader == event) ++ return -ENODATA; ++ + if (!is_mem_loads_aux_event(leader)) { + for_each_sibling_event(sibling, leader) { + if (is_mem_loads_aux_event(sibling)) diff --git a/queue-6.1/pm-qos-restore-support-for-default-value-on-frequency-qos.patch b/queue-6.1/pm-qos-restore-support-for-default-value-on-frequency-qos.patch new file mode 100644 index 00000000000..f9e11feb8f3 --- /dev/null +++ b/queue-6.1/pm-qos-restore-support-for-default-value-on-frequency-qos.patch @@ -0,0 +1,68 @@ +From 3a8395b565b5b4f019b3dc182be4c4541eb35ac8 Mon Sep 17 00:00:00 2001 +From: Chungkai Yang +Date: Wed, 5 Jul 2023 16:59:07 +0800 +Subject: PM: QoS: Restore support for default value on frequency QoS + +From: Chungkai Yang + +commit 3a8395b565b5b4f019b3dc182be4c4541eb35ac8 upstream. + +Commit 8d36694245f2 ("PM: QoS: Add check to make sure CPU freq is +non-negative") makes sure CPU freq is non-negative to avoid negative +value converting to unsigned data type. However, when the value is +PM_QOS_DEFAULT_VALUE, pm_qos_update_target specifically uses +c->default_value which is set to FREQ_QOS_MIN/MAX_DEFAULT_VALUE when +cpufreq_policy_alloc is executed, for this case handling. + +Adding check for PM_QOS_DEFAULT_VALUE to let default setting work will +fix this problem. + +Fixes: 8d36694245f2 ("PM: QoS: Add check to make sure CPU freq is non-negative") +Link: https://lore.kernel.org/lkml/20230626035144.19717-1-Chung-kai.Yang@mediatek.com/ +Link: https://lore.kernel.org/lkml/20230627071727.16646-1-Chung-kai.Yang@mediatek.com/ +Link: https://lore.kernel.org/lkml/CAJZ5v0gxNOWhC58PHeUhW_tgf6d1fGJVZ1x91zkDdht11yUv-A@mail.gmail.com/ +Signed-off-by: Chungkai Yang +Cc: 6.0+ # 6.0+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + kernel/power/qos.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/kernel/power/qos.c b/kernel/power/qos.c +index af51ed6d45ef..782d3b41c1f3 100644 +--- a/kernel/power/qos.c ++++ b/kernel/power/qos.c +@@ -426,6 +426,11 @@ late_initcall(cpu_latency_qos_init); + + /* Definitions related to the frequency QoS below. */ + ++static inline bool freq_qos_value_invalid(s32 value) ++{ ++ return value < 0 && value != PM_QOS_DEFAULT_VALUE; ++} ++ + /** + * freq_constraints_init - Initialize frequency QoS constraints. + * @qos: Frequency QoS constraints to initialize. +@@ -531,7 +536,7 @@ int freq_qos_add_request(struct freq_constraints *qos, + { + int ret; + +- if (IS_ERR_OR_NULL(qos) || !req || value < 0) ++ if (IS_ERR_OR_NULL(qos) || !req || freq_qos_value_invalid(value)) + return -EINVAL; + + if (WARN(freq_qos_request_active(req), +@@ -563,7 +568,7 @@ EXPORT_SYMBOL_GPL(freq_qos_add_request); + */ + int freq_qos_update_request(struct freq_qos_request *req, s32 new_value) + { +- if (!req || new_value < 0) ++ if (!req || freq_qos_value_invalid(new_value)) + return -EINVAL; + + if (WARN(!freq_qos_request_active(req), +-- +2.41.0 + diff --git a/queue-6.1/pwm-meson-fix-handling-of-period-duty-if-greater-than-uint_max.patch b/queue-6.1/pwm-meson-fix-handling-of-period-duty-if-greater-than-uint_max.patch new file mode 100644 index 00000000000..74ea4e5182b --- /dev/null +++ b/queue-6.1/pwm-meson-fix-handling-of-period-duty-if-greater-than-uint_max.patch @@ -0,0 +1,80 @@ +From 87a2cbf02d7701255f9fcca7e5bd864a7bb397cf Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Wed, 24 May 2023 21:48:36 +0200 +Subject: pwm: meson: fix handling of period/duty if greater than UINT_MAX +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Heiner Kallweit + +commit 87a2cbf02d7701255f9fcca7e5bd864a7bb397cf upstream. + +state->period/duty are of type u64, and if their value is greater than +UINT_MAX, then the cast to uint will cause problems. Fix this by +changing the type of the respective local variables to u64. + +Fixes: b79c3670e120 ("pwm: meson: Don't duplicate the polarity internally") +Cc: stable@vger.kernel.org +Suggested-by: Uwe Kleine-König +Reviewed-by: Martin Blumenstingl +Signed-off-by: Heiner Kallweit +Signed-off-by: Thierry Reding +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pwm/pwm-meson.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/pwm/pwm-meson.c ++++ b/drivers/pwm/pwm-meson.c +@@ -156,8 +156,9 @@ static int meson_pwm_calc(struct meson_p + const struct pwm_state *state) + { + struct meson_pwm_channel *channel = &meson->channels[pwm->hwpwm]; +- unsigned int duty, period, pre_div, cnt, duty_cnt; ++ unsigned int pre_div, cnt, duty_cnt; + unsigned long fin_freq; ++ u64 duty, period; + + duty = state->duty_cycle; + period = state->period; +@@ -179,19 +180,19 @@ static int meson_pwm_calc(struct meson_p + + dev_dbg(meson->chip.dev, "fin_freq: %lu Hz\n", fin_freq); + +- pre_div = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * 0xffffLL); ++ pre_div = div64_u64(fin_freq * period, NSEC_PER_SEC * 0xffffLL); + if (pre_div > MISC_CLK_DIV_MASK) { + dev_err(meson->chip.dev, "unable to get period pre_div\n"); + return -EINVAL; + } + +- cnt = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * (pre_div + 1)); ++ cnt = div64_u64(fin_freq * period, NSEC_PER_SEC * (pre_div + 1)); + if (cnt > 0xffff) { + dev_err(meson->chip.dev, "unable to get period cnt\n"); + return -EINVAL; + } + +- dev_dbg(meson->chip.dev, "period=%u pre_div=%u cnt=%u\n", period, ++ dev_dbg(meson->chip.dev, "period=%llu pre_div=%u cnt=%u\n", period, + pre_div, cnt); + + if (duty == period) { +@@ -204,14 +205,13 @@ static int meson_pwm_calc(struct meson_p + channel->lo = cnt; + } else { + /* Then check is we can have the duty with the same pre_div */ +- duty_cnt = div64_u64(fin_freq * (u64)duty, +- NSEC_PER_SEC * (pre_div + 1)); ++ duty_cnt = div64_u64(fin_freq * duty, NSEC_PER_SEC * (pre_div + 1)); + if (duty_cnt > 0xffff) { + dev_err(meson->chip.dev, "unable to get duty cycle\n"); + return -EINVAL; + } + +- dev_dbg(meson->chip.dev, "duty=%u pre_div=%u duty_cnt=%u\n", ++ dev_dbg(meson->chip.dev, "duty=%llu pre_div=%u duty_cnt=%u\n", + duty, pre_div, duty_cnt); + + channel->pre_div = pre_div; diff --git a/queue-6.1/pwm-meson-modify-and-simplify-calculation-in-meson_pwm_get_state.patch b/queue-6.1/pwm-meson-modify-and-simplify-calculation-in-meson_pwm_get_state.patch new file mode 100644 index 00000000000..f9c94791bc5 --- /dev/null +++ b/queue-6.1/pwm-meson-modify-and-simplify-calculation-in-meson_pwm_get_state.patch @@ -0,0 +1,55 @@ +From 6b9352f3f8a1a35faf0efc1ad1807ee303467796 Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Wed, 24 May 2023 21:47:43 +0200 +Subject: pwm: meson: modify and simplify calculation in meson_pwm_get_state +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Heiner Kallweit + +commit 6b9352f3f8a1a35faf0efc1ad1807ee303467796 upstream. + +I don't see a reason why we should treat the case lo < hi differently +and return 0 as period and duty_cycle. The current logic was added with +c375bcbaabdb ("pwm: meson: Read the full hardware state in +meson_pwm_get_state()"), Martin as original author doesn't remember why +it was implemented this way back then. +So let's handle it as normal use case and also remove the optimization +for lo == 0. I think the improved readability is worth it. + +Fixes: c375bcbaabdb ("pwm: meson: Read the full hardware state in meson_pwm_get_state()") +Reviewed-by: Uwe Kleine-König +Reviewed-by: Dmitry Rokosov +Acked-by: Martin Blumenstingl +Cc: stable@vger.kernel.org +Signed-off-by: Heiner Kallweit +Signed-off-by: Thierry Reding +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pwm/pwm-meson.c | 14 ++------------ + 1 file changed, 2 insertions(+), 12 deletions(-) + +--- a/drivers/pwm/pwm-meson.c ++++ b/drivers/pwm/pwm-meson.c +@@ -351,18 +351,8 @@ static int meson_pwm_get_state(struct pw + channel->lo = FIELD_GET(PWM_LOW_MASK, value); + channel->hi = FIELD_GET(PWM_HIGH_MASK, value); + +- if (channel->lo == 0) { +- state->period = meson_pwm_cnt_to_ns(chip, pwm, channel->hi); +- state->duty_cycle = state->period; +- } else if (channel->lo >= channel->hi) { +- state->period = meson_pwm_cnt_to_ns(chip, pwm, +- channel->lo + channel->hi); +- state->duty_cycle = meson_pwm_cnt_to_ns(chip, pwm, +- channel->hi); +- } else { +- state->period = 0; +- state->duty_cycle = 0; +- } ++ state->period = meson_pwm_cnt_to_ns(chip, pwm, channel->lo + channel->hi); ++ state->duty_cycle = meson_pwm_cnt_to_ns(chip, pwm, channel->hi); + + state->polarity = PWM_POLARITY_NORMAL; + diff --git a/queue-6.1/regmap-irq-fix-out-of-bounds-access-when-allocating-config-buffers.patch b/queue-6.1/regmap-irq-fix-out-of-bounds-access-when-allocating-config-buffers.patch new file mode 100644 index 00000000000..745a701fc16 --- /dev/null +++ b/queue-6.1/regmap-irq-fix-out-of-bounds-access-when-allocating-config-buffers.patch @@ -0,0 +1,66 @@ +From 963b54df82b6d6206d7def273390bf3f7af558e1 Mon Sep 17 00:00:00 2001 +From: "Isaac J. Manjarres" +Date: Tue, 11 Jul 2023 12:30:58 -0700 +Subject: regmap-irq: Fix out-of-bounds access when allocating config buffers + +From: Isaac J. Manjarres + +commit 963b54df82b6d6206d7def273390bf3f7af558e1 upstream. + +When allocating the 2D array for handling IRQ type registers in +regmap_add_irq_chip_fwnode(), the intent is to allocate a matrix +with num_config_bases rows and num_config_regs columns. + +This is currently handled by allocating a buffer to hold a pointer for +each row (i.e. num_config_bases). After that, the logic attempts to +allocate the memory required to hold the register configuration for +each row. However, instead of doing this allocation for each row +(i.e. num_config_bases allocations), the logic erroneously does this +allocation num_config_regs number of times. + +This scenario can lead to out-of-bounds accesses when num_config_regs +is greater than num_config_bases. Fix this by updating the terminating +condition of the loop that allocates the memory for holding the register +configuration to allocate memory only for each row in the matrix. + +Amit Pundir reported a crash that was occurring on his db845c device +due to memory corruption (see "Closes" tag for Amit's report). The KASAN +report below helped narrow it down to this issue: + +[ 14.033877][ T1] ================================================================== +[ 14.042507][ T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364 +[ 14.050796][ T1] Write of size 8 at addr 06ffff8081021850 by task init/1 + +[ 14.242004][ T1] The buggy address belongs to the object at ffffff8081021850 +[ 14.242004][ T1] which belongs to the cache kmalloc-8 of size 8 +[ 14.255669][ T1] The buggy address is located 0 bytes inside of +[ 14.255669][ T1] 8-byte region [ffffff8081021850, ffffff8081021858) + +Fixes: faa87ce9196d ("regmap-irq: Introduce config registers for irq types") +Reported-by: Amit Pundir +Closes: https://lore.kernel.org/all/CAMi1Hd04mu6JojT3y6wyN2YeVkPR5R3qnkKJ8iR8if_YByCn4w@mail.gmail.com/ +Tested-by: John Stultz +Tested-by: Amit Pundir # tested on Dragonboard 845c +Cc: stable@vger.kernel.org # v6.0+ +Cc: Aidan MacDonald +Cc: Saravana Kannan +Cc: Catalin Marinas +Signed-off-by: "Isaac J. Manjarres" +Link: https://lore.kernel.org/r/20230711193059.2480971-1-isaacmanjarres@google.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/regmap/regmap-irq.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/base/regmap/regmap-irq.c ++++ b/drivers/base/regmap/regmap-irq.c +@@ -843,7 +843,7 @@ int regmap_add_irq_chip_fwnode(struct fw + if (!d->config_buf) + goto err_alloc; + +- for (i = 0; i < chip->num_config_regs; i++) { ++ for (i = 0; i < chip->num_config_bases; i++) { + d->config_buf[i] = kcalloc(chip->num_config_regs, + sizeof(**d->config_buf), + GFP_KERNEL); diff --git a/queue-6.1/revert-8250-add-support-for-asix-devices-with-a-fifo-bug.patch b/queue-6.1/revert-8250-add-support-for-asix-devices-with-a-fifo-bug.patch new file mode 100644 index 00000000000..20714de813a --- /dev/null +++ b/queue-6.1/revert-8250-add-support-for-asix-devices-with-a-fifo-bug.patch @@ -0,0 +1,139 @@ +From a82d62f708545d22859584e0e0620da8e3759bbc Mon Sep 17 00:00:00 2001 +From: Jiaqing Zhao +Date: Mon, 19 Jun 2023 15:57:44 +0000 +Subject: Revert "8250: add support for ASIX devices with a FIFO bug" + +From: Jiaqing Zhao + +commit a82d62f708545d22859584e0e0620da8e3759bbc upstream. + +This reverts commit eb26dfe8aa7eeb5a5aa0b7574550125f8aa4c3b3. + +Commit eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO +bug") merged on Jul 13, 2012 adds a quirk for PCI_VENDOR_ID_ASIX +(0x9710). But that ID is the same as PCI_VENDOR_ID_NETMOS defined in +1f8b061050c7 ("[PATCH] Netmos parallel/serial/combo support") merged +on Mar 28, 2005. In pci_serial_quirks array, the NetMos entry always +takes precedence over the ASIX entry even since it was initially +merged, code in that commit is always unreachable. + +In my tests, adding the FIFO workaround to pci_netmos_init() makes no +difference, and the vendor driver also does not have such workaround. +Given that the code was never used for over a decade, it's safe to +revert it. + +Also, the real PCI_VENDOR_ID_ASIX should be 0x125b, which is used on +their newer AX99100 PCIe serial controllers released on 2016. The FIFO +workaround should not be intended for these newer controllers, and it +was never implemented in vendor driver. + +Fixes: eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug") +Cc: stable +Signed-off-by: Jiaqing Zhao +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20230619155743.827859-1-jiaqing.zhao@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/8250/8250.h | 1 - + drivers/tty/serial/8250/8250_pci.c | 19 ------------------- + drivers/tty/serial/8250/8250_port.c | 11 +++-------- + include/linux/serial_8250.h | 1 - + 4 files changed, 3 insertions(+), 29 deletions(-) + +--- a/drivers/tty/serial/8250/8250.h ++++ b/drivers/tty/serial/8250/8250.h +@@ -91,7 +91,6 @@ struct serial8250_config { + #define UART_BUG_TXEN BIT(1) /* UART has buggy TX IIR status */ + #define UART_BUG_NOMSR BIT(2) /* UART has buggy MSR status bits (Au1x00) */ + #define UART_BUG_THRE BIT(3) /* UART has buggy THRE reassertion */ +-#define UART_BUG_PARITY BIT(4) /* UART mishandles parity if FIFO enabled */ + #define UART_BUG_TXRACE BIT(5) /* UART Tx fails to set remote DR */ + + +--- a/drivers/tty/serial/8250/8250_pci.c ++++ b/drivers/tty/serial/8250/8250_pci.c +@@ -1252,14 +1252,6 @@ static int pci_oxsemi_tornado_setup(stru + return pci_default_setup(priv, board, up, idx); + } + +-static int pci_asix_setup(struct serial_private *priv, +- const struct pciserial_board *board, +- struct uart_8250_port *port, int idx) +-{ +- port->bugs |= UART_BUG_PARITY; +- return pci_default_setup(priv, board, port, idx); +-} +- + #define QPCR_TEST_FOR1 0x3F + #define QPCR_TEST_GET1 0x00 + #define QPCR_TEST_FOR2 0x40 +@@ -1975,7 +1967,6 @@ pci_moxa_setup(struct serial_private *pr + #define PCI_DEVICE_ID_WCH_CH355_4S 0x7173 + #define PCI_VENDOR_ID_AGESTAR 0x5372 + #define PCI_DEVICE_ID_AGESTAR_9375 0x6872 +-#define PCI_VENDOR_ID_ASIX 0x9710 + #define PCI_DEVICE_ID_BROADCOM_TRUMANAGE 0x160a + #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800 0x818e + +@@ -2621,16 +2612,6 @@ static struct pci_serial_quirk pci_seria + .setup = pci_wch_ch38x_setup, + }, + /* +- * ASIX devices with FIFO bug +- */ +- { +- .vendor = PCI_VENDOR_ID_ASIX, +- .device = PCI_ANY_ID, +- .subvendor = PCI_ANY_ID, +- .subdevice = PCI_ANY_ID, +- .setup = pci_asix_setup, +- }, +- /* + * Broadcom TruManage (NetXtreme) + */ + { +--- a/drivers/tty/serial/8250/8250_port.c ++++ b/drivers/tty/serial/8250/8250_port.c +@@ -2629,11 +2629,8 @@ static unsigned char serial8250_compute_ + + if (c_cflag & CSTOPB) + cval |= UART_LCR_STOP; +- if (c_cflag & PARENB) { ++ if (c_cflag & PARENB) + cval |= UART_LCR_PARITY; +- if (up->bugs & UART_BUG_PARITY) +- up->fifo_bug = true; +- } + if (!(c_cflag & PARODD)) + cval |= UART_LCR_EPAR; + if (c_cflag & CMSPAR) +@@ -2794,8 +2791,7 @@ serial8250_do_set_termios(struct uart_po + up->lcr = cval; /* Save computed LCR */ + + if (up->capabilities & UART_CAP_FIFO && port->fifosize > 1) { +- /* NOTE: If fifo_bug is not set, a user can set RX_trigger. */ +- if ((baud < 2400 && !up->dma) || up->fifo_bug) { ++ if (baud < 2400 && !up->dma) { + up->fcr &= ~UART_FCR_TRIGGER_MASK; + up->fcr |= UART_FCR_TRIGGER_1; + } +@@ -3131,8 +3127,7 @@ static int do_set_rxtrig(struct tty_port + struct uart_8250_port *up = up_to_u8250p(uport); + int rxtrig; + +- if (!(up->capabilities & UART_CAP_FIFO) || uport->fifosize <= 1 || +- up->fifo_bug) ++ if (!(up->capabilities & UART_CAP_FIFO) || uport->fifosize <= 1) + return -EINVAL; + + rxtrig = bytes_to_fcr_rxtrig(up, bytes); +--- a/include/linux/serial_8250.h ++++ b/include/linux/serial_8250.h +@@ -98,7 +98,6 @@ struct uart_8250_port { + struct list_head list; /* ports on this IRQ */ + u32 capabilities; /* port capabilities */ + unsigned short bugs; /* port bugs */ +- bool fifo_bug; /* min RX trigger if enabled */ + unsigned int tx_loadsz; /* transmit fifo load size */ + unsigned char acr; + unsigned char fcr; diff --git a/queue-6.1/ring-buffer-fix-deadloop-issue-on-reading-trace_pipe.patch b/queue-6.1/ring-buffer-fix-deadloop-issue-on-reading-trace_pipe.patch new file mode 100644 index 00000000000..4f388588e28 --- /dev/null +++ b/queue-6.1/ring-buffer-fix-deadloop-issue-on-reading-trace_pipe.patch @@ -0,0 +1,128 @@ +From 7e42907f3a7b4ce3a2d1757f6d78336984daf8f5 Mon Sep 17 00:00:00 2001 +From: Zheng Yejian +Date: Sun, 9 Jul 2023 06:51:44 +0800 +Subject: ring-buffer: Fix deadloop issue on reading trace_pipe + +From: Zheng Yejian + +commit 7e42907f3a7b4ce3a2d1757f6d78336984daf8f5 upstream. + +Soft lockup occurs when reading file 'trace_pipe': + + watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] + [...] + RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 + RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 + RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb + RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 + RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f + R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 + R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 + [...] + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 + DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 + DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 + Call Trace: + __find_next_entry+0x1a8/0x4b0 + ? peek_next_entry+0x250/0x250 + ? down_write+0xa5/0x120 + ? down_write_killable+0x130/0x130 + trace_find_next_entry_inc+0x3b/0x1d0 + tracing_read_pipe+0x423/0xae0 + ? tracing_splice_read_pipe+0xcb0/0xcb0 + vfs_read+0x16b/0x490 + ksys_read+0x105/0x210 + ? __ia32_sys_pwrite64+0x200/0x200 + ? switch_fpu_return+0x108/0x220 + do_syscall_64+0x33/0x40 + entry_SYSCALL_64_after_hwframe+0x61/0xc6 + +Through the vmcore, I found it's because in tracing_read_pipe(), +ring_buffer_empty_cpu() found some buffer is not empty but then it +cannot read anything due to "rb_num_of_entries() == 0" always true, +Then it infinitely loop the procedure due to user buffer not been +filled, see following code path: + + tracing_read_pipe() { + ... ... + waitagain: + tracing_wait_pipe() // 1. find non-empty buffer here + trace_find_next_entry_inc() // 2. loop here try to find an entry + __find_next_entry() + ring_buffer_empty_cpu(); // 3. find non-empty buffer + peek_next_entry() // 4. but peek always return NULL + ring_buffer_peek() + rb_buffer_peek() + rb_get_reader_page() + // 5. because rb_num_of_entries() == 0 always true here + // then return NULL + // 6. user buffer not been filled so goto 'waitgain' + // and eventually leads to an deadloop in kernel!!! + } + +By some analyzing, I found that when resetting ringbuffer, the 'entries' +of its pages are not all cleared (see rb_reset_cpu()). Then when reducing +the ringbuffer, and if some reduced pages exist dirty 'entries' data, they +will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which +cause wrong 'overrun' count and eventually cause the deadloop issue. + +To fix it, we need to clear every pages in rb_reset_cpu(). + +Link: https://lore.kernel.org/linux-trace-kernel/20230708225144.3785600-1-zhengyejian1@huawei.com + +Cc: stable@vger.kernel.org +Fixes: a5fb833172eca ("ring-buffer: Fix uninitialized read_stamp") +Signed-off-by: Zheng Yejian +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ring_buffer.c | 24 +++++++++++++++--------- + 1 file changed, 15 insertions(+), 9 deletions(-) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -5238,28 +5238,34 @@ unsigned long ring_buffer_size(struct tr + } + EXPORT_SYMBOL_GPL(ring_buffer_size); + ++static void rb_clear_buffer_page(struct buffer_page *page) ++{ ++ local_set(&page->write, 0); ++ local_set(&page->entries, 0); ++ rb_init_page(page->page); ++ page->read = 0; ++} ++ + static void + rb_reset_cpu(struct ring_buffer_per_cpu *cpu_buffer) + { ++ struct buffer_page *page; ++ + rb_head_page_deactivate(cpu_buffer); + + cpu_buffer->head_page + = list_entry(cpu_buffer->pages, struct buffer_page, list); +- local_set(&cpu_buffer->head_page->write, 0); +- local_set(&cpu_buffer->head_page->entries, 0); +- local_set(&cpu_buffer->head_page->page->commit, 0); +- +- cpu_buffer->head_page->read = 0; ++ rb_clear_buffer_page(cpu_buffer->head_page); ++ list_for_each_entry(page, cpu_buffer->pages, list) { ++ rb_clear_buffer_page(page); ++ } + + cpu_buffer->tail_page = cpu_buffer->head_page; + cpu_buffer->commit_page = cpu_buffer->head_page; + + INIT_LIST_HEAD(&cpu_buffer->reader_page->list); + INIT_LIST_HEAD(&cpu_buffer->new_pages); +- local_set(&cpu_buffer->reader_page->write, 0); +- local_set(&cpu_buffer->reader_page->entries, 0); +- local_set(&cpu_buffer->reader_page->page->commit, 0); +- cpu_buffer->reader_page->read = 0; ++ rb_clear_buffer_page(cpu_buffer->reader_page); + + local_set(&cpu_buffer->entries_bytes, 0); + local_set(&cpu_buffer->overrun, 0); diff --git a/queue-6.1/s390-decompressor-fix-misaligned-symbol-build-error.patch b/queue-6.1/s390-decompressor-fix-misaligned-symbol-build-error.patch new file mode 100644 index 00000000000..cd4d2667e93 --- /dev/null +++ b/queue-6.1/s390-decompressor-fix-misaligned-symbol-build-error.patch @@ -0,0 +1,53 @@ +From 938f0c35d7d93a822ab9c9728e3205e8e57409d0 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Thu, 22 Jun 2023 14:55:08 +0200 +Subject: s390/decompressor: fix misaligned symbol build error + +From: Heiko Carstens + +commit 938f0c35d7d93a822ab9c9728e3205e8e57409d0 upstream. + +Nathan Chancellor reported a kernel build error on Fedora 39: + +$ clang --version | head -1 +clang version 16.0.5 (Fedora 16.0.5-1.fc39) + +$ s390x-linux-gnu-ld --version | head -1 +GNU ld version 2.40-1.fc39 + +$ make -skj"$(nproc)" ARCH=s390 CC=clang CROSS_COMPILE=s390x-linux-gnu- olddefconfig all +s390x-linux-gnu-ld: arch/s390/boot/startup.o(.text+0x5b4): misaligned symbol `_decompressor_end' (0x35b0f) for relocation R_390_PC32DBL +make[3]: *** [.../arch/s390/boot/Makefile:78: arch/s390/boot/vmlinux] Error 1 + +It turned out that the problem with misaligned symbols on s390 was fixed +with commit 80ddf5ce1c92 ("s390: always build relocatable kernel") for the +kernel image, but did not take into account that the decompressor uses its +own set of CFLAGS, which come without -fPIE. + +Add the -fPIE flag also to the decompresser CFLAGS to fix this. + +Reported-by: Nathan Chancellor +Tested-by: Nathan Chancellor +Reported-by: CKI +Suggested-by: Ulrich Weigand +Link: https://github.com/ClangBuiltLinux/linux/issues/1747 +Link: https://lore.kernel.org/32935.123062114500601371@us-mta-9.us.mimecast.lan/ +Link: https://lore.kernel.org/r/20230622125508.1068457-1-hca@linux.ibm.com +Cc: +Signed-off-by: Heiko Carstens +Signed-off-by: Alexander Gordeev +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/Makefile | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/s390/Makefile ++++ b/arch/s390/Makefile +@@ -27,6 +27,7 @@ KBUILD_CFLAGS_DECOMPRESSOR += -fno-delet + KBUILD_CFLAGS_DECOMPRESSOR += -fno-asynchronous-unwind-tables + KBUILD_CFLAGS_DECOMPRESSOR += -ffreestanding + KBUILD_CFLAGS_DECOMPRESSOR += -fno-stack-protector ++KBUILD_CFLAGS_DECOMPRESSOR += -fPIE + KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning, address-of-packed-member) + KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g) + KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,)) diff --git a/queue-6.1/samples-ftrace-save-required-argument-registers-in-sample-trampolines.patch b/queue-6.1/samples-ftrace-save-required-argument-registers-in-sample-trampolines.patch new file mode 100644 index 00000000000..c8058e9b641 --- /dev/null +++ b/queue-6.1/samples-ftrace-save-required-argument-registers-in-sample-trampolines.patch @@ -0,0 +1,68 @@ +From 8564c315876ab86fcaf8e7f558d6a84cb2ce5590 Mon Sep 17 00:00:00 2001 +From: Florent Revest +Date: Thu, 27 Apr 2023 16:06:59 +0200 +Subject: samples: ftrace: Save required argument registers in sample trampolines + +From: Florent Revest + +commit 8564c315876ab86fcaf8e7f558d6a84cb2ce5590 upstream. + +The ftrace-direct-too sample traces the handle_mm_fault function whose +signature changed since the introduction of the sample. Since: +commit bce617edecad ("mm: do page fault accounting in handle_mm_fault") +handle_mm_fault now has 4 arguments. Therefore, the sample trampoline +should save 4 argument registers. + +s390 saves all argument registers already so it does not need a change +but x86_64 needs an extra push and pop. + +This also evolves the signature of the tracing function to make it +mirror the signature of the traced function. + +Link: https://lkml.kernel.org/r/20230427140700.625241-2-revest@chromium.org + +Cc: stable@vger.kernel.org +Fixes: bce617edecad ("mm: do page fault accounting in handle_mm_fault") +Reviewed-by: Steven Rostedt (Google) +Reviewed-by: Mark Rutland +Acked-by: Catalin Marinas +Signed-off-by: Florent Revest +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + samples/ftrace/ftrace-direct-too.c | 14 ++++++++------ + 1 file changed, 8 insertions(+), 6 deletions(-) + +--- a/samples/ftrace/ftrace-direct-too.c ++++ b/samples/ftrace/ftrace-direct-too.c +@@ -5,14 +5,14 @@ + #include + #include + +-extern void my_direct_func(struct vm_area_struct *vma, +- unsigned long address, unsigned int flags); ++extern void my_direct_func(struct vm_area_struct *vma, unsigned long address, ++ unsigned int flags, struct pt_regs *regs); + +-void my_direct_func(struct vm_area_struct *vma, +- unsigned long address, unsigned int flags) ++void my_direct_func(struct vm_area_struct *vma, unsigned long address, ++ unsigned int flags, struct pt_regs *regs) + { +- trace_printk("handle mm fault vma=%p address=%lx flags=%x\n", +- vma, address, flags); ++ trace_printk("handle mm fault vma=%p address=%lx flags=%x regs=%p\n", ++ vma, address, flags, regs); + } + + extern void my_tramp(void *); +@@ -32,7 +32,9 @@ asm ( + " pushq %rdi\n" + " pushq %rsi\n" + " pushq %rdx\n" ++" pushq %rcx\n" + " call my_direct_func\n" ++" popq %rcx\n" + " popq %rdx\n" + " popq %rsi\n" + " popq %rdi\n" diff --git a/queue-6.1/series b/queue-6.1/series index 3fbaafe95af..4a375f4bd43 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -159,3 +159,34 @@ tty-serial-samsung_tty-fix-a-memory-leak-in-s3c24xx_serial_getclk-in-case-of-err tty-serial-samsung_tty-fix-a-memory-leak-in-s3c24xx_serial_getclk-when-iterating-clk.patch tty-serial-imx-fix-rs485-rx-after-tx.patch firmware-stratix10-svc-fix-a-potential-resource-leak-in-svc_create_memory_pool.patch +libceph-harden-msgr2.1-frame-segment-length-checks.patch +ceph-add-a-dedicated-private-data-for-netfs-rreq.patch +ceph-fix-blindly-expanding-the-readahead-windows.patch +ceph-don-t-let-check_caps-skip-sending-responses-for-revoke-msgs.patch +xhci-fix-resume-issue-of-some-zhaoxin-hosts.patch +xhci-fix-trb-prefetch-issue-of-zhaoxin-hosts.patch +xhci-show-zhaoxin-xhci-root-hub-speed-correctly.patch +meson-saradc-fix-clock-divider-mask-length.patch +opp-fix-use-after-free-in-lazy_opp_tables-after-probe-deferral.patch +soundwire-qcom-fix-storing-port-config-out-of-bounds.patch +revert-8250-add-support-for-asix-devices-with-a-fifo-bug.patch +bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch +s390-decompressor-fix-misaligned-symbol-build-error.patch +dm-verity-loadpin-add-null-pointer-check-for-bdev-parameter.patch +tracing-histograms-add-histograms-to-hist_vars-if-they-have-referenced-variables.patch +tracing-fix-memory-leak-of-iter-temp-when-reading-trace_pipe.patch +nvme-don-t-reject-probe-due-to-duplicate-ids-for-single-ported-pcie-devices.patch +samples-ftrace-save-required-argument-registers-in-sample-trampolines.patch +perf-risc-v-remove-perf_hes_stopped-flag-checking-in-riscv_pmu_start.patch +regmap-irq-fix-out-of-bounds-access-when-allocating-config-buffers.patch +net-ena-fix-shift-out-of-bounds-in-exponential-backoff.patch +ring-buffer-fix-deadloop-issue-on-reading-trace_pipe.patch +ftrace-fix-possible-warning-on-checking-all-pages-used-in-ftrace_process_locs.patch +drm-amd-pm-share-the-code-around-smu13-pcie-parameters-update.patch +drm-amd-pm-conditionally-disable-pcie-lane-speed-switching-for-smu13.patch +cifs-if-deferred-close-is-disabled-then-close-files-immediately.patch +xtensa-iss-fix-call-to-split_if_spec.patch +perf-x86-fix-lockdep-warning-in-for_each_sibling_event-on-spr.patch +pm-qos-restore-support-for-default-value-on-frequency-qos.patch +pwm-meson-modify-and-simplify-calculation-in-meson_pwm_get_state.patch +pwm-meson-fix-handling-of-period-duty-if-greater-than-uint_max.patch diff --git a/queue-6.1/soundwire-qcom-fix-storing-port-config-out-of-bounds.patch b/queue-6.1/soundwire-qcom-fix-storing-port-config-out-of-bounds.patch new file mode 100644 index 00000000000..dfa2c620e42 --- /dev/null +++ b/queue-6.1/soundwire-qcom-fix-storing-port-config-out-of-bounds.patch @@ -0,0 +1,43 @@ +From 490937d479abe5f6584e69b96df066bc87be92e9 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Thu, 1 Jun 2023 12:25:25 +0200 +Subject: soundwire: qcom: fix storing port config out-of-bounds + +From: Krzysztof Kozlowski + +commit 490937d479abe5f6584e69b96df066bc87be92e9 upstream. + +The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14), +however we index it starting from 1, not 0, to match real port numbers. +This can lead to writing port config past 'pconfig' bounds and +overwriting next member of 'qcom_swrm_ctrl' struct. Reported also by +smatch: + + drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14 + +Fixes: 9916c02ccd74 ("soundwire: qcom: cleanup internal port config indexing") +Cc: +Reported-by: kernel test robot +Reported-by: Dan Carpenter +Link: https://lore.kernel.org/r/202305201301.sCJ8UDKV-lkp@intel.com/ +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Konrad Dybcio +Link: https://lore.kernel.org/r/20230601102525.609627-1-krzysztof.kozlowski@linaro.org +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/soundwire/qcom.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/soundwire/qcom.c ++++ b/drivers/soundwire/qcom.c +@@ -167,7 +167,8 @@ struct qcom_swrm_ctrl { + u32 intr_mask; + u8 rcmd_id; + u8 wcmd_id; +- struct qcom_swrm_port_config pconfig[QCOM_SDW_MAX_PORTS]; ++ /* Port numbers are 1 - 14 */ ++ struct qcom_swrm_port_config pconfig[QCOM_SDW_MAX_PORTS + 1]; + struct sdw_stream_runtime *sruntime[SWRM_MAX_DAIS]; + enum sdw_slave_status status[SDW_MAX_DEVICES + 1]; + int (*reg_read)(struct qcom_swrm_ctrl *ctrl, int reg, u32 *val); diff --git a/queue-6.1/tracing-fix-memory-leak-of-iter-temp-when-reading-trace_pipe.patch b/queue-6.1/tracing-fix-memory-leak-of-iter-temp-when-reading-trace_pipe.patch new file mode 100644 index 00000000000..3ed06057e71 --- /dev/null +++ b/queue-6.1/tracing-fix-memory-leak-of-iter-temp-when-reading-trace_pipe.patch @@ -0,0 +1,52 @@ +From d5a821896360cc8b93a15bd888fabc858c038dc0 Mon Sep 17 00:00:00 2001 +From: Zheng Yejian +Date: Thu, 13 Jul 2023 22:14:35 +0800 +Subject: tracing: Fix memory leak of iter->temp when reading trace_pipe + +From: Zheng Yejian + +commit d5a821896360cc8b93a15bd888fabc858c038dc0 upstream. + +kmemleak reports: + unreferenced object 0xffff88814d14e200 (size 256): + comm "cat", pid 336, jiffies 4294871818 (age 779.490s) + hex dump (first 32 bytes): + 04 00 01 03 00 00 00 00 08 00 00 00 00 00 00 00 ................ + 0c d8 c8 9b ff ff ff ff 04 5a ca 9b ff ff ff ff .........Z...... + backtrace: + [] __kmalloc+0x4f/0x140 + [] trace_find_next_entry+0xbb/0x1d0 + [] trace_print_lat_context+0xaf/0x4e0 + [] print_trace_line+0x3e0/0x950 + [] tracing_read_pipe+0x2d9/0x5a0 + [] vfs_read+0x143/0x520 + [] ksys_read+0xbd/0x160 + [] do_syscall_64+0x3f/0x90 + [] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 + +when reading file 'trace_pipe', 'iter->temp' is allocated or relocated +in trace_find_next_entry() but not freed before 'trace_pipe' is closed. + +To fix it, free 'iter->temp' in tracing_release_pipe(). + +Link: https://lore.kernel.org/linux-trace-kernel/20230713141435.1133021-1-zhengyejian1@huawei.com + +Cc: stable@vger.kernel.org +Fixes: ff895103a84ab ("tracing: Save off entry when peeking at next entry") +Signed-off-by: Zheng Yejian +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -6679,6 +6679,7 @@ static int tracing_release_pipe(struct i + + free_cpumask_var(iter->started); + kfree(iter->fmt); ++ kfree(iter->temp); + mutex_destroy(&iter->mutex); + kfree(iter); + diff --git a/queue-6.1/tracing-histograms-add-histograms-to-hist_vars-if-they-have-referenced-variables.patch b/queue-6.1/tracing-histograms-add-histograms-to-hist_vars-if-they-have-referenced-variables.patch new file mode 100644 index 00000000000..9690b7dc7dc --- /dev/null +++ b/queue-6.1/tracing-histograms-add-histograms-to-hist_vars-if-they-have-referenced-variables.patch @@ -0,0 +1,127 @@ +From 6018b585e8c6fa7d85d4b38d9ce49a5b67be7078 Mon Sep 17 00:00:00 2001 +From: Mohamed Khalfella +Date: Wed, 12 Jul 2023 22:30:21 +0000 +Subject: tracing/histograms: Add histograms to hist_vars if they have referenced variables + +From: Mohamed Khalfella + +commit 6018b585e8c6fa7d85d4b38d9ce49a5b67be7078 upstream. + +Hist triggers can have referenced variables without having direct +variables fields. This can be the case if referenced variables are added +for trigger actions. In this case the newly added references will not +have field variables. Not taking such referenced variables into +consideration can result in a bug where it would be possible to remove +hist trigger with variables being refenced. This will result in a bug +that is easily reproducable like so + +$ cd /sys/kernel/tracing +$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events +$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger +$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger +$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger + +[ 100.263533] ================================================================== +[ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180 +[ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439 +[ 100.266320] +[ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4 +[ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 +[ 100.268561] Call Trace: +[ 100.268902] +[ 100.269189] dump_stack_lvl+0x4c/0x70 +[ 100.269680] print_report+0xc5/0x600 +[ 100.270165] ? resolve_var_refs+0xc7/0x180 +[ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0 +[ 100.271389] ? resolve_var_refs+0xc7/0x180 +[ 100.271913] kasan_report+0xbd/0x100 +[ 100.272380] ? resolve_var_refs+0xc7/0x180 +[ 100.272920] __asan_load8+0x71/0xa0 +[ 100.273377] resolve_var_refs+0xc7/0x180 +[ 100.273888] event_hist_trigger+0x749/0x860 +[ 100.274505] ? kasan_save_stack+0x2a/0x50 +[ 100.275024] ? kasan_set_track+0x29/0x40 +[ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10 +[ 100.276138] ? ksys_write+0xd1/0x170 +[ 100.276607] ? do_syscall_64+0x3c/0x90 +[ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8 +[ 100.277771] ? destroy_hist_data+0x446/0x470 +[ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860 +[ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10 +[ 100.279627] ? __kasan_check_write+0x18/0x20 +[ 100.280177] ? mutex_unlock+0x85/0xd0 +[ 100.280660] ? __pfx_mutex_unlock+0x10/0x10 +[ 100.281200] ? kfree+0x7b/0x120 +[ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0 +[ 100.282197] ? event_trigger_write+0xac/0x100 +[ 100.282764] ? __kasan_slab_free+0x16/0x20 +[ 100.283293] ? __kmem_cache_free+0x153/0x2f0 +[ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250 +[ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10 +[ 100.285221] ? event_trigger_write+0xbc/0x100 +[ 100.285781] ? __kasan_check_read+0x15/0x20 +[ 100.286321] ? __bitmap_weight+0x66/0xa0 +[ 100.286833] ? _find_next_bit+0x46/0xe0 +[ 100.287334] ? task_mm_cid_work+0x37f/0x450 +[ 100.287872] event_triggers_call+0x84/0x150 +[ 100.288408] trace_event_buffer_commit+0x339/0x430 +[ 100.289073] ? ring_buffer_event_data+0x3f/0x60 +[ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0 +[ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0 +[ 100.298653] syscall_enter_from_user_mode+0x32/0x40 +[ 100.301808] do_syscall_64+0x1a/0x90 +[ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 +[ 100.307775] RIP: 0033:0x7f686c75c1cb +[ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48 +[ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021 +[ 100.321200] RAX: ffffffffffffffda RBX: 000055f566469ea0 RCX: 00007f686c75c1cb +[ 100.324631] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 000000000000000a +[ 100.328104] RBP: 00007ffc60137ac0 R08: 00007f686c818460 R09: 000000000000000a +[ 100.331509] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 +[ 100.334992] R13: 0000000000000007 R14: 000000000000000a R15: 0000000000000007 +[ 100.338381] + +We hit the bug because when second hist trigger has was created +has_hist_vars() returned false because hist trigger did not have +variables. As a result of that save_hist_vars() was not called to add +the trigger to trace_array->hist_vars. Later on when we attempted to +remove the first histogram find_any_var_ref() failed to detect it is +being used because it did not find the second trigger in hist_vars list. + +With this change we wait until trigger actions are created so we can take +into consideration if hist trigger has variable references. Also, now we +check the return value of save_hist_vars() and fail trigger creation if +save_hist_vars() fails. + +Link: https://lore.kernel.org/linux-trace-kernel/20230712223021.636335-1-mkhalfella@purestorage.com + +Cc: stable@vger.kernel.org +Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers") +Signed-off-by: Mohamed Khalfella +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace_events_hist.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/kernel/trace/trace_events_hist.c ++++ b/kernel/trace/trace_events_hist.c +@@ -6555,13 +6555,15 @@ static int event_hist_trigger_parse(stru + if (get_named_trigger_data(trigger_data)) + goto enable; + +- if (has_hist_vars(hist_data)) +- save_hist_vars(hist_data); +- + ret = create_actions(hist_data); + if (ret) + goto out_unreg; + ++ if (has_hist_vars(hist_data) || hist_data->n_var_refs) { ++ if (save_hist_vars(hist_data)) ++ goto out_unreg; ++ } ++ + ret = tracing_map_init(hist_data->map); + if (ret) + goto out_unreg; diff --git a/queue-6.1/xhci-fix-resume-issue-of-some-zhaoxin-hosts.patch b/queue-6.1/xhci-fix-resume-issue-of-some-zhaoxin-hosts.patch new file mode 100644 index 00000000000..f6a6163d91a --- /dev/null +++ b/queue-6.1/xhci-fix-resume-issue-of-some-zhaoxin-hosts.patch @@ -0,0 +1,38 @@ +From f927728186f0de1167262d6a632f9f7e96433d1a Mon Sep 17 00:00:00 2001 +From: Weitao Wang +Date: Fri, 2 Jun 2023 17:40:06 +0300 +Subject: xhci: Fix resume issue of some ZHAOXIN hosts + +From: Weitao Wang + +commit f927728186f0de1167262d6a632f9f7e96433d1a upstream. + +On ZHAOXIN ZX-100 project, xHCI can't work normally after resume +from system Sx state. To fix this issue, when resume from system +Sx state, reinitialize xHCI instead of restore. +So, Add XHCI_RESET_ON_RESUME quirk for ZX-100 to fix issue of +resuming from system Sx state. + +Cc: stable@vger.kernel.org +Signed-off-by: Weitao Wang +Signed-off-by: Mathias Nyman +Message-ID: <20230602144009.1225632-9-mathias.nyman@linux.intel.com> +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -335,6 +335,11 @@ static void xhci_pci_quirks(struct devic + pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_4)) + xhci->quirks |= XHCI_NO_SOFT_RETRY; + ++ if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) { ++ if (pdev->device == 0x9202) ++ xhci->quirks |= XHCI_RESET_ON_RESUME; ++ } ++ + /* xHC spec requires PCI devices to support D3hot and D3cold */ + if (xhci->hci_version >= 0x120) + xhci->quirks |= XHCI_DEFAULT_PM_RUNTIME_ALLOW; diff --git a/queue-6.1/xhci-fix-trb-prefetch-issue-of-zhaoxin-hosts.patch b/queue-6.1/xhci-fix-trb-prefetch-issue-of-zhaoxin-hosts.patch new file mode 100644 index 00000000000..75b18335c7c --- /dev/null +++ b/queue-6.1/xhci-fix-trb-prefetch-issue-of-zhaoxin-hosts.patch @@ -0,0 +1,71 @@ +From 2a865a652299f5666f3b785cbe758c5f57453036 Mon Sep 17 00:00:00 2001 +From: Weitao Wang +Date: Fri, 2 Jun 2023 17:40:07 +0300 +Subject: xhci: Fix TRB prefetch issue of ZHAOXIN hosts + +From: Weitao Wang + +commit 2a865a652299f5666f3b785cbe758c5f57453036 upstream. + +On some ZHAOXIN hosts, xHCI will prefetch TRB for performance +improvement. However this TRB prefetch mechanism may cross page boundary, +which may access memory not allocated by xHCI driver. In order to fix +this issue, two pages was allocated for a segment and only the first +page will be used. And add a quirk XHCI_ZHAOXIN_TRB_FETCH for this issue. + +Cc: stable@vger.kernel.org +Signed-off-by: Weitao Wang +Signed-off-by: Mathias Nyman +Message-ID: <20230602144009.1225632-10-mathias.nyman@linux.intel.com> +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-mem.c | 8 ++++++-- + drivers/usb/host/xhci-pci.c | 7 ++++++- + drivers/usb/host/xhci.h | 1 + + 3 files changed, 13 insertions(+), 3 deletions(-) + +--- a/drivers/usb/host/xhci-mem.c ++++ b/drivers/usb/host/xhci-mem.c +@@ -2439,8 +2439,12 @@ int xhci_mem_init(struct xhci_hcd *xhci, + * and our use of dma addresses in the trb_address_map radix tree needs + * TRB_SEGMENT_SIZE alignment, so we pick the greater alignment need. + */ +- xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, +- TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size); ++ if (xhci->quirks & XHCI_ZHAOXIN_TRB_FETCH) ++ xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, ++ TRB_SEGMENT_SIZE * 2, TRB_SEGMENT_SIZE * 2, xhci->page_size * 2); ++ else ++ xhci->segment_pool = dma_pool_create("xHCI ring segments", dev, ++ TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size); + + /* See Table 46 and Note on Figure 55 */ + xhci->device_pool = dma_pool_create("xHCI input/output contexts", dev, +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -336,8 +336,13 @@ static void xhci_pci_quirks(struct devic + xhci->quirks |= XHCI_NO_SOFT_RETRY; + + if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) { +- if (pdev->device == 0x9202) ++ if (pdev->device == 0x9202) { + xhci->quirks |= XHCI_RESET_ON_RESUME; ++ xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH; ++ } ++ ++ if (pdev->device == 0x9203) ++ xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH; + } + + /* xHC spec requires PCI devices to support D3hot and D3cold */ +--- a/drivers/usb/host/xhci.h ++++ b/drivers/usb/host/xhci.h +@@ -1899,6 +1899,7 @@ struct xhci_hcd { + #define XHCI_EP_CTX_BROKEN_DCS BIT_ULL(42) + #define XHCI_SUSPEND_RESUME_CLKS BIT_ULL(43) + #define XHCI_RESET_TO_DEFAULT BIT_ULL(44) ++#define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45) + + unsigned int num_active_eps; + unsigned int limit_active_eps; diff --git a/queue-6.1/xhci-show-zhaoxin-xhci-root-hub-speed-correctly.patch b/queue-6.1/xhci-show-zhaoxin-xhci-root-hub-speed-correctly.patch new file mode 100644 index 00000000000..c5df48c15d7 --- /dev/null +++ b/queue-6.1/xhci-show-zhaoxin-xhci-root-hub-speed-correctly.patch @@ -0,0 +1,127 @@ +From d9b0328d0b8b8298dfdc97cd8e0e2371d4bcc97b Mon Sep 17 00:00:00 2001 +From: Weitao Wang +Date: Fri, 2 Jun 2023 17:40:08 +0300 +Subject: xhci: Show ZHAOXIN xHCI root hub speed correctly + +From: Weitao Wang + +commit d9b0328d0b8b8298dfdc97cd8e0e2371d4bcc97b upstream. + +Some ZHAOXIN xHCI controllers follow usb3.1 spec, but only support +gen1 speed 5Gbps. While in Linux kernel, if xHCI suspport usb3.1, +root hub speed will show on 10Gbps. +To fix this issue of ZHAOXIN xHCI platforms, read usb speed ID +supported by xHCI to determine root hub speed. And add a quirk +XHCI_ZHAOXIN_HOST for this issue. + +[fix warning about uninitialized symbol -Mathias] + +Suggested-by: Mathias Nyman +Cc: stable@vger.kernel.org +Signed-off-by: Weitao Wang +Signed-off-by: Mathias Nyman +Message-ID: <20230602144009.1225632-11-mathias.nyman@linux.intel.com> +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-mem.c | 31 ++++++++++++++++++++++++------- + drivers/usb/host/xhci-pci.c | 2 ++ + drivers/usb/host/xhci.h | 1 + + 3 files changed, 27 insertions(+), 7 deletions(-) + +--- a/drivers/usb/host/xhci-mem.c ++++ b/drivers/usb/host/xhci-mem.c +@@ -2116,7 +2116,7 @@ static void xhci_add_in_port(struct xhci + { + u32 temp, port_offset, port_count; + int i; +- u8 major_revision, minor_revision; ++ u8 major_revision, minor_revision, tmp_minor_revision; + struct xhci_hub *rhub; + struct device *dev = xhci_to_hcd(xhci)->self.sysdev; + struct xhci_port_cap *port_cap; +@@ -2136,6 +2136,15 @@ static void xhci_add_in_port(struct xhci + */ + if (minor_revision > 0x00 && minor_revision < 0x10) + minor_revision <<= 4; ++ /* ++ * Some zhaoxin's xHCI controller that follow usb3.1 spec ++ * but only support Gen1. ++ */ ++ if (xhci->quirks & XHCI_ZHAOXIN_HOST) { ++ tmp_minor_revision = minor_revision; ++ minor_revision = 0; ++ } ++ + } else if (major_revision <= 0x02) { + rhub = &xhci->usb2_rhub; + } else { +@@ -2145,10 +2154,6 @@ static void xhci_add_in_port(struct xhci + /* Ignoring port protocol we can't understand. FIXME */ + return; + } +- rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp); +- +- if (rhub->min_rev < minor_revision) +- rhub->min_rev = minor_revision; + + /* Port offset and count in the third dword, see section 7.2 */ + temp = readl(addr + 2); +@@ -2167,8 +2172,6 @@ static void xhci_add_in_port(struct xhci + if (xhci->num_port_caps > max_caps) + return; + +- port_cap->maj_rev = major_revision; +- port_cap->min_rev = minor_revision; + port_cap->psi_count = XHCI_EXT_PORT_PSIC(temp); + + if (port_cap->psi_count) { +@@ -2189,6 +2192,11 @@ static void xhci_add_in_port(struct xhci + XHCI_EXT_PORT_PSIV(port_cap->psi[i - 1]))) + port_cap->psi_uid_count++; + ++ if (xhci->quirks & XHCI_ZHAOXIN_HOST && ++ major_revision == 0x03 && ++ XHCI_EXT_PORT_PSIV(port_cap->psi[i]) >= 5) ++ minor_revision = tmp_minor_revision; ++ + xhci_dbg(xhci, "PSIV:%d PSIE:%d PLT:%d PFD:%d LP:%d PSIM:%d\n", + XHCI_EXT_PORT_PSIV(port_cap->psi[i]), + XHCI_EXT_PORT_PSIE(port_cap->psi[i]), +@@ -2198,6 +2206,15 @@ static void xhci_add_in_port(struct xhci + XHCI_EXT_PORT_PSIM(port_cap->psi[i])); + } + } ++ ++ rhub->maj_rev = major_revision; ++ ++ if (rhub->min_rev < minor_revision) ++ rhub->min_rev = minor_revision; ++ ++ port_cap->maj_rev = major_revision; ++ port_cap->min_rev = minor_revision; ++ + /* cache usb2 port capabilities */ + if (major_revision < 0x03 && xhci->num_ext_caps < max_caps) + xhci->ext_caps[xhci->num_ext_caps++] = temp; +--- a/drivers/usb/host/xhci-pci.c ++++ b/drivers/usb/host/xhci-pci.c +@@ -336,6 +336,8 @@ static void xhci_pci_quirks(struct devic + xhci->quirks |= XHCI_NO_SOFT_RETRY; + + if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) { ++ xhci->quirks |= XHCI_ZHAOXIN_HOST; ++ + if (pdev->device == 0x9202) { + xhci->quirks |= XHCI_RESET_ON_RESUME; + xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH; +--- a/drivers/usb/host/xhci.h ++++ b/drivers/usb/host/xhci.h +@@ -1900,6 +1900,7 @@ struct xhci_hcd { + #define XHCI_SUSPEND_RESUME_CLKS BIT_ULL(43) + #define XHCI_RESET_TO_DEFAULT BIT_ULL(44) + #define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45) ++#define XHCI_ZHAOXIN_HOST BIT_ULL(46) + + unsigned int num_active_eps; + unsigned int limit_active_eps; diff --git a/queue-6.1/xtensa-iss-fix-call-to-split_if_spec.patch b/queue-6.1/xtensa-iss-fix-call-to-split_if_spec.patch new file mode 100644 index 00000000000..d0f677c64b8 --- /dev/null +++ b/queue-6.1/xtensa-iss-fix-call-to-split_if_spec.patch @@ -0,0 +1,34 @@ +From bc8d5916541fa19ca5bc598eb51a5f78eb891a36 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Mon, 3 Jul 2023 11:01:42 -0700 +Subject: xtensa: ISS: fix call to split_if_spec + +From: Max Filippov + +commit bc8d5916541fa19ca5bc598eb51a5f78eb891a36 upstream. + +split_if_spec expects a NULL-pointer as an end marker for the argument +list, but tuntap_probe never supplied that terminating NULL. As a result +incorrectly formatted interface specification string may cause a crash +because of the random memory access. Fix that by adding NULL terminator +to the split_if_spec argument list. + +Cc: stable@vger.kernel.org +Fixes: 7282bee78798 ("[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 8") +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/platforms/iss/network.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/xtensa/platforms/iss/network.c ++++ b/arch/xtensa/platforms/iss/network.c +@@ -237,7 +237,7 @@ static int tuntap_probe(struct iss_net_p + + init += sizeof(TRANSPORT_TUNTAP_NAME) - 1; + if (*init == ',') { +- rem = split_if_spec(init + 1, &mac_str, &dev_name); ++ rem = split_if_spec(init + 1, &mac_str, &dev_name, NULL); + if (rem != NULL) { + pr_err("%s: extra garbage on specification : '%s'\n", + dev->name, rem); -- 2.47.3