From: Greg Kroah-Hartman Date: Sat, 16 Sep 2023 12:30:24 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v5.10.195~37 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8bdd47d30490798a2df2305b156fd8cfe3380d59;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: btrfs-compare-the-correct-fsid-metadata_uuid-in-btrfs_validate_super.patch btrfs-set-page-extent-mapped-after-read_folio-in-relocate_one_page.patch btrfs-use-the-correct-superblock-to-compare-fsid-in-btrfs_validate_super.patch btrfs-zoned-re-enable-metadata-over-commit-for-zoned-mode.patch drm-amd-display-always-switch-off-odm-before-committing-more-streams.patch drm-amd-display-enable-cursor-degamma-for-dcn3-drm-legacy-gamma.patch drm-amd-display-prevent-potential-division-by-zero-errors.patch drm-amd-display-remove-wait-while-locked.patch drm-amdgpu-register-a-dirty-framebuffer-callback-for-fbcon.patch drm-mxsfb-disable-overlay-plane-in-mxsfb_plane_overlay_atomic_disable.patch kvm-nsvm-check-instead-of-asserting-on-nested-tsc-scaling-support.patch kvm-nsvm-load-l1-s-tsc-multiplier-based-on-l1-state-not-l2-state.patch kvm-svm-don-t-inject-ud-if-kvm-attempts-to-skip-sev-guest-insn.patch kvm-svm-get-source-vcpus-from-source-vm-for-sev-es-intrahost-migration.patch kvm-svm-set-target-pcpu-during-irte-update-if-target-vcpu-is-running.patch kvm-svm-skip-vmsa-init-in-sev_es_init_vmcb-if-pointer-is-null.patch kvm-svm-take-and-hold-ir_list_lock-when-updating-vcpu-s-physical-id-entry.patch mips-fix-config_cpu_daddi_workarounds-modules_install-regression.patch mtd-rawnand-brcmnand-fix-crash-during-the-panic_write.patch mtd-rawnand-brcmnand-fix-ecc-level-field-setting-for-v7.2-controller.patch mtd-rawnand-brcmnand-fix-potential-false-time-out-warning.patch mtd-rawnand-brcmnand-fix-potential-out-of-bounds-access-in-oob-write.patch mtd-spi-nor-correct-flags-for-winbond-w25q128.patch perf-build-update-build-rule-for-generated-files.patch perf-hists-browser-fix-hierarchy-mode-header.patch perf-hists-browser-fix-the-number-of-entries-for-e-key.patch perf-test-shell-stat_bpf_counters-fix-test-on-intel.patch perf-tools-handle-old-data-in-perf_record_attr.patch --- diff --git a/queue-6.1/btrfs-compare-the-correct-fsid-metadata_uuid-in-btrfs_validate_super.patch b/queue-6.1/btrfs-compare-the-correct-fsid-metadata_uuid-in-btrfs_validate_super.patch new file mode 100644 index 00000000000..6a2891cbd7b --- /dev/null +++ b/queue-6.1/btrfs-compare-the-correct-fsid-metadata_uuid-in-btrfs_validate_super.patch @@ -0,0 +1,61 @@ +From 6bfe3959b0e7a526f5c64747801a8613f002f05a Mon Sep 17 00:00:00 2001 +From: Anand Jain +Date: Mon, 31 Jul 2023 19:16:35 +0800 +Subject: btrfs: compare the correct fsid/metadata_uuid in btrfs_validate_super + +From: Anand Jain + +commit 6bfe3959b0e7a526f5c64747801a8613f002f05a upstream. + +The function btrfs_validate_super() should verify the metadata_uuid in +the provided superblock argument. Because, all its callers expect it to +do that. + +Such as in the following stacks: + + write_all_supers() + sb = fs_info->super_for_commit; + btrfs_validate_write_super(.., sb) + btrfs_validate_super(.., sb, ..) + + scrub_one_super() + btrfs_validate_super(.., sb, ..) + +And + check_dev_super() + btrfs_validate_super(.., sb, ..) + +However, it currently verifies the fs_info::super_copy::metadata_uuid +instead. Fix this using the correct metadata_uuid in the superblock +argument. + +CC: stable@vger.kernel.org # 5.4+ +Reviewed-by: Johannes Thumshirn +Tested-by: Guilherme G. Piccoli +Signed-off-by: Anand Jain +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -2728,13 +2728,11 @@ int btrfs_validate_super(struct btrfs_fs + ret = -EINVAL; + } + +- if (btrfs_fs_incompat(fs_info, METADATA_UUID) && +- memcmp(fs_info->fs_devices->metadata_uuid, +- fs_info->super_copy->metadata_uuid, BTRFS_FSID_SIZE)) { ++ if (memcmp(fs_info->fs_devices->metadata_uuid, btrfs_sb_fsid_ptr(sb), ++ BTRFS_FSID_SIZE) != 0) { + btrfs_err(fs_info, + "superblock metadata_uuid doesn't match metadata uuid of fs_devices: %pU != %pU", +- fs_info->super_copy->metadata_uuid, +- fs_info->fs_devices->metadata_uuid); ++ btrfs_sb_fsid_ptr(sb), fs_info->fs_devices->metadata_uuid); + ret = -EINVAL; + } + diff --git a/queue-6.1/btrfs-set-page-extent-mapped-after-read_folio-in-relocate_one_page.patch b/queue-6.1/btrfs-set-page-extent-mapped-after-read_folio-in-relocate_one_page.patch new file mode 100644 index 00000000000..ee10faf40ef --- /dev/null +++ b/queue-6.1/btrfs-set-page-extent-mapped-after-read_folio-in-relocate_one_page.patch @@ -0,0 +1,100 @@ +From e7f1326cc24e22b38afc3acd328480a1183f9e79 Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Mon, 31 Jul 2023 11:13:00 -0400 +Subject: btrfs: set page extent mapped after read_folio in relocate_one_page + +From: Josef Bacik + +commit e7f1326cc24e22b38afc3acd328480a1183f9e79 upstream. + +One of the CI runs triggered the following panic + + assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 + ------------[ cut here ]------------ + kernel BUG at fs/btrfs/subpage.c:229! + Internal error: Oops - BUG: 00000000f2000800 [#1] SMP + CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 + pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) + pc : btrfs_subpage_assert+0xbc/0xf0 + lr : btrfs_subpage_assert+0xbc/0xf0 + sp : ffff800093213720 + x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000 + x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff + x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880 + x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff + x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028 + x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000 + x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c + x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8 + x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000 + x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f + Call trace: + btrfs_subpage_assert+0xbc/0xf0 + btrfs_subpage_set_dirty+0x38/0xa0 + btrfs_page_set_dirty+0x58/0x88 + relocate_one_page+0x204/0x5f0 + relocate_file_extent_cluster+0x11c/0x180 + relocate_data_extent+0xd0/0xf8 + relocate_block_group+0x3d0/0x4e8 + btrfs_relocate_block_group+0x2d8/0x490 + btrfs_relocate_chunk+0x54/0x1a8 + btrfs_balance+0x7f4/0x1150 + btrfs_ioctl+0x10f0/0x20b8 + __arm64_sys_ioctl+0x120/0x11d8 + invoke_syscall.constprop.0+0x80/0xd8 + do_el0_svc+0x6c/0x158 + el0_svc+0x50/0x1b0 + el0t_64_sync_handler+0x120/0x130 + el0t_64_sync+0x194/0x198 + Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000) + +This is the same problem outlined in 17b17fcd6d44 ("btrfs: +set_page_extent_mapped after read_folio in btrfs_cont_expand") , and the +fix is the same. I originally looked for the same pattern elsewhere in +our code, but mistakenly skipped over this code because I saw the page +cache readahead before we set_page_extent_mapped, not realizing that +this was only in the !page case, that we can still end up with a +!uptodate page and then do the btrfs_read_folio further down. + +The fix here is the same as the above mentioned patch, move the +set_page_extent_mapped call to after the btrfs_read_folio() block to +make sure that we have the subpage blocksize stuff setup properly before +using the page. + +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Filipe Manana +Signed-off-by: Josef Bacik +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/relocation.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -2985,9 +2985,6 @@ static int relocate_one_page(struct inod + if (!page) + return -ENOMEM; + } +- ret = set_page_extent_mapped(page); +- if (ret < 0) +- goto release_page; + + if (PageReadahead(page)) + page_cache_async_readahead(inode->i_mapping, ra, NULL, +@@ -3003,6 +3000,15 @@ static int relocate_one_page(struct inod + } + } + ++ /* ++ * We could have lost page private when we dropped the lock to read the ++ * page above, make sure we set_page_extent_mapped here so we have any ++ * of the subpage blocksize stuff we need in place. ++ */ ++ ret = set_page_extent_mapped(page); ++ if (ret < 0) ++ goto release_page; ++ + page_start = page_offset(page); + page_end = page_start + PAGE_SIZE - 1; + diff --git a/queue-6.1/btrfs-use-the-correct-superblock-to-compare-fsid-in-btrfs_validate_super.patch b/queue-6.1/btrfs-use-the-correct-superblock-to-compare-fsid-in-btrfs_validate_super.patch new file mode 100644 index 00000000000..a8ae8540022 --- /dev/null +++ b/queue-6.1/btrfs-use-the-correct-superblock-to-compare-fsid-in-btrfs_validate_super.patch @@ -0,0 +1,57 @@ +From d167aa76dc0683828588c25767da07fb549e4f48 Mon Sep 17 00:00:00 2001 +From: Anand Jain +Date: Mon, 31 Jul 2023 19:16:34 +0800 +Subject: btrfs: use the correct superblock to compare fsid in btrfs_validate_super + +From: Anand Jain + +commit d167aa76dc0683828588c25767da07fb549e4f48 upstream. + +The function btrfs_validate_super() should verify the fsid in the provided +superblock argument. Because, all its callers expect it to do that. + +Such as in the following stack: + + write_all_supers() + sb = fs_info->super_for_commit; + btrfs_validate_write_super(.., sb) + btrfs_validate_super(.., sb, ..) + + scrub_one_super() + btrfs_validate_super(.., sb, ..) + +And + check_dev_super() + btrfs_validate_super(.., sb, ..) + +However, it currently verifies the fs_info::super_copy::fsid instead, +which is not correct. Fix this using the correct fsid in the superblock +argument. + +CC: stable@vger.kernel.org # 5.4+ +Reviewed-by: Johannes Thumshirn +Tested-by: Guilherme G. Piccoli +Signed-off-by: Anand Jain +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -2721,11 +2721,10 @@ int btrfs_validate_super(struct btrfs_fs + ret = -EINVAL; + } + +- if (memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, +- BTRFS_FSID_SIZE)) { ++ if (memcmp(fs_info->fs_devices->fsid, sb->fsid, BTRFS_FSID_SIZE) != 0) { + btrfs_err(fs_info, + "superblock fsid doesn't match fsid of fs_devices: %pU != %pU", +- fs_info->super_copy->fsid, fs_info->fs_devices->fsid); ++ sb->fsid, fs_info->fs_devices->fsid); + ret = -EINVAL; + } + diff --git a/queue-6.1/btrfs-zoned-re-enable-metadata-over-commit-for-zoned-mode.patch b/queue-6.1/btrfs-zoned-re-enable-metadata-over-commit-for-zoned-mode.patch new file mode 100644 index 00000000000..f26dc2aff67 --- /dev/null +++ b/queue-6.1/btrfs-zoned-re-enable-metadata-over-commit-for-zoned-mode.patch @@ -0,0 +1,42 @@ +From 5b135b382a360f4c87cf8896d1465b0b07f10cb0 Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Tue, 8 Aug 2023 01:12:40 +0900 +Subject: btrfs: zoned: re-enable metadata over-commit for zoned mode + +From: Naohiro Aota + +commit 5b135b382a360f4c87cf8896d1465b0b07f10cb0 upstream. + +Now that, we can re-enable metadata over-commit. As we moved the activation +from the reservation time to the write time, we no longer need to ensure +all the reserved bytes is properly activated. + +Without the metadata over-commit, it suffers from lower performance because +it needs to flush the delalloc items more often and allocate more block +groups. Re-enabling metadata over-commit will solve the issue. + +Fixes: 79417d040f4f ("btrfs: zoned: disable metadata overcommit for zoned") +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Naohiro Aota +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/space-info.c | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) + +--- a/fs/btrfs/space-info.c ++++ b/fs/btrfs/space-info.c +@@ -404,11 +404,7 @@ int btrfs_can_overcommit(struct btrfs_fs + return 0; + + used = btrfs_space_info_used(space_info, true); +- if (test_bit(BTRFS_FS_ACTIVE_ZONE_TRACKING, &fs_info->flags) && +- (space_info->flags & BTRFS_BLOCK_GROUP_METADATA)) +- avail = 0; +- else +- avail = calc_available_free_space(fs_info, space_info, flush); ++ avail = calc_available_free_space(fs_info, space_info, flush); + + if (used + bytes < writable_total_bytes(fs_info, space_info) + avail) + return 1; diff --git a/queue-6.1/drm-amd-display-always-switch-off-odm-before-committing-more-streams.patch b/queue-6.1/drm-amd-display-always-switch-off-odm-before-committing-more-streams.patch new file mode 100644 index 00000000000..b4c51854374 --- /dev/null +++ b/queue-6.1/drm-amd-display-always-switch-off-odm-before-committing-more-streams.patch @@ -0,0 +1,46 @@ +From 49a30c3d1a2258fc93cfe6eea8e4951dabadc824 Mon Sep 17 00:00:00 2001 +From: Wenjing Liu +Date: Tue, 15 Aug 2023 10:47:52 -0400 +Subject: drm/amd/display: always switch off ODM before committing more streams + +From: Wenjing Liu + +commit 49a30c3d1a2258fc93cfe6eea8e4951dabadc824 upstream. + +ODM power optimization is only supported with single stream. When ODM +power optimization is enabled, we might not have enough free pipes for +enabling other stream. So when we are committing more than 1 stream we +should first switch off ODM power optimization to make room for new +stream and then allocating pipe resource for the new stream. + +Cc: stable@vger.kernel.org +Fixes: 59de751e3845 ("drm/amd/display: add ODM case when looking for first split pipe") +Reviewed-by: Dillon Varone +Acked-by: Hamza Mahfooz +Signed-off-by: Wenjing Liu +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/core/dc.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc.c +@@ -1977,12 +1977,12 @@ enum dc_status dc_commit_streams(struct + } + } + +- /* Check for case where we are going from odm 2:1 to max +- * pipe scenario. For these cases, we will call +- * commit_minimal_transition_state() to exit out of odm 2:1 +- * first before processing new streams ++ /* ODM Combine 2:1 power optimization is only applied for single stream ++ * scenario, it uses extra pipes than needed to reduce power consumption ++ * We need to switch off this feature to make room for new streams. + */ +- if (stream_count == dc->res_pool->pipe_count) { ++ if (stream_count > dc->current_state->stream_count && ++ dc->current_state->stream_count == 1) { + for (i = 0; i < dc->res_pool->pipe_count; i++) { + pipe = &dc->current_state->res_ctx.pipe_ctx[i]; + if (pipe->next_odm_pipe) diff --git a/queue-6.1/drm-amd-display-enable-cursor-degamma-for-dcn3-drm-legacy-gamma.patch b/queue-6.1/drm-amd-display-enable-cursor-degamma-for-dcn3-drm-legacy-gamma.patch new file mode 100644 index 00000000000..b77264a297f --- /dev/null +++ b/queue-6.1/drm-amd-display-enable-cursor-degamma-for-dcn3-drm-legacy-gamma.patch @@ -0,0 +1,44 @@ +From 57a943ebfcdb4a97fbb409640234bdb44bfa1953 Mon Sep 17 00:00:00 2001 +From: Melissa Wen +Date: Thu, 31 Aug 2023 15:12:28 -0100 +Subject: drm/amd/display: enable cursor degamma for DCN3+ DRM legacy gamma + +From: Melissa Wen + +commit 57a943ebfcdb4a97fbb409640234bdb44bfa1953 upstream. + +For DRM legacy gamma, AMD display manager applies implicit sRGB degamma +using a pre-defined sRGB transfer function. It works fine for DCN2 +family where degamma ROM and custom curves go to the same color block. +But, on DCN3+, degamma is split into two blocks: degamma ROM for +pre-defined TFs and `gamma correction` for user/custom curves and +degamma ROM settings doesn't apply to cursor plane. To get DRM legacy +gamma working as expected, enable cursor degamma ROM for implict sRGB +degamma on HW with this configuration. + +Cc: stable@vger.kernel.org +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2803 +Fixes: 96b020e2163f ("drm/amd/display: check attr flag before set cursor degamma on DCN3+") +Signed-off-by: Melissa Wen +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c +@@ -1269,6 +1269,13 @@ void handle_cursor_update(struct drm_pla + attributes.rotation_angle = 0; + attributes.attribute_flags.value = 0; + ++ /* Enable cursor degamma ROM on DCN3+ for implicit sRGB degamma in DRM ++ * legacy gamma setup. ++ */ ++ if (crtc_state->cm_is_degamma_srgb && ++ adev->dm.dc->caps.color.dpp.gamma_corr) ++ attributes.attribute_flags.bits.ENABLE_CURSOR_DEGAMMA = 1; ++ + attributes.pitch = afb->base.pitches[0] / afb->base.format->cpp[0]; + + if (crtc_state->stream) { diff --git a/queue-6.1/drm-amd-display-prevent-potential-division-by-zero-errors.patch b/queue-6.1/drm-amd-display-prevent-potential-division-by-zero-errors.patch new file mode 100644 index 00000000000..ced3099f9cf --- /dev/null +++ b/queue-6.1/drm-amd-display-prevent-potential-division-by-zero-errors.patch @@ -0,0 +1,50 @@ +From 07e388aab042774f284a2ad75a70a194517cdad4 Mon Sep 17 00:00:00 2001 +From: Hamza Mahfooz +Date: Tue, 5 Sep 2023 13:27:22 -0400 +Subject: drm/amd/display: prevent potential division by zero errors + +From: Hamza Mahfooz + +commit 07e388aab042774f284a2ad75a70a194517cdad4 upstream. + +There are two places in apply_below_the_range() where it's possible for +a divide by zero error to occur. So, to fix this make sure the divisor +is non-zero before attempting the computation in both cases. + +Cc: stable@vger.kernel.org +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637 +Fixes: a463b263032f ("drm/amd/display: Fix frames_to_insert math") +Fixes: ded6119e825a ("drm/amd/display: Reinstate LFC optimization") +Reviewed-by: Aurabindo Pillai +Signed-off-by: Hamza Mahfooz +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c ++++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c +@@ -338,7 +338,9 @@ static void apply_below_the_range(struct + * - Delta for CEIL: delta_from_mid_point_in_us_1 + * - Delta for FLOOR: delta_from_mid_point_in_us_2 + */ +- if ((last_render_time_in_us / mid_point_frames_ceil) < in_out_vrr->min_duration_in_us) { ++ if (mid_point_frames_ceil && ++ (last_render_time_in_us / mid_point_frames_ceil) < ++ in_out_vrr->min_duration_in_us) { + /* Check for out of range. + * If using CEIL produces a value that is out of range, + * then we are forced to use FLOOR. +@@ -385,8 +387,9 @@ static void apply_below_the_range(struct + /* Either we've calculated the number of frames to insert, + * or we need to insert min duration frames + */ +- if (last_render_time_in_us / frames_to_insert < +- in_out_vrr->min_duration_in_us){ ++ if (frames_to_insert && ++ (last_render_time_in_us / frames_to_insert) < ++ in_out_vrr->min_duration_in_us){ + frames_to_insert -= (frames_to_insert > 1) ? + 1 : 0; + } diff --git a/queue-6.1/drm-amd-display-remove-wait-while-locked.patch b/queue-6.1/drm-amd-display-remove-wait-while-locked.patch new file mode 100644 index 00000000000..70db7118b88 --- /dev/null +++ b/queue-6.1/drm-amd-display-remove-wait-while-locked.patch @@ -0,0 +1,134 @@ +From 5a3ccb1400339268c5e3dc1fa044a7f6c7f59a02 Mon Sep 17 00:00:00 2001 +From: Gabe Teeger +Date: Mon, 14 Aug 2023 16:06:18 -0400 +Subject: drm/amd/display: Remove wait while locked + +From: Gabe Teeger + +commit 5a3ccb1400339268c5e3dc1fa044a7f6c7f59a02 upstream. + +[Why] +We wait for mpc idle while in a locked state, leading to potential +deadlock. + +[What] +Move the wait_for_idle call to outside of HW lock. This and a +call to wait_drr_doublebuffer_pending_clear are moved added to a new +static helper function called wait_for_outstanding_hw_updates, to make +the interface clearer. + +Cc: stable@vger.kernel.org +Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR") +Reviewed-by: Jun Lei +Acked-by: Hamza Mahfooz +Signed-off-by: Gabe Teeger +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/Makefile | 1 + drivers/gpu/drm/amd/display/dc/core/dc.c | 58 ++++++++++++++------- + drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 11 --- + 3 files changed, 42 insertions(+), 28 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/Makefile ++++ b/drivers/gpu/drm/amd/display/dc/Makefile +@@ -82,3 +82,4 @@ DC_EDID += dc_edid_parser.o + AMD_DISPLAY_DMUB = $(addprefix $(AMDDALPATH)/dc/,$(DC_DMUB)) + AMD_DISPLAY_EDID = $(addprefix $(AMDDALPATH)/dc/,$(DC_EDID)) + AMD_DISPLAY_FILES += $(AMD_DISPLAY_DMUB) $(AMD_DISPLAY_EDID) ++ +--- a/drivers/gpu/drm/amd/display/dc/core/dc.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc.c +@@ -3361,6 +3361,45 @@ void dc_dmub_update_dirty_rect(struct dc + } + } + ++static void wait_for_outstanding_hw_updates(struct dc *dc, const struct dc_state *dc_context) ++{ ++/* ++ * This function calls HWSS to wait for any potentially double buffered ++ * operations to complete. It should be invoked as a pre-amble prior ++ * to full update programming before asserting any HW locks. ++ */ ++ int pipe_idx; ++ int opp_inst; ++ int opp_count = dc->res_pool->pipe_count; ++ struct hubp *hubp; ++ int mpcc_inst; ++ const struct pipe_ctx *pipe_ctx; ++ ++ for (pipe_idx = 0; pipe_idx < dc->res_pool->pipe_count; pipe_idx++) { ++ pipe_ctx = &dc_context->res_ctx.pipe_ctx[pipe_idx]; ++ ++ if (!pipe_ctx->stream) ++ continue; ++ ++ if (pipe_ctx->stream_res.tg->funcs->wait_drr_doublebuffer_pending_clear) ++ pipe_ctx->stream_res.tg->funcs->wait_drr_doublebuffer_pending_clear(pipe_ctx->stream_res.tg); ++ ++ hubp = pipe_ctx->plane_res.hubp; ++ if (!hubp) ++ continue; ++ ++ mpcc_inst = hubp->inst; ++ // MPCC inst is equal to pipe index in practice ++ for (opp_inst = 0; opp_inst < opp_count; opp_inst++) { ++ if (dc->res_pool->opps[opp_inst]->mpcc_disconnect_pending[mpcc_inst]) { ++ dc->res_pool->mpc->funcs->wait_for_idle(dc->res_pool->mpc, mpcc_inst); ++ dc->res_pool->opps[opp_inst]->mpcc_disconnect_pending[mpcc_inst] = false; ++ break; ++ } ++ } ++ } ++} ++ + static void commit_planes_for_stream(struct dc *dc, + struct dc_surface_update *srf_updates, + int surface_count, +@@ -3378,24 +3417,9 @@ static void commit_planes_for_stream(str + // dc->current_state anymore, so we have to cache it before we apply + // the new SubVP context + subvp_prev_use = false; +- +- + dc_z10_restore(dc); +- +- if (update_type == UPDATE_TYPE_FULL) { +- /* wait for all double-buffer activity to clear on all pipes */ +- int pipe_idx; +- +- for (pipe_idx = 0; pipe_idx < dc->res_pool->pipe_count; pipe_idx++) { +- struct pipe_ctx *pipe_ctx = &context->res_ctx.pipe_ctx[pipe_idx]; +- +- if (!pipe_ctx->stream) +- continue; +- +- if (pipe_ctx->stream_res.tg->funcs->wait_drr_doublebuffer_pending_clear) +- pipe_ctx->stream_res.tg->funcs->wait_drr_doublebuffer_pending_clear(pipe_ctx->stream_res.tg); +- } +- } ++ if (update_type == UPDATE_TYPE_FULL) ++ wait_for_outstanding_hw_updates(dc, context); + + if (get_seamless_boot_stream_count(context) > 0 && surface_count > 0) { + /* Optimize seamless boot flag keeps clocks and watermarks high until +--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c ++++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c +@@ -1515,17 +1515,6 @@ static void dcn20_update_dchubp_dpp( + || plane_state->update_flags.bits.global_alpha_change + || plane_state->update_flags.bits.per_pixel_alpha_change) { + // MPCC inst is equal to pipe index in practice +- int mpcc_inst = hubp->inst; +- int opp_inst; +- int opp_count = dc->res_pool->pipe_count; +- +- for (opp_inst = 0; opp_inst < opp_count; opp_inst++) { +- if (dc->res_pool->opps[opp_inst]->mpcc_disconnect_pending[mpcc_inst]) { +- dc->res_pool->mpc->funcs->wait_for_idle(dc->res_pool->mpc, mpcc_inst); +- dc->res_pool->opps[opp_inst]->mpcc_disconnect_pending[mpcc_inst] = false; +- break; +- } +- } + hws->funcs.update_mpcc(dc, pipe_ctx); + } + diff --git a/queue-6.1/drm-amdgpu-register-a-dirty-framebuffer-callback-for-fbcon.patch b/queue-6.1/drm-amdgpu-register-a-dirty-framebuffer-callback-for-fbcon.patch new file mode 100644 index 00000000000..cae917d1207 --- /dev/null +++ b/queue-6.1/drm-amdgpu-register-a-dirty-framebuffer-callback-for-fbcon.patch @@ -0,0 +1,84 @@ +From 0a611560f53bfd489e33f4a718c915f1a6123d03 Mon Sep 17 00:00:00 2001 +From: Hamza Mahfooz +Date: Tue, 15 Aug 2023 09:13:37 -0400 +Subject: drm/amdgpu: register a dirty framebuffer callback for fbcon + +From: Hamza Mahfooz + +commit 0a611560f53bfd489e33f4a718c915f1a6123d03 upstream. + +fbcon requires that we implement &drm_framebuffer_funcs.dirty. +Otherwise, the framebuffer might take a while to flush (which would +manifest as noticeable lag). However, we can't enable this callback for +non-fbcon cases since it may cause too many atomic commits to be made at +once. So, implement amdgpu_dirtyfb() and only enable it for fbcon +framebuffers (we can use the "struct drm_file file" parameter in the +callback to check for this since it is only NULL when called by fbcon, +at least in the mainline kernel) on devices that support atomic KMS. + +Cc: Aurabindo Pillai +Cc: Mario Limonciello +Cc: stable@vger.kernel.org # 6.1+ +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2519 +Reviewed-by: Mario Limonciello +Signed-off-by: Hamza Mahfooz +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 26 +++++++++++++++++++++++++- + 1 file changed, 25 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c +@@ -38,6 +38,8 @@ + #include + #include + #include ++#include ++#include + #include + #include + #include +@@ -493,11 +495,29 @@ bool amdgpu_display_ddc_probe(struct amd + return true; + } + ++static int amdgpu_dirtyfb(struct drm_framebuffer *fb, struct drm_file *file, ++ unsigned int flags, unsigned int color, ++ struct drm_clip_rect *clips, unsigned int num_clips) ++{ ++ ++ if (file) ++ return -ENOSYS; ++ ++ return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips, ++ num_clips); ++} ++ + static const struct drm_framebuffer_funcs amdgpu_fb_funcs = { + .destroy = drm_gem_fb_destroy, + .create_handle = drm_gem_fb_create_handle, + }; + ++static const struct drm_framebuffer_funcs amdgpu_fb_funcs_atomic = { ++ .destroy = drm_gem_fb_destroy, ++ .create_handle = drm_gem_fb_create_handle, ++ .dirty = amdgpu_dirtyfb ++}; ++ + uint32_t amdgpu_display_supported_domains(struct amdgpu_device *adev, + uint64_t bo_flags) + { +@@ -1100,7 +1120,11 @@ static int amdgpu_display_gem_fb_verify_ + if (ret) + goto err; + +- ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs); ++ if (drm_drv_uses_atomic_modeset(dev)) ++ ret = drm_framebuffer_init(dev, &rfb->base, ++ &amdgpu_fb_funcs_atomic); ++ else ++ ret = drm_framebuffer_init(dev, &rfb->base, &amdgpu_fb_funcs); + + if (ret) + goto err; diff --git a/queue-6.1/drm-mxsfb-disable-overlay-plane-in-mxsfb_plane_overlay_atomic_disable.patch b/queue-6.1/drm-mxsfb-disable-overlay-plane-in-mxsfb_plane_overlay_atomic_disable.patch new file mode 100644 index 00000000000..ad5ad445172 --- /dev/null +++ b/queue-6.1/drm-mxsfb-disable-overlay-plane-in-mxsfb_plane_overlay_atomic_disable.patch @@ -0,0 +1,50 @@ +From aa656d48e871a1b062e1bbf9474d8b831c35074c Mon Sep 17 00:00:00 2001 +From: Liu Ying +Date: Mon, 12 Jun 2023 17:23:59 +0800 +Subject: drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable() + +From: Liu Ying + +commit aa656d48e871a1b062e1bbf9474d8b831c35074c upstream. + +When disabling overlay plane in mxsfb_plane_overlay_atomic_update(), +overlay plane's framebuffer pointer is NULL. So, dereferencing it would +cause a kernel Oops(NULL pointer dereferencing). Fix the issue by +disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead. + +Fixes: cb285a5348e7 ("drm: mxsfb: Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr()") +Cc: stable@vger.kernel.org # 5.19+ +Signed-off-by: Liu Ying +Reviewed-by: Marek Vasut +Signed-off-by: Marek Vasut +Link: https://patchwork.freedesktop.org/patch/msgid/20230612092359.784115-1-victor.liu@nxp.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/mxsfb/mxsfb_kms.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c ++++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c +@@ -611,6 +611,14 @@ static void mxsfb_plane_overlay_atomic_u + writel(ctrl, mxsfb->base + LCDC_AS_CTRL); + } + ++static void mxsfb_plane_overlay_atomic_disable(struct drm_plane *plane, ++ struct drm_atomic_state *state) ++{ ++ struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev); ++ ++ writel(0, mxsfb->base + LCDC_AS_CTRL); ++} ++ + static bool mxsfb_format_mod_supported(struct drm_plane *plane, + uint32_t format, + uint64_t modifier) +@@ -626,6 +634,7 @@ static const struct drm_plane_helper_fun + static const struct drm_plane_helper_funcs mxsfb_plane_overlay_helper_funcs = { + .atomic_check = mxsfb_plane_atomic_check, + .atomic_update = mxsfb_plane_overlay_atomic_update, ++ .atomic_disable = mxsfb_plane_overlay_atomic_disable, + }; + + static const struct drm_plane_funcs mxsfb_plane_funcs = { diff --git a/queue-6.1/kvm-nsvm-check-instead-of-asserting-on-nested-tsc-scaling-support.patch b/queue-6.1/kvm-nsvm-check-instead-of-asserting-on-nested-tsc-scaling-support.patch new file mode 100644 index 00000000000..8e40875def4 --- /dev/null +++ b/queue-6.1/kvm-nsvm-check-instead-of-asserting-on-nested-tsc-scaling-support.patch @@ -0,0 +1,67 @@ +From 7cafe9b8e22bb3d77f130c461aedf6868c4aaf58 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 28 Jul 2023 18:15:48 -0700 +Subject: KVM: nSVM: Check instead of asserting on nested TSC scaling support + +From: Sean Christopherson + +commit 7cafe9b8e22bb3d77f130c461aedf6868c4aaf58 upstream. + +Check for nested TSC scaling support on nested SVM VMRUN instead of +asserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO +has diverged from KVM's default. Userspace can trigger the WARN at will +by writing the MSR and then updating guest CPUID to hide the feature +(modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking +KVM's state_test selftest to do + + vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); + vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); + +after restoring state in a new VM+vCPU yields an endless supply of: + + ------------[ cut here ]------------ + WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699 + nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd] + Call Trace: + + enter_svm_guest_mode+0x114/0x560 [kvm_amd] + nested_svm_vmrun+0x260/0x330 [kvm_amd] + vmrun_interception+0x29/0x30 [kvm_amd] + svm_invoke_exit_handler+0x35/0x100 [kvm_amd] + svm_handle_exit+0xe7/0x180 [kvm_amd] + kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] + kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] + __se_sys_ioctl+0x7a/0xc0 + __x64_sys_ioctl+0x21/0x30 + do_syscall_64+0x41/0x90 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + RIP: 0033:0x45ca1b + +Note, the nested #VMEXIT path has the same flaw, but needs a different +fix and will be handled separately. + +Fixes: 5228eb96a487 ("KVM: x86: nSVM: implement nested TSC scaling") +Cc: Maxim Levitsky +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230729011608.1065019-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -660,10 +660,9 @@ static void nested_vmcb02_prepare_contro + + vmcb02->control.tsc_offset = vcpu->arch.tsc_offset; + +- if (svm->tsc_ratio_msr != kvm_caps.default_tsc_scaling_ratio) { +- WARN_ON(!svm->tsc_scaling_enabled); ++ if (svm->tsc_scaling_enabled && ++ svm->tsc_ratio_msr != kvm_caps.default_tsc_scaling_ratio) + nested_svm_update_tsc_ratio_msr(vcpu); +- } + + vmcb02->control.int_ctl = + (svm->nested.ctl.int_ctl & int_ctl_vmcb12_bits) | diff --git a/queue-6.1/kvm-nsvm-load-l1-s-tsc-multiplier-based-on-l1-state-not-l2-state.patch b/queue-6.1/kvm-nsvm-load-l1-s-tsc-multiplier-based-on-l1-state-not-l2-state.patch new file mode 100644 index 00000000000..3b272049909 --- /dev/null +++ b/queue-6.1/kvm-nsvm-load-l1-s-tsc-multiplier-based-on-l1-state-not-l2-state.patch @@ -0,0 +1,71 @@ +From 0c94e2468491cbf0754f49a5136ab51294a96b69 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 28 Jul 2023 18:15:49 -0700 +Subject: KVM: nSVM: Load L1's TSC multiplier based on L1 state, not L2 state + +From: Sean Christopherson + +commit 0c94e2468491cbf0754f49a5136ab51294a96b69 upstream. + +When emulating nested VM-Exit, load L1's TSC multiplier if L1's desired +ratio doesn't match the current ratio, not if the ratio L1 is using for +L2 diverges from the default. Functionally, the end result is the same +as KVM will run L2 with L1's multiplier if L2's multiplier is the default, +i.e. checking that L1's multiplier is loaded is equivalent to checking if +L2 has a non-default multiplier. + +However, the assertion that TSC scaling is exposed to L1 is flawed, as +userspace can trigger the WARN at will by writing the MSR and then +updating guest CPUID to hide the feature (modifying guest CPUID is +allowed anytime before KVM_RUN). E.g. hacking KVM's state_test +selftest to do + + vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0); + vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR); + +after restoring state in a new VM+vCPU yields an endless supply of: + + ------------[ cut here ]------------ + WARNING: CPU: 10 PID: 206939 at arch/x86/kvm/svm/nested.c:1105 + nested_svm_vmexit+0x6af/0x720 [kvm_amd] + Call Trace: + nested_svm_exit_handled+0x102/0x1f0 [kvm_amd] + svm_handle_exit+0xb9/0x180 [kvm_amd] + kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm] + kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm] + ? trace_hardirqs_off+0x4d/0xa0 + __se_sys_ioctl+0x7a/0xc0 + __x64_sys_ioctl+0x21/0x30 + do_syscall_64+0x41/0x90 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +Unlike the nested VMRUN path, hoisting the svm->tsc_scaling_enabled check +into the if-statement is wrong as KVM needs to ensure L1's multiplier is +loaded in the above scenario. Alternatively, the WARN_ON() could simply +be deleted, but that would make KVM's behavior even more subtle, e.g. it's +not immediately obvious why it's safe to write MSR_AMD64_TSC_RATIO when +checking only tsc_ratio_msr. + +Fixes: 5228eb96a487 ("KVM: x86: nSVM: implement nested TSC scaling") +Cc: Maxim Levitsky +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230729011608.1065019-3-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -1021,8 +1021,8 @@ int nested_svm_vmexit(struct vcpu_svm *s + vmcb_mark_dirty(vmcb01, VMCB_INTERCEPTS); + } + +- if (svm->tsc_ratio_msr != kvm_caps.default_tsc_scaling_ratio) { +- WARN_ON(!svm->tsc_scaling_enabled); ++ if (kvm_caps.has_tsc_control && ++ vcpu->arch.tsc_scaling_ratio != vcpu->arch.l1_tsc_scaling_ratio) { + vcpu->arch.tsc_scaling_ratio = vcpu->arch.l1_tsc_scaling_ratio; + __svm_write_tsc_multiplier(vcpu->arch.tsc_scaling_ratio); + } diff --git a/queue-6.1/kvm-svm-don-t-inject-ud-if-kvm-attempts-to-skip-sev-guest-insn.patch b/queue-6.1/kvm-svm-don-t-inject-ud-if-kvm-attempts-to-skip-sev-guest-insn.patch new file mode 100644 index 00000000000..2c4c04f8794 --- /dev/null +++ b/queue-6.1/kvm-svm-don-t-inject-ud-if-kvm-attempts-to-skip-sev-guest-insn.patch @@ -0,0 +1,104 @@ +From cb49631ad111570f1bad37702c11c2ae07fa2e3c Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 24 Aug 2023 18:36:18 -0700 +Subject: KVM: SVM: Don't inject #UD if KVM attempts to skip SEV guest insn + +From: Sean Christopherson + +commit cb49631ad111570f1bad37702c11c2ae07fa2e3c upstream. + +Don't inject a #UD if KVM attempts to "emulate" to skip an instruction +for an SEV guest, and instead resume the guest and hope that it can make +forward progress. When commit 04c40f344def ("KVM: SVM: Inject #UD on +attempted emulation for SEV guest w/o insn buffer") added the completely +arbitrary #UD behavior, there were no known scenarios where a well-behaved +guest would induce a VM-Exit that triggered emulation, i.e. it was thought +that injecting #UD would be helpful. + +However, now that KVM (correctly) attempts to re-inject INT3/INTO, e.g. if +a #NPF is encountered when attempting to deliver the INT3/INTO, an SEV +guest can trigger emulation without a buffer, through no fault of its own. +Resuming the guest and retrying the INT3/INTO is architecturally wrong, +e.g. the vCPU will incorrectly re-hit code #DBs, but for SEV guests there +is literally no other option that has a chance of making forward progress. + +Drop the #UD injection for all "skip" emulation, not just those related to +INT3/INTO, even though that means that the guest will likely end up in an +infinite loop instead of getting a #UD (the vCPU may also crash, e.g. if +KVM emulated everything about an instruction except for advancing RIP). +There's no evidence that suggests that an unexpected #UD is actually +better than hanging the vCPU, e.g. a soft-hung vCPU can still respond to +IRQs and NMIs to generate a backtrace. + +Reported-by: Wu Zongyo +Closes: https://lore.kernel.org/all/8eb933fd-2cf3-d7a9-32fe-2a1d82eac42a@mail.ustc.edu.cn +Fixes: 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction") +Cc: stable@vger.kernel.org +Cc: Tom Lendacky +Link: https://lore.kernel.org/r/20230825013621.2845700-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/svm.c | 35 +++++++++++++++++++++++++++-------- + 1 file changed, 27 insertions(+), 8 deletions(-) + +--- a/arch/x86/kvm/svm/svm.c ++++ b/arch/x86/kvm/svm/svm.c +@@ -366,6 +366,8 @@ static void svm_set_interrupt_shadow(str + svm->vmcb->control.int_state |= SVM_INTERRUPT_SHADOW_MASK; + + } ++static bool svm_can_emulate_instruction(struct kvm_vcpu *vcpu, int emul_type, ++ void *insn, int insn_len); + + static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu, + bool commit_side_effects) +@@ -386,6 +388,14 @@ static int __svm_skip_emulated_instructi + } + + if (!svm->next_rip) { ++ /* ++ * FIXME: Drop this when kvm_emulate_instruction() does the ++ * right thing and treats "can't emulate" as outright failure ++ * for EMULTYPE_SKIP. ++ */ ++ if (!svm_can_emulate_instruction(vcpu, EMULTYPE_SKIP, NULL, 0)) ++ return 0; ++ + if (unlikely(!commit_side_effects)) + old_rflags = svm->vmcb->save.rflags; + +@@ -4592,16 +4602,25 @@ static bool svm_can_emulate_instruction( + * and cannot be decrypted by KVM, i.e. KVM would read cyphertext and + * decode garbage. + * +- * Inject #UD if KVM reached this point without an instruction buffer. +- * In practice, this path should never be hit by a well-behaved guest, +- * e.g. KVM doesn't intercept #UD or #GP for SEV guests, but this path +- * is still theoretically reachable, e.g. via unaccelerated fault-like +- * AVIC access, and needs to be handled by KVM to avoid putting the +- * guest into an infinite loop. Injecting #UD is somewhat arbitrary, +- * but its the least awful option given lack of insight into the guest. ++ * If KVM is NOT trying to simply skip an instruction, inject #UD if ++ * KVM reached this point without an instruction buffer. In practice, ++ * this path should never be hit by a well-behaved guest, e.g. KVM ++ * doesn't intercept #UD or #GP for SEV guests, but this path is still ++ * theoretically reachable, e.g. via unaccelerated fault-like AVIC ++ * access, and needs to be handled by KVM to avoid putting the guest ++ * into an infinite loop. Injecting #UD is somewhat arbitrary, but ++ * its the least awful option given lack of insight into the guest. ++ * ++ * If KVM is trying to skip an instruction, simply resume the guest. ++ * If a #NPF occurs while the guest is vectoring an INT3/INTO, then KVM ++ * will attempt to re-inject the INT3/INTO and skip the instruction. ++ * In that scenario, retrying the INT3/INTO and hoping the guest will ++ * make forward progress is the only option that has a chance of ++ * success (and in practice it will work the vast majority of the time). + */ + if (unlikely(!insn)) { +- kvm_queue_exception(vcpu, UD_VECTOR); ++ if (!(emul_type & EMULTYPE_SKIP)) ++ kvm_queue_exception(vcpu, UD_VECTOR); + return false; + } + diff --git a/queue-6.1/kvm-svm-get-source-vcpus-from-source-vm-for-sev-es-intrahost-migration.patch b/queue-6.1/kvm-svm-get-source-vcpus-from-source-vm-for-sev-es-intrahost-migration.patch new file mode 100644 index 00000000000..417b0e5a499 --- /dev/null +++ b/queue-6.1/kvm-svm-get-source-vcpus-from-source-vm-for-sev-es-intrahost-migration.patch @@ -0,0 +1,75 @@ +From f1187ef24eb8f36e8ad8106d22615ceddeea6097 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 24 Aug 2023 19:23:56 -0700 +Subject: KVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migration + +From: Sean Christopherson + +commit f1187ef24eb8f36e8ad8106d22615ceddeea6097 upstream. + +Fix a goof where KVM tries to grab source vCPUs from the destination VM +when doing intrahost migration. Grabbing the wrong vCPU not only hoses +the guest, it also crashes the host due to the VMSA pointer being left +NULL. + + BUG: unable to handle page fault for address: ffffe38687000000 + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 0 P4D 0 + Oops: 0000 [#1] SMP NOPTI + CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO 6.5.0-smp--fff2e47e6c3b-next #151 + Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023 + RIP: 0010:__free_pages+0x15/0xd0 + RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffffe38687000000 RCX: 0000000000000100 + RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffe38687000000 + RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: 0000000000000000 + R10: 0000000000000000 R11: ffffffff83619b90 R12: ffff923fa9540000 + R13: 0000000000080007 R14: ffff923f6d35d000 R15: 0000000000000000 + FS: 0000000000000000(0000) GS:ffff929d0d7c0000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: ffffe38687000000 CR3: 0000005224c34005 CR4: 0000000000770ee0 + PKRU: 55555554 + Call Trace: + + sev_free_vcpu+0xcb/0x110 [kvm_amd] + svm_vcpu_free+0x75/0xf0 [kvm_amd] + kvm_arch_vcpu_destroy+0x36/0x140 [kvm] + kvm_destroy_vcpus+0x67/0x100 [kvm] + kvm_arch_destroy_vm+0x161/0x1d0 [kvm] + kvm_put_kvm+0x276/0x560 [kvm] + kvm_vm_release+0x25/0x30 [kvm] + __fput+0x106/0x280 + ____fput+0x12/0x20 + task_work_run+0x86/0xb0 + do_exit+0x2e3/0x9c0 + do_group_exit+0xb1/0xc0 + __x64_sys_exit_group+0x1b/0x20 + do_syscall_64+0x41/0x90 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + + CR2: ffffe38687000000 + +Fixes: 6defa24d3b12 ("KVM: SEV: Init target VMCBs in sev_migrate_from") +Cc: stable@vger.kernel.org +Cc: Peter Gonda +Reviewed-by: Peter Gonda +Reviewed-by: Pankaj Gupta +Link: https://lore.kernel.org/r/20230825022357.2852133-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -1723,7 +1723,7 @@ static void sev_migrate_from(struct kvm + * Note, the source is not required to have the same number of + * vCPUs as the destination when migrating a vanilla SEV VM. + */ +- src_vcpu = kvm_get_vcpu(dst_kvm, i); ++ src_vcpu = kvm_get_vcpu(src_kvm, i); + src_svm = to_svm(src_vcpu); + + /* diff --git a/queue-6.1/kvm-svm-set-target-pcpu-during-irte-update-if-target-vcpu-is-running.patch b/queue-6.1/kvm-svm-set-target-pcpu-during-irte-update-if-target-vcpu-is-running.patch new file mode 100644 index 00000000000..ffbe1b2093f --- /dev/null +++ b/queue-6.1/kvm-svm-set-target-pcpu-during-irte-update-if-target-vcpu-is-running.patch @@ -0,0 +1,95 @@ +From f3cebc75e7425d6949d726bb8e937095b0aef025 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 8 Aug 2023 16:31:32 -0700 +Subject: KVM: SVM: Set target pCPU during IRTE update if target vCPU is running + +From: Sean Christopherson + +commit f3cebc75e7425d6949d726bb8e937095b0aef025 upstream. + +Update the target pCPU for IOMMU doorbells when updating IRTE routing if +KVM is actively running the associated vCPU. KVM currently only updates +the pCPU when loading the vCPU (via avic_vcpu_load()), and so doorbell +events will be delayed until the vCPU goes through a put+load cycle (which +might very well "never" happen for the lifetime of the VM). + +To avoid inserting a stale pCPU, e.g. due to racing between updating IRTE +routing and vCPU load/put, get the pCPU information from the vCPU's +Physical APIC ID table entry (a.k.a. avic_physical_id_cache in KVM) and +update the IRTE while holding ir_list_lock. Add comments with --verbose +enabled to explain exactly what is and isn't protected by ir_list_lock. + +Fixes: 411b44ba80ab ("svm: Implements update_pi_irte hook to setup posted interrupt") +Reported-by: dengqiao.joey +Cc: stable@vger.kernel.org +Cc: Alejandro Jimenez +Cc: Joao Martins +Cc: Maxim Levitsky +Cc: Suravee Suthikulpanit +Tested-by: Alejandro Jimenez +Reviewed-by: Joao Martins +Link: https://lore.kernel.org/r/20230808233132.2499764-3-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/avic.c | 28 ++++++++++++++++++++++++++++ + 1 file changed, 28 insertions(+) + +--- a/arch/x86/kvm/svm/avic.c ++++ b/arch/x86/kvm/svm/avic.c +@@ -810,6 +810,7 @@ static int svm_ir_list_add(struct vcpu_s + int ret = 0; + unsigned long flags; + struct amd_svm_iommu_ir *ir; ++ u64 entry; + + /** + * In some cases, the existing irte is updated and re-set, +@@ -843,6 +844,18 @@ static int svm_ir_list_add(struct vcpu_s + ir->data = pi->ir_data; + + spin_lock_irqsave(&svm->ir_list_lock, flags); ++ ++ /* ++ * Update the target pCPU for IOMMU doorbells if the vCPU is running. ++ * If the vCPU is NOT running, i.e. is blocking or scheduled out, KVM ++ * will update the pCPU info when the vCPU awkened and/or scheduled in. ++ * See also avic_vcpu_load(). ++ */ ++ entry = READ_ONCE(*(svm->avic_physical_id_cache)); ++ if (entry & AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK) ++ amd_iommu_update_ga(entry & AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK, ++ true, pi->ir_data); ++ + list_add(&ir->node, &svm->ir_list); + spin_unlock_irqrestore(&svm->ir_list_lock, flags); + out: +@@ -1067,6 +1080,13 @@ void avic_vcpu_load(struct kvm_vcpu *vcp + if (kvm_vcpu_is_blocking(vcpu)) + return; + ++ /* ++ * Grab the per-vCPU interrupt remapping lock even if the VM doesn't ++ * _currently_ have assigned devices, as that can change. Holding ++ * ir_list_lock ensures that either svm_ir_list_add() will consume ++ * up-to-date entry information, or that this task will wait until ++ * svm_ir_list_add() completes to set the new target pCPU. ++ */ + spin_lock_irqsave(&svm->ir_list_lock, flags); + + entry = READ_ONCE(*(svm->avic_physical_id_cache)); +@@ -1102,6 +1122,14 @@ void avic_vcpu_put(struct kvm_vcpu *vcpu + if (!(entry & AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK)) + return; + ++ /* ++ * Take and hold the per-vCPU interrupt remapping lock while updating ++ * the Physical ID entry even though the lock doesn't protect against ++ * multiple writers (see above). Holding ir_list_lock ensures that ++ * either svm_ir_list_add() will consume up-to-date entry information, ++ * or that this task will wait until svm_ir_list_add() completes to ++ * mark the vCPU as not running. ++ */ + spin_lock_irqsave(&svm->ir_list_lock, flags); + + avic_update_iommu_vcpu_affinity(vcpu, -1, 0); diff --git a/queue-6.1/kvm-svm-skip-vmsa-init-in-sev_es_init_vmcb-if-pointer-is-null.patch b/queue-6.1/kvm-svm-skip-vmsa-init-in-sev_es_init_vmcb-if-pointer-is-null.patch new file mode 100644 index 00000000000..eb09ec2ce0e --- /dev/null +++ b/queue-6.1/kvm-svm-skip-vmsa-init-in-sev_es_init_vmcb-if-pointer-is-null.patch @@ -0,0 +1,47 @@ +From 1952e74da96fb3e48b72a2d0ece78c688a5848c1 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 24 Aug 2023 19:23:57 -0700 +Subject: KVM: SVM: Skip VMSA init in sev_es_init_vmcb() if pointer is NULL + +From: Sean Christopherson + +commit 1952e74da96fb3e48b72a2d0ece78c688a5848c1 upstream. + +Skip initializing the VMSA physical address in the VMCB if the VMSA is +NULL, which occurs during intrahost migration as KVM initializes the VMCB +before copying over state from the source to the destination (including +the VMSA and its physical address). + +In normal builds, __pa() is just math, so the bug isn't fatal, but with +CONFIG_DEBUG_VIRTUAL=y, the validity of the virtual address is verified +and passing in NULL will make the kernel unhappy. + +Fixes: 6defa24d3b12 ("KVM: SEV: Init target VMCBs in sev_migrate_from") +Cc: stable@vger.kernel.org +Cc: Peter Gonda +Reviewed-by: Peter Gonda +Reviewed-by: Pankaj Gupta +Link: https://lore.kernel.org/r/20230825022357.2852133-3-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/sev.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/svm/sev.c ++++ b/arch/x86/kvm/svm/sev.c +@@ -2951,9 +2951,12 @@ static void sev_es_init_vmcb(struct vcpu + /* + * An SEV-ES guest requires a VMSA area that is a separate from the + * VMCB page. Do not include the encryption mask on the VMSA physical +- * address since hardware will access it using the guest key. ++ * address since hardware will access it using the guest key. Note, ++ * the VMSA will be NULL if this vCPU is the destination for intrahost ++ * migration, and will be copied later. + */ +- svm->vmcb->control.vmsa_pa = __pa(svm->sev_es.vmsa); ++ if (svm->sev_es.vmsa) ++ svm->vmcb->control.vmsa_pa = __pa(svm->sev_es.vmsa); + + /* Can't intercept CR register access, HV can't modify CR registers */ + svm_clr_intercept(svm, INTERCEPT_CR0_READ); diff --git a/queue-6.1/kvm-svm-take-and-hold-ir_list_lock-when-updating-vcpu-s-physical-id-entry.patch b/queue-6.1/kvm-svm-take-and-hold-ir_list_lock-when-updating-vcpu-s-physical-id-entry.patch new file mode 100644 index 00000000000..08f0132c7a8 --- /dev/null +++ b/queue-6.1/kvm-svm-take-and-hold-ir_list_lock-when-updating-vcpu-s-physical-id-entry.patch @@ -0,0 +1,131 @@ +From 4c08e737f056fec930b416a2bd37ed266d724f95 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 8 Aug 2023 16:31:31 -0700 +Subject: KVM: SVM: Take and hold ir_list_lock when updating vCPU's Physical ID entry + +From: Sean Christopherson + +commit 4c08e737f056fec930b416a2bd37ed266d724f95 upstream. + +Hoist the acquisition of ir_list_lock from avic_update_iommu_vcpu_affinity() +to its two callers, avic_vcpu_load() and avic_vcpu_put(), specifically to +encapsulate the write to the vCPU's entry in the AVIC Physical ID table. +This will allow a future fix to pull information from the Physical ID entry +when updating the IRTE, without potentially consuming stale information, +i.e. without racing with the vCPU being (un)loaded. + +Add a comment to call out that ir_list_lock does NOT protect against +multiple writers, specifically that reading the Physical ID entry in +avic_vcpu_put() outside of the lock is safe. + +To preserve some semblance of independence from ir_list_lock, keep the +READ_ONCE() in avic_vcpu_load() even though acuiring the spinlock +effectively ensures the load(s) will be generated after acquiring the +lock. + +Cc: stable@vger.kernel.org +Tested-by: Alejandro Jimenez +Reviewed-by: Joao Martins +Link: https://lore.kernel.org/r/20230808233132.2499764-2-seanjc@google.com +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/avic.c | 31 +++++++++++++++++++++++-------- + 1 file changed, 23 insertions(+), 8 deletions(-) + +--- a/arch/x86/kvm/svm/avic.c ++++ b/arch/x86/kvm/svm/avic.c +@@ -1022,10 +1022,11 @@ static inline int + avic_update_iommu_vcpu_affinity(struct kvm_vcpu *vcpu, int cpu, bool r) + { + int ret = 0; +- unsigned long flags; + struct amd_svm_iommu_ir *ir; + struct vcpu_svm *svm = to_svm(vcpu); + ++ lockdep_assert_held(&svm->ir_list_lock); ++ + if (!kvm_arch_has_assigned_device(vcpu->kvm)) + return 0; + +@@ -1033,19 +1034,15 @@ avic_update_iommu_vcpu_affinity(struct k + * Here, we go through the per-vcpu ir_list to update all existing + * interrupt remapping table entry targeting this vcpu. + */ +- spin_lock_irqsave(&svm->ir_list_lock, flags); +- + if (list_empty(&svm->ir_list)) +- goto out; ++ return 0; + + list_for_each_entry(ir, &svm->ir_list, node) { + ret = amd_iommu_update_ga(cpu, r, ir->data); + if (ret) +- break; ++ return ret; + } +-out: +- spin_unlock_irqrestore(&svm->ir_list_lock, flags); +- return ret; ++ return 0; + } + + void avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu) +@@ -1053,6 +1050,7 @@ void avic_vcpu_load(struct kvm_vcpu *vcp + u64 entry; + int h_physical_id = kvm_cpu_get_apicid(cpu); + struct vcpu_svm *svm = to_svm(vcpu); ++ unsigned long flags; + + lockdep_assert_preemption_disabled(); + +@@ -1069,6 +1067,8 @@ void avic_vcpu_load(struct kvm_vcpu *vcp + if (kvm_vcpu_is_blocking(vcpu)) + return; + ++ spin_lock_irqsave(&svm->ir_list_lock, flags); ++ + entry = READ_ONCE(*(svm->avic_physical_id_cache)); + + entry &= ~AVIC_PHYSICAL_ID_ENTRY_HOST_PHYSICAL_ID_MASK; +@@ -1077,25 +1077,40 @@ void avic_vcpu_load(struct kvm_vcpu *vcp + + WRITE_ONCE(*(svm->avic_physical_id_cache), entry); + avic_update_iommu_vcpu_affinity(vcpu, h_physical_id, true); ++ ++ spin_unlock_irqrestore(&svm->ir_list_lock, flags); + } + + void avic_vcpu_put(struct kvm_vcpu *vcpu) + { + u64 entry; + struct vcpu_svm *svm = to_svm(vcpu); ++ unsigned long flags; + + lockdep_assert_preemption_disabled(); + ++ /* ++ * Note, reading the Physical ID entry outside of ir_list_lock is safe ++ * as only the pCPU that has loaded (or is loading) the vCPU is allowed ++ * to modify the entry, and preemption is disabled. I.e. the vCPU ++ * can't be scheduled out and thus avic_vcpu_{put,load}() can't run ++ * recursively. ++ */ + entry = READ_ONCE(*(svm->avic_physical_id_cache)); + + /* Nothing to do if IsRunning == '0' due to vCPU blocking. */ + if (!(entry & AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK)) + return; + ++ spin_lock_irqsave(&svm->ir_list_lock, flags); ++ + avic_update_iommu_vcpu_affinity(vcpu, -1, 0); + + entry &= ~AVIC_PHYSICAL_ID_ENTRY_IS_RUNNING_MASK; + WRITE_ONCE(*(svm->avic_physical_id_cache), entry); ++ ++ spin_unlock_irqrestore(&svm->ir_list_lock, flags); ++ + } + + void avic_refresh_virtual_apic_mode(struct kvm_vcpu *vcpu) diff --git a/queue-6.1/mips-fix-config_cpu_daddi_workarounds-modules_install-regression.patch b/queue-6.1/mips-fix-config_cpu_daddi_workarounds-modules_install-regression.patch new file mode 100644 index 00000000000..8911ca2cdd2 --- /dev/null +++ b/queue-6.1/mips-fix-config_cpu_daddi_workarounds-modules_install-regression.patch @@ -0,0 +1,48 @@ +From a79a404e6c2241ebc528b9ebf4c0832457b498c3 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Tue, 18 Jul 2023 15:37:18 +0100 +Subject: MIPS: Fix CONFIG_CPU_DADDI_WORKAROUNDS `modules_install' regression +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Maciej W. Rozycki + +commit a79a404e6c2241ebc528b9ebf4c0832457b498c3 upstream. + +Remove a build-time check for the presence of the GCC `-msym32' option. +This option has been there since GCC 4.1.0, which is below the minimum +required as at commit 805b2e1d427a ("kbuild: include Makefile.compiler +only when compiler is needed"), when an error message: + +arch/mips/Makefile:306: *** CONFIG_CPU_DADDI_WORKAROUNDS unsupported without -msym32. Stop. + +started to trigger for the `modules_install' target with configurations +such as `decstation_64_defconfig' that set CONFIG_CPU_DADDI_WORKAROUNDS, +because said commit has made `cc-option-yn' an undefined function for +non-build targets. + +Reported-by: Jan-Benedict Glaw +Signed-off-by: Maciej W. Rozycki +Fixes: 805b2e1d427a ("kbuild: include Makefile.compiler only when compiler is needed") +Cc: stable@vger.kernel.org # v5.13+ +Reviewed-by: Philippe Mathieu-Daudé +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/Makefile | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/mips/Makefile ++++ b/arch/mips/Makefile +@@ -308,8 +308,8 @@ ifdef CONFIG_64BIT + endif + endif + +- ifeq ($(KBUILD_SYM32)$(call cc-option-yn,-msym32), yy) +- cflags-y += -msym32 -DKBUILD_64BIT_SYM32 ++ ifeq ($(KBUILD_SYM32), y) ++ cflags-$(KBUILD_SYM32) += -msym32 -DKBUILD_64BIT_SYM32 + else + ifeq ($(CONFIG_CPU_DADDI_WORKAROUNDS), y) + $(error CONFIG_CPU_DADDI_WORKAROUNDS unsupported without -msym32) diff --git a/queue-6.1/mtd-rawnand-brcmnand-fix-crash-during-the-panic_write.patch b/queue-6.1/mtd-rawnand-brcmnand-fix-crash-during-the-panic_write.patch new file mode 100644 index 00000000000..95617b82a4e --- /dev/null +++ b/queue-6.1/mtd-rawnand-brcmnand-fix-crash-during-the-panic_write.patch @@ -0,0 +1,47 @@ +From e66dd317194daae0475fe9e5577c80aa97f16cb9 Mon Sep 17 00:00:00 2001 +From: William Zhang +Date: Thu, 6 Jul 2023 11:29:07 -0700 +Subject: mtd: rawnand: brcmnand: Fix crash during the panic_write + +From: William Zhang + +commit e66dd317194daae0475fe9e5577c80aa97f16cb9 upstream. + +When executing a NAND command within the panic write path, wait for any +pending command instead of calling BUG_ON to avoid crashing while +already crashing. + +Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") +Signed-off-by: William Zhang +Reviewed-by: Florian Fainelli +Reviewed-by: Kursad Oney +Reviewed-by: Kamal Dasu +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230706182909.79151-4-william.zhang@broadcom.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/brcmnand/brcmnand.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c ++++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c +@@ -1592,7 +1592,17 @@ static void brcmnand_send_cmd(struct brc + + dev_dbg(ctrl->dev, "send native cmd %d addr 0x%llx\n", cmd, cmd_addr); + +- BUG_ON(ctrl->cmd_pending != 0); ++ /* ++ * If we came here through _panic_write and there is a pending ++ * command, try to wait for it. If it times out, rather than ++ * hitting BUG_ON, just return so we don't crash while crashing. ++ */ ++ if (oops_in_progress) { ++ if (ctrl->cmd_pending && ++ bcmnand_ctrl_poll_status(ctrl, NAND_CTRL_RDY, NAND_CTRL_RDY, 0)) ++ return; ++ } else ++ BUG_ON(ctrl->cmd_pending != 0); + ctrl->cmd_pending = cmd; + + ret = bcmnand_ctrl_poll_status(ctrl, NAND_CTRL_RDY, NAND_CTRL_RDY, 0); diff --git a/queue-6.1/mtd-rawnand-brcmnand-fix-ecc-level-field-setting-for-v7.2-controller.patch b/queue-6.1/mtd-rawnand-brcmnand-fix-ecc-level-field-setting-for-v7.2-controller.patch new file mode 100644 index 00000000000..02aa35d2ee0 --- /dev/null +++ b/queue-6.1/mtd-rawnand-brcmnand-fix-ecc-level-field-setting-for-v7.2-controller.patch @@ -0,0 +1,155 @@ +From 2ec2839a9062db8a592525a3fdabd42dcd9a3a9b Mon Sep 17 00:00:00 2001 +From: William Zhang +Date: Thu, 6 Jul 2023 11:29:05 -0700 +Subject: mtd: rawnand: brcmnand: Fix ECC level field setting for v7.2 controller + +From: William Zhang + +commit 2ec2839a9062db8a592525a3fdabd42dcd9a3a9b upstream. + +v7.2 controller has different ECC level field size and shift in the acc +control register than its predecessor and successor controller. It needs +to be set specifically. + +Fixes: decba6d47869 ("mtd: brcmnand: Add v7.2 controller support") +Signed-off-by: William Zhang +Reviewed-by: Florian Fainelli +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230706182909.79151-2-william.zhang@broadcom.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/brcmnand/brcmnand.c | 74 +++++++++++++++++-------------- + 1 file changed, 41 insertions(+), 33 deletions(-) + +--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c ++++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c +@@ -272,6 +272,7 @@ struct brcmnand_controller { + const unsigned int *page_sizes; + unsigned int page_size_shift; + unsigned int max_oob; ++ u32 ecc_level_shift; + u32 features; + + /* for low-power standby/resume only */ +@@ -596,6 +597,34 @@ enum { + INTFC_CTLR_READY = BIT(31), + }; + ++/*********************************************************************** ++ * NAND ACC CONTROL bitfield ++ * ++ * Some bits have remained constant throughout hardware revision, while ++ * others have shifted around. ++ ***********************************************************************/ ++ ++/* Constant for all versions (where supported) */ ++enum { ++ /* See BRCMNAND_HAS_CACHE_MODE */ ++ ACC_CONTROL_CACHE_MODE = BIT(22), ++ ++ /* See BRCMNAND_HAS_PREFETCH */ ++ ACC_CONTROL_PREFETCH = BIT(23), ++ ++ ACC_CONTROL_PAGE_HIT = BIT(24), ++ ACC_CONTROL_WR_PREEMPT = BIT(25), ++ ACC_CONTROL_PARTIAL_PAGE = BIT(26), ++ ACC_CONTROL_RD_ERASED = BIT(27), ++ ACC_CONTROL_FAST_PGM_RDIN = BIT(28), ++ ACC_CONTROL_WR_ECC = BIT(30), ++ ACC_CONTROL_RD_ECC = BIT(31), ++}; ++ ++#define ACC_CONTROL_ECC_SHIFT 16 ++/* Only for v7.2 */ ++#define ACC_CONTROL_ECC_EXT_SHIFT 13 ++ + static inline bool brcmnand_non_mmio_ops(struct brcmnand_controller *ctrl) + { + #if IS_ENABLED(CONFIG_MTD_NAND_BRCMNAND_BCMA) +@@ -737,6 +766,12 @@ static int brcmnand_revision_init(struct + else if (of_property_read_bool(ctrl->dev->of_node, "brcm,nand-has-wp")) + ctrl->features |= BRCMNAND_HAS_WP; + ++ /* v7.2 has different ecc level shift in the acc register */ ++ if (ctrl->nand_version == 0x0702) ++ ctrl->ecc_level_shift = ACC_CONTROL_ECC_EXT_SHIFT; ++ else ++ ctrl->ecc_level_shift = ACC_CONTROL_ECC_SHIFT; ++ + return 0; + } + +@@ -931,30 +966,6 @@ static inline int brcmnand_cmd_shift(str + return 0; + } + +-/*********************************************************************** +- * NAND ACC CONTROL bitfield +- * +- * Some bits have remained constant throughout hardware revision, while +- * others have shifted around. +- ***********************************************************************/ +- +-/* Constant for all versions (where supported) */ +-enum { +- /* See BRCMNAND_HAS_CACHE_MODE */ +- ACC_CONTROL_CACHE_MODE = BIT(22), +- +- /* See BRCMNAND_HAS_PREFETCH */ +- ACC_CONTROL_PREFETCH = BIT(23), +- +- ACC_CONTROL_PAGE_HIT = BIT(24), +- ACC_CONTROL_WR_PREEMPT = BIT(25), +- ACC_CONTROL_PARTIAL_PAGE = BIT(26), +- ACC_CONTROL_RD_ERASED = BIT(27), +- ACC_CONTROL_FAST_PGM_RDIN = BIT(28), +- ACC_CONTROL_WR_ECC = BIT(30), +- ACC_CONTROL_RD_ECC = BIT(31), +-}; +- + static inline u32 brcmnand_spare_area_mask(struct brcmnand_controller *ctrl) + { + if (ctrl->nand_version == 0x0702) +@@ -967,18 +978,15 @@ static inline u32 brcmnand_spare_area_ma + return GENMASK(4, 0); + } + +-#define NAND_ACC_CONTROL_ECC_SHIFT 16 +-#define NAND_ACC_CONTROL_ECC_EXT_SHIFT 13 +- + static inline u32 brcmnand_ecc_level_mask(struct brcmnand_controller *ctrl) + { + u32 mask = (ctrl->nand_version >= 0x0600) ? 0x1f : 0x0f; + +- mask <<= NAND_ACC_CONTROL_ECC_SHIFT; ++ mask <<= ACC_CONTROL_ECC_SHIFT; + + /* v7.2 includes additional ECC levels */ +- if (ctrl->nand_version >= 0x0702) +- mask |= 0x7 << NAND_ACC_CONTROL_ECC_EXT_SHIFT; ++ if (ctrl->nand_version == 0x0702) ++ mask |= 0x7 << ACC_CONTROL_ECC_EXT_SHIFT; + + return mask; + } +@@ -992,8 +1000,8 @@ static void brcmnand_set_ecc_enabled(str + + if (en) { + acc_control |= ecc_flags; /* enable RD/WR ECC */ +- acc_control |= host->hwcfg.ecc_level +- << NAND_ACC_CONTROL_ECC_SHIFT; ++ acc_control &= ~brcmnand_ecc_level_mask(ctrl); ++ acc_control |= host->hwcfg.ecc_level << ctrl->ecc_level_shift; + } else { + acc_control &= ~ecc_flags; /* disable RD/WR ECC */ + acc_control &= ~brcmnand_ecc_level_mask(ctrl); +@@ -2593,7 +2601,7 @@ static int brcmnand_set_cfg(struct brcmn + tmp &= ~brcmnand_ecc_level_mask(ctrl); + tmp &= ~brcmnand_spare_area_mask(ctrl); + if (ctrl->nand_version >= 0x0302) { +- tmp |= cfg->ecc_level << NAND_ACC_CONTROL_ECC_SHIFT; ++ tmp |= cfg->ecc_level << ctrl->ecc_level_shift; + tmp |= cfg->spare_area_size; + } + nand_writereg(ctrl, acc_control_offs, tmp); diff --git a/queue-6.1/mtd-rawnand-brcmnand-fix-potential-false-time-out-warning.patch b/queue-6.1/mtd-rawnand-brcmnand-fix-potential-false-time-out-warning.patch new file mode 100644 index 00000000000..86cb9cb1784 --- /dev/null +++ b/queue-6.1/mtd-rawnand-brcmnand-fix-potential-false-time-out-warning.patch @@ -0,0 +1,42 @@ +From 9cc0a598b944816f2968baf2631757f22721b996 Mon Sep 17 00:00:00 2001 +From: William Zhang +Date: Thu, 6 Jul 2023 11:29:06 -0700 +Subject: mtd: rawnand: brcmnand: Fix potential false time out warning + +From: William Zhang + +commit 9cc0a598b944816f2968baf2631757f22721b996 upstream. + +If system is busy during the command status polling function, the driver +may not get the chance to poll the status register till the end of time +out and return the premature status. Do a final check after time out +happens to ensure reading the correct status. + +Fixes: 9d2ee0a60b8b ("mtd: nand: brcmnand: Check flash #WP pin status before nand erase/program") +Signed-off-by: William Zhang +Reviewed-by: Florian Fainelli +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230706182909.79151-3-william.zhang@broadcom.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/brcmnand/brcmnand.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c ++++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c +@@ -1072,6 +1072,14 @@ static int bcmnand_ctrl_poll_status(stru + cpu_relax(); + } while (time_after(limit, jiffies)); + ++ /* ++ * do a final check after time out in case the CPU was busy and the driver ++ * did not get enough time to perform the polling to avoid false alarms ++ */ ++ val = brcmnand_read_reg(ctrl, BRCMNAND_INTFC_STATUS); ++ if ((val & mask) == expected_val) ++ return 0; ++ + dev_warn(ctrl->dev, "timeout on status poll (expected %x got %x)\n", + expected_val, val & mask); + diff --git a/queue-6.1/mtd-rawnand-brcmnand-fix-potential-out-of-bounds-access-in-oob-write.patch b/queue-6.1/mtd-rawnand-brcmnand-fix-potential-out-of-bounds-access-in-oob-write.patch new file mode 100644 index 00000000000..540ce6aa671 --- /dev/null +++ b/queue-6.1/mtd-rawnand-brcmnand-fix-potential-out-of-bounds-access-in-oob-write.patch @@ -0,0 +1,64 @@ +From 5d53244186c9ac58cb88d76a0958ca55b83a15cd Mon Sep 17 00:00:00 2001 +From: William Zhang +Date: Thu, 6 Jul 2023 11:29:08 -0700 +Subject: mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write + +From: William Zhang + +commit 5d53244186c9ac58cb88d76a0958ca55b83a15cd upstream. + +When the oob buffer length is not in multiple of words, the oob write +function does out-of-bounds read on the oob source buffer at the last +iteration. Fix that by always checking length limit on the oob buffer +read and fill with 0xff when reaching the end of the buffer to the oob +registers. + +Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") +Signed-off-by: William Zhang +Reviewed-by: Florian Fainelli +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230706182909.79151-5-william.zhang@broadcom.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/brcmnand/brcmnand.c | 18 ++++++++++++++++-- + 1 file changed, 16 insertions(+), 2 deletions(-) + +--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c ++++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c +@@ -1461,19 +1461,33 @@ static int write_oob_to_regs(struct brcm + const u8 *oob, int sas, int sector_1k) + { + int tbytes = sas << sector_1k; +- int j; ++ int j, k = 0; ++ u32 last = 0xffffffff; ++ u8 *plast = (u8 *)&last; + + /* Adjust OOB values for 1K sector size */ + if (sector_1k && (i & 0x01)) + tbytes = max(0, tbytes - (int)ctrl->max_oob); + tbytes = min_t(int, tbytes, ctrl->max_oob); + +- for (j = 0; j < tbytes; j += 4) ++ /* ++ * tbytes may not be multiple of words. Make sure we don't read out of ++ * the boundary and stop at last word. ++ */ ++ for (j = 0; (j + 3) < tbytes; j += 4) + oob_reg_write(ctrl, j, + (oob[j + 0] << 24) | + (oob[j + 1] << 16) | + (oob[j + 2] << 8) | + (oob[j + 3] << 0)); ++ ++ /* handle the remaing bytes */ ++ while (j < tbytes) ++ plast[k++] = oob[j++]; ++ ++ if (tbytes & 0x3) ++ oob_reg_write(ctrl, (tbytes & ~0x3), (__force u32)cpu_to_be32(last)); ++ + return tbytes; + } + diff --git a/queue-6.1/mtd-spi-nor-correct-flags-for-winbond-w25q128.patch b/queue-6.1/mtd-spi-nor-correct-flags-for-winbond-w25q128.patch new file mode 100644 index 00000000000..66b984d2239 --- /dev/null +++ b/queue-6.1/mtd-spi-nor-correct-flags-for-winbond-w25q128.patch @@ -0,0 +1,89 @@ +From 83e824a4a595132f9bd7ac4f5afff857bfc5991e Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Tue, 18 Jul 2023 13:56:11 +0200 +Subject: mtd: spi-nor: Correct flags for Winbond w25q128 + +From: Linus Walleij + +commit 83e824a4a595132f9bd7ac4f5afff857bfc5991e upstream. + +The Winbond "w25q128" (actual vendor name W25Q128JV) has +exactly the same flags as the sibling device "w25q128jv". +The devices both require unlocking to enable write access. + +The actual product naming between devices vs the Linux +strings in winbond.c: + +0xef4018: "w25q128" W25Q128JV-IN/IQ/JQ +0xef7018: "w25q128jv" W25Q128JV-IM/JM + +The latter device, "w25q128jv" supports features named DTQ +and QPI, otherwise it is the same. + +Not having the right flags has the annoying side effect +that write access does not work. + +After this patch I can write to the flash on the Inteno +XG6846 router. + +The flash memory also supports dual and quad SPI modes. +This does not currently manifest, but by turning on SFDP +parsing, the right SPI modes are emitted in +/sys/kernel/debug/spi-nor/spi1.0/capabilities +for this chip, so we also turn on this. + +Since we now have determined that SFDP parsing works on +the device, we also detect the geometry using SFDP. + +After this dmesg and sysfs says: +[ 1.062401] spi-nor spi1.0: w25q128 (16384 Kbytes) +cat erasesize +65536 +(16384*1024)/65536 = 256 sectors + +spi-nor sysfs: +cat jedec_id +ef4018 +cat manufacturer +winbond +cat partname +w25q128 +hexdump -v -C sfdp +00000000 53 46 44 50 05 01 00 ff 00 05 01 10 80 00 00 ff +00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +00000030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +00000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +00000050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +00000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +00000070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff +00000080 e5 20 f9 ff ff ff ff 07 44 eb 08 6b 08 3b 42 bb +00000090 fe ff ff ff ff ff 00 00 ff ff 40 eb 0c 20 0f 52 +000000a0 10 d8 00 00 36 02 a6 00 82 ea 14 c9 e9 63 76 33 +000000b0 7a 75 7a 75 f7 a2 d5 5c 19 f7 4d ff e9 30 f8 80 + +Cc: stable@vger.kernel.org +Suggested-by: Michael Walle +Reviewed-by: Michael Walle +Signed-off-by: Linus Walleij +Link: https://lore.kernel.org/r/20230718-spi-nor-winbond-w25q128-v5-1-a73653ee46c3@linaro.org +Signed-off-by: Tudor Ambarus +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/spi-nor/winbond.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/mtd/spi-nor/winbond.c ++++ b/drivers/mtd/spi-nor/winbond.c +@@ -120,8 +120,9 @@ static const struct flash_info winbond_n + NO_SFDP_FLAGS(SECT_4K) }, + { "w25q80bl", INFO(0xef4014, 0, 64 * 1024, 16) + NO_SFDP_FLAGS(SECT_4K) }, +- { "w25q128", INFO(0xef4018, 0, 64 * 1024, 256) +- NO_SFDP_FLAGS(SECT_4K) }, ++ { "w25q128", INFO(0xef4018, 0, 0, 0) ++ PARSE_SFDP ++ FLAGS(SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB) }, + { "w25q256", INFO(0xef4019, 0, 64 * 1024, 512) + NO_SFDP_FLAGS(SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) + .fixups = &w25q256_fixups }, diff --git a/queue-6.1/perf-build-update-build-rule-for-generated-files.patch b/queue-6.1/perf-build-update-build-rule-for-generated-files.patch new file mode 100644 index 00000000000..21373c2e980 --- /dev/null +++ b/queue-6.1/perf-build-update-build-rule-for-generated-files.patch @@ -0,0 +1,80 @@ +From 7822a8913f4c51c7d1aff793b525d60c3384fb5b Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Thu, 27 Jul 2023 19:24:46 -0700 +Subject: perf build: Update build rule for generated files + +From: Namhyung Kim + +commit 7822a8913f4c51c7d1aff793b525d60c3384fb5b upstream. + +The bison and flex generate C files from the source (.y and .l) +files. When O= option is used, they are saved in a separate directory +but the default build rule assumes the .C files are in the source +directory. So it might read invalid file if there are generated files +from an old version. The same is true for the pmu-events files. + +For example, the following command would cause a build failure: + + $ git checkout v6.3 + $ make -C tools/perf # build in the same directory + + $ git checkout v6.5-rc2 + $ mkdir build # create a build directory + $ make -C tools/perf O=build # build in a different directory but it + # refers files in the source directory + +Let's update the build rule to specify those cases explicitly to depend +on the files in the output directory. + +Note that it's not a complete fix and it needs the next patch for the +include path too. + +Fixes: 80eeb67fe577aa76 ("perf jevents: Program to convert JSON file") +Signed-off-by: Namhyung Kim +Cc: Adrian Hunter +Cc: Andi Kleen +Cc: Anup Sharma +Cc: Ian Rogers +Cc: Ingo Molnar +Cc: Jiri Olsa +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230728022447.1323563-1-namhyung@kernel.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/build/Makefile.build | 10 ++++++++++ + tools/perf/pmu-events/Build | 6 ++++++ + 2 files changed, 16 insertions(+) + +--- a/tools/build/Makefile.build ++++ b/tools/build/Makefile.build +@@ -116,6 +116,16 @@ $(OUTPUT)%.s: %.c FORCE + $(call rule_mkdir) + $(call if_changed_dep,cc_s_c) + ++# bison and flex files are generated in the OUTPUT directory ++# so it needs a separate rule to depend on them properly ++$(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE ++ $(call rule_mkdir) ++ $(call if_changed_dep,$(host)cc_o_c) ++ ++$(OUTPUT)%-flex.o: $(OUTPUT)%-flex.c FORCE ++ $(call rule_mkdir) ++ $(call if_changed_dep,$(host)cc_o_c) ++ + # Gather build data: + # obj-y - list of build objects + # subdir-y - list of directories to nest +--- a/tools/perf/pmu-events/Build ++++ b/tools/perf/pmu-events/Build +@@ -25,3 +25,9 @@ $(OUTPUT)pmu-events/pmu-events.c: $(JSON + $(call rule_mkdir) + $(Q)$(call echo-cmd,gen)$(PYTHON) $(JEVENTS_PY) $(JEVENTS_ARCH) pmu-events/arch $@ + endif ++ ++# pmu-events.c file is generated in the OUTPUT directory so it needs a ++# separate rule to depend on it properly ++$(OUTPUT)pmu-events/pmu-events.o: $(PMU_EVENTS_C) ++ $(call rule_mkdir) ++ $(call if_changed_dep,cc_o_c) diff --git a/queue-6.1/perf-hists-browser-fix-hierarchy-mode-header.patch b/queue-6.1/perf-hists-browser-fix-hierarchy-mode-header.patch new file mode 100644 index 00000000000..429a228d022 --- /dev/null +++ b/queue-6.1/perf-hists-browser-fix-hierarchy-mode-header.patch @@ -0,0 +1,43 @@ +From e2cabf2a44791f01c21f8d5189b946926e34142e Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Mon, 31 Jul 2023 02:49:32 -0700 +Subject: perf hists browser: Fix hierarchy mode header + +From: Namhyung Kim + +commit e2cabf2a44791f01c21f8d5189b946926e34142e upstream. + +The commit ef9ff6017e3c4593 ("perf ui browser: Move the extra title +lines from the hists browser") introduced ui_browser__gotorc_title() to +help moving non-title lines easily. But it missed to update the title +for the hierarchy mode so it won't print the header line on TUI at all. + + $ perf report --hierarchy + +Fixes: ef9ff6017e3c4593 ("perf ui browser: Move the extra title lines from the hists browser") +Signed-off-by: Namhyung Kim +Tested-by: Arnaldo Carvalho de Melo +Cc: Adrian Hunter +Cc: Ian Rogers +Cc: Ingo Molnar +Cc: Jiri Olsa +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230731094934.1616495-1-namhyung@kernel.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/ui/browsers/hists.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/perf/ui/browsers/hists.c ++++ b/tools/perf/ui/browsers/hists.c +@@ -1779,7 +1779,7 @@ static void hists_browser__hierarchy_hea + hists_browser__scnprintf_hierarchy_headers(browser, headers, + sizeof(headers)); + +- ui_browser__gotorc(&browser->b, 0, 0); ++ ui_browser__gotorc_title(&browser->b, 0, 0); + ui_browser__set_color(&browser->b, HE_COLORSET_ROOT); + ui_browser__write_nstring(&browser->b, headers, browser->b.width + 1); + } diff --git a/queue-6.1/perf-hists-browser-fix-the-number-of-entries-for-e-key.patch b/queue-6.1/perf-hists-browser-fix-the-number-of-entries-for-e-key.patch new file mode 100644 index 00000000000..07b764b25fa --- /dev/null +++ b/queue-6.1/perf-hists-browser-fix-the-number-of-entries-for-e-key.patch @@ -0,0 +1,150 @@ +From f6b8436bede3e80226e8b2100279c4450c73806a Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Mon, 31 Jul 2023 02:49:33 -0700 +Subject: perf hists browser: Fix the number of entries for 'e' key + +From: Namhyung Kim + +commit f6b8436bede3e80226e8b2100279c4450c73806a upstream. + +The 'e' key is to toggle expand/collapse the selected entry only. But +the current code has a bug that it only increases the number of entries +by 1 in the hierarchy mode so users cannot move under the current entry +after the key stroke. This is due to a wrong assumption in the +hist_entry__set_folding(). + +The commit b33f922651011eff ("perf hists browser: Put hist_entry folding +logic into single function") factored out the code, but actually it +should be handled separately. The hist_browser__set_folding() is to +update fold state for each entry so it needs to traverse all (child) +entries regardless of the current fold state. So it increases the +number of entries by 1. + +But the hist_entry__set_folding() only cares the currently selected +entry and its all children. So it should count all unfolded child +entries. This code is implemented in hist_browser__toggle_fold() +already so we can just call it. + +Fixes: b33f922651011eff ("perf hists browser: Put hist_entry folding logic into single function") +Signed-off-by: Namhyung Kim +Tested-by: Arnaldo Carvalho de Melo +Cc: Adrian Hunter +Cc: Ian Rogers +Cc: Ingo Molnar +Cc: Jiri Olsa +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230731094934.1616495-2-namhyung@kernel.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/ui/browsers/hists.c | 58 ++++++++++++++++------------------------- + 1 file changed, 24 insertions(+), 34 deletions(-) + +--- a/tools/perf/ui/browsers/hists.c ++++ b/tools/perf/ui/browsers/hists.c +@@ -407,11 +407,6 @@ static bool hist_browser__selection_has_ + return container_of(ms, struct callchain_list, ms)->has_children; + } + +-static bool hist_browser__he_selection_unfolded(struct hist_browser *browser) +-{ +- return browser->he_selection ? browser->he_selection->unfolded : false; +-} +- + static bool hist_browser__selection_unfolded(struct hist_browser *browser) + { + struct hist_entry *he = browser->he_selection; +@@ -584,8 +579,8 @@ static int hierarchy_set_folding(struct + return n; + } + +-static void __hist_entry__set_folding(struct hist_entry *he, +- struct hist_browser *hb, bool unfold) ++static void hist_entry__set_folding(struct hist_entry *he, ++ struct hist_browser *hb, bool unfold) + { + hist_entry__init_have_children(he); + he->unfolded = unfold ? he->has_children : false; +@@ -603,34 +598,12 @@ static void __hist_entry__set_folding(st + he->nr_rows = 0; + } + +-static void hist_entry__set_folding(struct hist_entry *he, +- struct hist_browser *browser, bool unfold) +-{ +- double percent; +- +- percent = hist_entry__get_percent_limit(he); +- if (he->filtered || percent < browser->min_pcnt) +- return; +- +- __hist_entry__set_folding(he, browser, unfold); +- +- if (!he->depth || unfold) +- browser->nr_hierarchy_entries++; +- if (he->leaf) +- browser->nr_callchain_rows += he->nr_rows; +- else if (unfold && !hist_entry__has_hierarchy_children(he, browser->min_pcnt)) { +- browser->nr_hierarchy_entries++; +- he->has_no_entry = true; +- he->nr_rows = 1; +- } else +- he->has_no_entry = false; +-} +- + static void + __hist_browser__set_folding(struct hist_browser *browser, bool unfold) + { + struct rb_node *nd; + struct hist_entry *he; ++ double percent; + + nd = rb_first_cached(&browser->hists->entries); + while (nd) { +@@ -640,6 +613,21 @@ __hist_browser__set_folding(struct hist_ + nd = __rb_hierarchy_next(nd, HMD_FORCE_CHILD); + + hist_entry__set_folding(he, browser, unfold); ++ ++ percent = hist_entry__get_percent_limit(he); ++ if (he->filtered || percent < browser->min_pcnt) ++ continue; ++ ++ if (!he->depth || unfold) ++ browser->nr_hierarchy_entries++; ++ if (he->leaf) ++ browser->nr_callchain_rows += he->nr_rows; ++ else if (unfold && !hist_entry__has_hierarchy_children(he, browser->min_pcnt)) { ++ browser->nr_hierarchy_entries++; ++ he->has_no_entry = true; ++ he->nr_rows = 1; ++ } else ++ he->has_no_entry = false; + } + } + +@@ -659,8 +647,10 @@ static void hist_browser__set_folding_se + if (!browser->he_selection) + return; + +- hist_entry__set_folding(browser->he_selection, browser, unfold); +- browser->b.nr_entries = hist_browser__nr_entries(browser); ++ if (unfold == browser->he_selection->unfolded) ++ return; ++ ++ hist_browser__toggle_fold(browser); + } + + static void ui_browser__warn_lost_events(struct ui_browser *browser) +@@ -732,8 +722,8 @@ static int hist_browser__handle_hotkey(s + hist_browser__set_folding(browser, true); + break; + case 'e': +- /* Expand the selected entry. */ +- hist_browser__set_folding_selected(browser, !hist_browser__he_selection_unfolded(browser)); ++ /* Toggle expand/collapse the selected entry. */ ++ hist_browser__toggle_fold(browser); + break; + case 'H': + browser->show_headers = !browser->show_headers; diff --git a/queue-6.1/perf-test-shell-stat_bpf_counters-fix-test-on-intel.patch b/queue-6.1/perf-test-shell-stat_bpf_counters-fix-test-on-intel.patch new file mode 100644 index 00000000000..f4fac1c3f63 --- /dev/null +++ b/queue-6.1/perf-test-shell-stat_bpf_counters-fix-test-on-intel.patch @@ -0,0 +1,51 @@ +From 68ca249c964f520af7f8763e22f12bd26b57b870 Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Fri, 25 Aug 2023 09:41:51 -0700 +Subject: perf test shell stat_bpf_counters: Fix test on Intel + +From: Namhyung Kim + +commit 68ca249c964f520af7f8763e22f12bd26b57b870 upstream. + +As of now, bpf counters (bperf) don't support event groups. But the +default perf stat includes topdown metrics if supported (on recent Intel +machines) which require groups. That makes perf stat exiting. + + $ sudo perf stat --bpf-counter true + bpf managed perf events do not yet support groups. + +Actually the test explicitly uses cycles event only, but it missed to +pass the option when it checks the availability of the command. + +Fixes: 2c0cb9f56020d2ea ("perf test: Add a shell test for 'perf stat --bpf-counters' new option") +Reviewed-by: Song Liu +Signed-off-by: Namhyung Kim +Cc: Adrian Hunter +Cc: Ian Rogers +Cc: Ingo Molnar +Cc: Jiri Olsa +Cc: Peter Zijlstra +Cc: bpf@vger.kernel.org +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230825164152.165610-2-namhyung@kernel.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/tests/shell/stat_bpf_counters.sh | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/tools/perf/tests/shell/stat_bpf_counters.sh ++++ b/tools/perf/tests/shell/stat_bpf_counters.sh +@@ -22,10 +22,10 @@ compare_number() + } + + # skip if --bpf-counters is not supported +-if ! perf stat --bpf-counters true > /dev/null 2>&1; then ++if ! perf stat -e cycles --bpf-counters true > /dev/null 2>&1; then + if [ "$1" = "-v" ]; then + echo "Skipping: --bpf-counters not supported" +- perf --no-pager stat --bpf-counters true || true ++ perf --no-pager stat -e cycles --bpf-counters true || true + fi + exit 2 + fi diff --git a/queue-6.1/perf-tools-handle-old-data-in-perf_record_attr.patch b/queue-6.1/perf-tools-handle-old-data-in-perf_record_attr.patch new file mode 100644 index 00000000000..7ceeeaf6415 --- /dev/null +++ b/queue-6.1/perf-tools-handle-old-data-in-perf_record_attr.patch @@ -0,0 +1,90 @@ +From 9bf63282ea77a531ea58acb42fb3f40d2d1e4497 Mon Sep 17 00:00:00 2001 +From: Namhyung Kim +Date: Fri, 25 Aug 2023 08:25:49 -0700 +Subject: perf tools: Handle old data in PERF_RECORD_ATTR + +From: Namhyung Kim + +commit 9bf63282ea77a531ea58acb42fb3f40d2d1e4497 upstream. + +The PERF_RECORD_ATTR is used for a pipe mode to describe an event with +attribute and IDs. The ID table comes after the attr and it calculate +size of the table using the total record size and the attr size. + + n_ids = (total_record_size - end_of_the_attr_field) / sizeof(u64) + +This is fine for most use cases, but sometimes it saves the pipe output +in a file and then process it later. And it becomes a problem if there +is a change in attr size between the record and report. + + $ perf record -o- > perf-pipe.data # old version + $ perf report -i- < perf-pipe.data # new version + +For example, if the attr size is 128 and it has 4 IDs, then it would +save them in 168 byte like below: + + 8 byte: perf event header { .type = PERF_RECORD_ATTR, .size = 168 }, + 128 byte: perf event attr { .size = 128, ... }, + 32 byte: event IDs [] = { 1234, 1235, 1236, 1237 }, + +But when report later, it thinks the attr size is 136 then it only read +the last 3 entries as ID. + + 8 byte: perf event header { .type = PERF_RECORD_ATTR, .size = 168 }, + 136 byte: perf event attr { .size = 136, ... }, + 24 byte: event IDs [] = { 1235, 1236, 1237 }, // 1234 is missing + +So it should use the recorded version of the attr. The attr has the +size field already then it should honor the size when reading data. + +Fixes: 2c46dbb517a10b18 ("perf: Convert perf header attrs into attr events") +Signed-off-by: Namhyung Kim +Cc: Adrian Hunter +Cc: Ian Rogers +Cc: Ingo Molnar +Cc: Jiri Olsa +Cc: Peter Zijlstra +Cc: Tom Zanussi +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230825152552.112913-1-namhyung@kernel.org +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman +--- + tools/perf/util/header.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/tools/perf/util/header.c ++++ b/tools/perf/util/header.c +@@ -4331,7 +4331,8 @@ int perf_event__process_attr(struct perf + union perf_event *event, + struct evlist **pevlist) + { +- u32 i, ids, n_ids; ++ u32 i, n_ids; ++ u64 *ids; + struct evsel *evsel; + struct evlist *evlist = *pevlist; + +@@ -4347,9 +4348,8 @@ int perf_event__process_attr(struct perf + + evlist__add(evlist, evsel); + +- ids = event->header.size; +- ids -= (void *)&event->attr.id - (void *)event; +- n_ids = ids / sizeof(u64); ++ n_ids = event->header.size - sizeof(event->header) - event->attr.attr.size; ++ n_ids = n_ids / sizeof(u64); + /* + * We don't have the cpu and thread maps on the header, so + * for allocating the perf_sample_id table we fake 1 cpu and +@@ -4358,8 +4358,9 @@ int perf_event__process_attr(struct perf + if (perf_evsel__alloc_id(&evsel->core, 1, n_ids)) + return -ENOMEM; + ++ ids = (void *)&event->attr.attr + event->attr.attr.size; + for (i = 0; i < n_ids; i++) { +- perf_evlist__id_add(&evlist->core, &evsel->core, 0, i, event->attr.id[i]); ++ perf_evlist__id_add(&evlist->core, &evsel->core, 0, i, ids[i]); + } + + return 0; diff --git a/queue-6.1/series b/queue-6.1/series index fc96d404277..1ec5f7ebefe 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -156,3 +156,31 @@ btrfs-zoned-do-not-zone-finish-data-relocation-block-group.patch btrfs-fix-start-transaction-qgroup-rsv-double-free.patch btrfs-free-qgroup-rsv-on-io-failure.patch btrfs-don-t-start-transaction-when-joining-with-trans_join_nostart.patch +btrfs-set-page-extent-mapped-after-read_folio-in-relocate_one_page.patch +btrfs-zoned-re-enable-metadata-over-commit-for-zoned-mode.patch +btrfs-use-the-correct-superblock-to-compare-fsid-in-btrfs_validate_super.patch +btrfs-compare-the-correct-fsid-metadata_uuid-in-btrfs_validate_super.patch +drm-mxsfb-disable-overlay-plane-in-mxsfb_plane_overlay_atomic_disable.patch +mtd-rawnand-brcmnand-fix-crash-during-the-panic_write.patch +mtd-rawnand-brcmnand-fix-potential-out-of-bounds-access-in-oob-write.patch +mtd-spi-nor-correct-flags-for-winbond-w25q128.patch +mtd-rawnand-brcmnand-fix-potential-false-time-out-warning.patch +mtd-rawnand-brcmnand-fix-ecc-level-field-setting-for-v7.2-controller.patch +drm-amd-display-enable-cursor-degamma-for-dcn3-drm-legacy-gamma.patch +drm-amd-display-prevent-potential-division-by-zero-errors.patch +kvm-svm-take-and-hold-ir_list_lock-when-updating-vcpu-s-physical-id-entry.patch +kvm-svm-don-t-inject-ud-if-kvm-attempts-to-skip-sev-guest-insn.patch +kvm-svm-get-source-vcpus-from-source-vm-for-sev-es-intrahost-migration.patch +kvm-nsvm-check-instead-of-asserting-on-nested-tsc-scaling-support.patch +kvm-nsvm-load-l1-s-tsc-multiplier-based-on-l1-state-not-l2-state.patch +kvm-svm-set-target-pcpu-during-irte-update-if-target-vcpu-is-running.patch +kvm-svm-skip-vmsa-init-in-sev_es_init_vmcb-if-pointer-is-null.patch +mips-fix-config_cpu_daddi_workarounds-modules_install-regression.patch +perf-hists-browser-fix-hierarchy-mode-header.patch +perf-build-update-build-rule-for-generated-files.patch +perf-test-shell-stat_bpf_counters-fix-test-on-intel.patch +perf-tools-handle-old-data-in-perf_record_attr.patch +perf-hists-browser-fix-the-number-of-entries-for-e-key.patch +drm-amd-display-always-switch-off-odm-before-committing-more-streams.patch +drm-amd-display-remove-wait-while-locked.patch +drm-amdgpu-register-a-dirty-framebuffer-callback-for-fbcon.patch