From: Greg Kroah-Hartman Date: Tue, 7 Jul 2020 13:47:45 +0000 (+0200) Subject: 5.7-stable patches X-Git-Tag: v4.4.230~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f96d254591839c5fd52aad7f7a0d4eb5a644932f;p=thirdparty%2Fkernel%2Fstable-queue.git 5.7-stable patches added patches: acpi-fan-fix-tiger-lake-acpi-device-id.patch cifs-fix-the-target-file-was-deleted-when-rename-failed.patch dma-buf-move-dma_buf_release-from-fops-to-dentry_ops.patch drivers-hv-change-flag-to-write-log-level-in-panic-msg-to-false.patch drm-amd-display-only-revalidate-bandwidth-on-medium-and-fast-updates.patch drm-amd-powerplay-fix-null-dereference-in-lock_bus-on-vega20-w-o-ras.patch drm-amdgpu-atomfirmware-fix-vram_info-fetching-for-renoir.patch drm-amdgpu-use-u-rather-than-d-for-sclk-mclk.patch drm-i915-include-asm-sources-for-ivb-hsw-_clear_kernel.c.patch gfs2-fix-trans-slab-error-when-withdraw-occurs-inside-log_flush.patch hwmon-pmbus-fix-page-vs.-register-when-accessing-fans.patch irqchip-gic-atomically-update-affinity.patch mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch mips-lantiq-xway-sysctrl-fix-the-gphy-clock-alias-names.patch mm-cma.c-use-exact_nid-true-to-fix-possible-per-numa-cma-leak.patch mm-hugetlb.c-fix-pages-per-hugetlb-calculation.patch padata-upgrade-smp_mb__after_atomic-to-smp_mb-in-padata_do_serial.patch smb3-honor-handletimeout-flag-for-multiuser-mounts.patch smb3-honor-lease-disabling-for-multiuser-mounts.patch smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch smb3-honor-seal-flag-for-multiuser-mounts.patch thermal-drivers-cpufreq_cooling-fix-wrong-frequency-converted-from-power.patch x86-split_lock-don-t-write-msr_test_ctrl-on-cpus-that-aren-t-whitelisted.patch --- diff --git a/queue-5.7/acpi-fan-fix-tiger-lake-acpi-device-id.patch b/queue-5.7/acpi-fan-fix-tiger-lake-acpi-device-id.patch new file mode 100644 index 00000000000..76fe7b0dca5 --- /dev/null +++ b/queue-5.7/acpi-fan-fix-tiger-lake-acpi-device-id.patch @@ -0,0 +1,35 @@ +From 0318e8374e87b32def1d5c279013ca7730a74982 Mon Sep 17 00:00:00 2001 +From: Sumeet Pawnikar +Date: Tue, 30 Jun 2020 21:11:49 +0530 +Subject: ACPI: fan: Fix Tiger Lake ACPI device ID + +From: Sumeet Pawnikar + +commit 0318e8374e87b32def1d5c279013ca7730a74982 upstream. + +Tiger Lake's new unique ACPI device ID for Fan is not valid +because of missing 'C' in the ID. Use correct fan device ID. + +Fixes: c248dfe7e0ca ("ACPI: fan: Add Tiger Lake ACPI device ID") +Signed-off-by: Sumeet Pawnikar +Cc: 5.6+ # 5.6+ +[ rjw: Subject and changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/fan.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/acpi/fan.c ++++ b/drivers/acpi/fan.c +@@ -25,8 +25,8 @@ static int acpi_fan_remove(struct platfo + + static const struct acpi_device_id fan_device_ids[] = { + {"PNP0C0B", 0}, +- {"INT1044", 0}, + {"INT3404", 0}, ++ {"INTC1044", 0}, + {"", 0}, + }; + MODULE_DEVICE_TABLE(acpi, fan_device_ids); diff --git a/queue-5.7/cifs-fix-the-target-file-was-deleted-when-rename-failed.patch b/queue-5.7/cifs-fix-the-target-file-was-deleted-when-rename-failed.patch new file mode 100644 index 00000000000..fd88553be72 --- /dev/null +++ b/queue-5.7/cifs-fix-the-target-file-was-deleted-when-rename-failed.patch @@ -0,0 +1,56 @@ +From 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 Mon Sep 17 00:00:00 2001 +From: Zhang Xiaoxu +Date: Sun, 28 Jun 2020 21:06:38 -0400 +Subject: cifs: Fix the target file was deleted when rename failed. + +From: Zhang Xiaoxu + +commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 upstream. + +When xfstest generic/035, we found the target file was deleted +if the rename return -EACESS. + +In cifs_rename2, we unlink the positive target dentry if rename +failed with EACESS or EEXIST, even if the target dentry is positived +before rename. Then the existing file was deleted. + +We should just delete the target file which created during the +rename. + +Reported-by: Hulk Robot +Signed-off-by: Zhang Xiaoxu +Cc: stable@vger.kernel.org +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/inode.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/fs/cifs/inode.c ++++ b/fs/cifs/inode.c +@@ -1855,6 +1855,7 @@ cifs_rename2(struct inode *source_dir, s + FILE_UNIX_BASIC_INFO *info_buf_target; + unsigned int xid; + int rc, tmprc; ++ bool new_target = d_really_is_negative(target_dentry); + + if (flags & ~RENAME_NOREPLACE) + return -EINVAL; +@@ -1931,8 +1932,13 @@ cifs_rename2(struct inode *source_dir, s + */ + + unlink_target: +- /* Try unlinking the target dentry if it's not negative */ +- if (d_really_is_positive(target_dentry) && (rc == -EACCES || rc == -EEXIST)) { ++ /* ++ * If the target dentry was created during the rename, try ++ * unlinking it if it's not negative ++ */ ++ if (new_target && ++ d_really_is_positive(target_dentry) && ++ (rc == -EACCES || rc == -EEXIST)) { + if (d_is_dir(target_dentry)) + tmprc = cifs_rmdir(target_dir, target_dentry); + else diff --git a/queue-5.7/dma-buf-move-dma_buf_release-from-fops-to-dentry_ops.patch b/queue-5.7/dma-buf-move-dma_buf_release-from-fops-to-dentry_ops.patch new file mode 100644 index 00000000000..64b37abb22a --- /dev/null +++ b/queue-5.7/dma-buf-move-dma_buf_release-from-fops-to-dentry_ops.patch @@ -0,0 +1,135 @@ +From 4ab59c3c638c6c8952bf07739805d20eb6358a4d Mon Sep 17 00:00:00 2001 +From: Sumit Semwal +Date: Thu, 11 Jun 2020 17:14:18 +0530 +Subject: dma-buf: Move dma_buf_release() from fops to dentry_ops + +From: Sumit Semwal + +commit 4ab59c3c638c6c8952bf07739805d20eb6358a4d upstream. + +Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which +happens if the dma_buf_release() is called while the userspace is +accessing the dma_buf pseudo fs's dmabuffs_dname() in another process, +and dma_buf_release() releases the dmabuf object when the last reference +to the struct file goes away. + +I discussed with Arnd Bergmann, and he suggested that rather than tying +the dma_buf_release() to the file_operations' release(), we can tie it to +the dentry_operations' d_release(), which will be called when the last ref +to the dentry is removed. + +The path exercised by __fput() calls f_op->release() first, and then calls +dput, which eventually calls d_op->d_release(). + +In the 'normal' case, when no userspace access is happening via dma_buf +pseudo fs, there should be exactly one fd, file, dentry and inode, so +closing the fd will kill of everything right away. + +In the presented case, the dentry's d_release() will be called only when +the dentry's last ref is released. + +Therefore, lets move dma_buf_release() from fops->release() to +d_ops->d_release() + +Many thanks to Arnd for his FS insights :) + +[1]: https://lore.kernel.org/patchwork/patch/1238278/ + +Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") +Reported-by: syzbot+3643a18836bce555bff6@syzkaller.appspotmail.com +Cc: [5.3+] +Cc: Arnd Bergmann +Reported-by: Charan Teja Reddy +Reviewed-by: Arnd Bergmann +Signed-off-by: Sumit Semwal +Tested-by: Charan Teja Reddy +Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma-buf/dma-buf.c | 54 +++++++++++++++++++++------------------------- + 1 file changed, 25 insertions(+), 29 deletions(-) + +--- a/drivers/dma-buf/dma-buf.c ++++ b/drivers/dma-buf/dma-buf.c +@@ -54,37 +54,11 @@ static char *dmabuffs_dname(struct dentr + dentry->d_name.name, ret > 0 ? name : ""); + } + +-static const struct dentry_operations dma_buf_dentry_ops = { +- .d_dname = dmabuffs_dname, +-}; +- +-static struct vfsmount *dma_buf_mnt; +- +-static int dma_buf_fs_init_context(struct fs_context *fc) +-{ +- struct pseudo_fs_context *ctx; +- +- ctx = init_pseudo(fc, DMA_BUF_MAGIC); +- if (!ctx) +- return -ENOMEM; +- ctx->dops = &dma_buf_dentry_ops; +- return 0; +-} +- +-static struct file_system_type dma_buf_fs_type = { +- .name = "dmabuf", +- .init_fs_context = dma_buf_fs_init_context, +- .kill_sb = kill_anon_super, +-}; +- +-static int dma_buf_release(struct inode *inode, struct file *file) ++static void dma_buf_release(struct dentry *dentry) + { + struct dma_buf *dmabuf; + +- if (!is_dma_buf_file(file)) +- return -EINVAL; +- +- dmabuf = file->private_data; ++ dmabuf = dentry->d_fsdata; + + BUG_ON(dmabuf->vmapping_counter); + +@@ -110,9 +84,32 @@ static int dma_buf_release(struct inode + module_put(dmabuf->owner); + kfree(dmabuf->name); + kfree(dmabuf); ++} ++ ++static const struct dentry_operations dma_buf_dentry_ops = { ++ .d_dname = dmabuffs_dname, ++ .d_release = dma_buf_release, ++}; ++ ++static struct vfsmount *dma_buf_mnt; ++ ++static int dma_buf_fs_init_context(struct fs_context *fc) ++{ ++ struct pseudo_fs_context *ctx; ++ ++ ctx = init_pseudo(fc, DMA_BUF_MAGIC); ++ if (!ctx) ++ return -ENOMEM; ++ ctx->dops = &dma_buf_dentry_ops; + return 0; + } + ++static struct file_system_type dma_buf_fs_type = { ++ .name = "dmabuf", ++ .init_fs_context = dma_buf_fs_init_context, ++ .kill_sb = kill_anon_super, ++}; ++ + static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) + { + struct dma_buf *dmabuf; +@@ -412,7 +409,6 @@ static void dma_buf_show_fdinfo(struct s + } + + static const struct file_operations dma_buf_fops = { +- .release = dma_buf_release, + .mmap = dma_buf_mmap_internal, + .llseek = dma_buf_llseek, + .poll = dma_buf_poll, diff --git a/queue-5.7/drivers-hv-change-flag-to-write-log-level-in-panic-msg-to-false.patch b/queue-5.7/drivers-hv-change-flag-to-write-log-level-in-panic-msg-to-false.patch new file mode 100644 index 00000000000..4126015509d --- /dev/null +++ b/queue-5.7/drivers-hv-change-flag-to-write-log-level-in-panic-msg-to-false.patch @@ -0,0 +1,41 @@ +From 77b48bea2fee47c15a835f6725dd8df0bc38375a Mon Sep 17 00:00:00 2001 +From: Joseph Salisbury +Date: Fri, 26 Jun 2020 15:28:17 -0700 +Subject: Drivers: hv: Change flag to write log level in panic msg to false + +From: Joseph Salisbury + +commit 77b48bea2fee47c15a835f6725dd8df0bc38375a upstream. + +When the kernel panics, one page of kmsg data may be collected and sent to +Hyper-V to aid in diagnosing the failure. The collected kmsg data typically + contains 50 to 100 lines, each of which has a log level prefix that isn't +very useful from a diagnostic standpoint. So tell kmsg_dump_get_buffer() +to not include the log level, enabling more information that *is* useful to +fit in the page. + +Requesting in stable kernels, since many kernels running in production are +stable releases. + +Cc: stable@vger.kernel.org +Signed-off-by: Joseph Salisbury +Reviewed-by: Michael Kelley +Link: https://lore.kernel.org/r/1593210497-114310-1-git-send-email-joseph.salisbury@microsoft.com +Signed-off-by: Wei Liu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hv/vmbus_drv.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/hv/vmbus_drv.c ++++ b/drivers/hv/vmbus_drv.c +@@ -1328,7 +1328,7 @@ static void hv_kmsg_dump(struct kmsg_dum + * Write dump contents to the page. No need to synchronize; panic should + * be single-threaded. + */ +- kmsg_dump_get_buffer(dumper, true, hv_panic_page, HV_HYP_PAGE_SIZE, ++ kmsg_dump_get_buffer(dumper, false, hv_panic_page, HV_HYP_PAGE_SIZE, + &bytes_written); + if (bytes_written) + hyperv_report_panic_msg(panic_pa, bytes_written); diff --git a/queue-5.7/drm-amd-display-only-revalidate-bandwidth-on-medium-and-fast-updates.patch b/queue-5.7/drm-amd-display-only-revalidate-bandwidth-on-medium-and-fast-updates.patch new file mode 100644 index 00000000000..d05ce32199c --- /dev/null +++ b/queue-5.7/drm-amd-display-only-revalidate-bandwidth-on-medium-and-fast-updates.patch @@ -0,0 +1,54 @@ +From 6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 Mon Sep 17 00:00:00 2001 +From: Nicholas Kazlauskas +Date: Mon, 29 Jun 2020 13:03:52 -0400 +Subject: drm/amd/display: Only revalidate bandwidth on medium and fast updates + +From: Nicholas Kazlauskas + +commit 6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 upstream. + +[Why] +Changes that are fast don't require updating DLG parameters making +this call unnecessary. Considering this is an expensive call it should +not be done on every flip. + +DML touches clocks, p-state support, DLG params and a few other DC +internal flags and these aren't expected during fast. A hang has been +reported with this change when called on every flip which suggests that +modifying these fields is not recommended behavior on fast updates. + +[How] +Guard the validation to only happen if update type isn't FAST. + +Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1191 +Fixes: a24eaa5c51255b ("drm/amd/display: Revalidate bandwidth before commiting DC updates") +Signed-off-by: Nicholas Kazlauskas +Acked-by: Alex Deucher +Reviewed-by: Roman Li +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/display/dc/core/dc.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc.c +@@ -2533,10 +2533,12 @@ void dc_commit_updates_for_stream(struct + + copy_stream_update_to_stream(dc, context, stream, stream_update); + +- if (!dc->res_pool->funcs->validate_bandwidth(dc, context, false)) { +- DC_ERROR("Mode validation failed for stream update!\n"); +- dc_release_state(context); +- return; ++ if (update_type > UPDATE_TYPE_FAST) { ++ if (!dc->res_pool->funcs->validate_bandwidth(dc, context, false)) { ++ DC_ERROR("Mode validation failed for stream update!\n"); ++ dc_release_state(context); ++ return; ++ } + } + + commit_planes_for_stream( diff --git a/queue-5.7/drm-amd-powerplay-fix-null-dereference-in-lock_bus-on-vega20-w-o-ras.patch b/queue-5.7/drm-amd-powerplay-fix-null-dereference-in-lock_bus-on-vega20-w-o-ras.patch new file mode 100644 index 00000000000..5f82db4e5bd --- /dev/null +++ b/queue-5.7/drm-amd-powerplay-fix-null-dereference-in-lock_bus-on-vega20-w-o-ras.patch @@ -0,0 +1,109 @@ +From 7e89e4aaa9ae83107d059c186955484b3aa6eb23 Mon Sep 17 00:00:00 2001 +From: Ivan Mironov +Date: Thu, 25 Jun 2020 21:50:42 +0500 +Subject: drm/amd/powerplay: Fix NULL dereference in lock_bus() on Vega20 w/o RAS + +From: Ivan Mironov + +commit 7e89e4aaa9ae83107d059c186955484b3aa6eb23 upstream. + +I updated my system with Radeon VII from kernel 5.6 to kernel 5.7, and +following started to happen on each boot: + + ... + BUG: kernel NULL pointer dereference, address: 0000000000000128 + ... + CPU: 9 PID: 1940 Comm: modprobe Tainted: G E 5.7.2-200.im0.fc32.x86_64 #1 + Hardware name: System manufacturer System Product Name/PRIME X570-P, BIOS 1407 04/02/2020 + RIP: 0010:lock_bus+0x42/0x60 [amdgpu] + ... + Call Trace: + i2c_smbus_xfer+0x3d/0xf0 + i2c_default_probe+0xf3/0x130 + i2c_detect.isra.0+0xfe/0x2b0 + ? kfree+0xa3/0x200 + ? kobject_uevent_env+0x11f/0x6a0 + ? i2c_detect.isra.0+0x2b0/0x2b0 + __process_new_driver+0x1b/0x20 + bus_for_each_dev+0x64/0x90 + ? 0xffffffffc0f34000 + i2c_register_driver+0x73/0xc0 + do_one_initcall+0x46/0x200 + ? _cond_resched+0x16/0x40 + ? kmem_cache_alloc_trace+0x167/0x220 + ? do_init_module+0x23/0x260 + do_init_module+0x5c/0x260 + __do_sys_init_module+0x14f/0x170 + do_syscall_64+0x5b/0xf0 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + ... + +Error appears when some i2c device driver tries to probe for devices +using adapter registered by `smu_v11_0_i2c_eeprom_control_init()`. +Code supporting this adapter requires `adev->psp.ras.ras` to be not +NULL, which is true only when `amdgpu_ras_init()` detects HW support by +calling `amdgpu_ras_check_supported()`. + +Before 9015d60c9ee1, adapter was registered by + + -> amdgpu_device_ip_init() + -> amdgpu_ras_recovery_init() + -> amdgpu_ras_eeprom_init() + -> smu_v11_0_i2c_eeprom_control_init() + +after verifying that `adev->psp.ras.ras` is not NULL in +`amdgpu_ras_recovery_init()`. Currently it is registered +unconditionally by + + -> amdgpu_device_ip_init() + -> pp_sw_init() + -> hwmgr_sw_init() + -> vega20_smu_init() + -> smu_v11_0_i2c_eeprom_control_init() + +Fix simply adds HW support check (ras == NULL => no support) before +calling `smu_v11_0_i2c_eeprom_control_{init,fini}()`. + +Please note that there is a chance that similar fix is also required for +CHIP_ARCTURUS. I do not know whether any actual Arcturus hardware without +RAS exist, and whether calling `smu_i2c_eeprom_init()` makes any sense +when there is no HW support. + +Cc: stable@vger.kernel.org +Fixes: 9015d60c9ee1 ("drm/amdgpu: Move EEPROM I2C adapter to amdgpu_device") +Signed-off-by: Ivan Mironov +Tested-by: Bjorn Nostvold +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c | 11 +++++++---- + 1 file changed, 7 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c ++++ b/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c +@@ -508,9 +508,11 @@ static int vega20_smu_init(struct pp_hwm + priv->smu_tables.entry[TABLE_ACTIVITY_MONITOR_COEFF].version = 0x01; + priv->smu_tables.entry[TABLE_ACTIVITY_MONITOR_COEFF].size = sizeof(DpmActivityMonitorCoeffInt_t); + +- ret = smu_v11_0_i2c_eeprom_control_init(&adev->pm.smu_i2c); +- if (ret) +- goto err4; ++ if (adev->psp.ras.ras) { ++ ret = smu_v11_0_i2c_eeprom_control_init(&adev->pm.smu_i2c); ++ if (ret) ++ goto err4; ++ } + + return 0; + +@@ -546,7 +548,8 @@ static int vega20_smu_fini(struct pp_hwm + (struct vega20_smumgr *)(hwmgr->smu_backend); + struct amdgpu_device *adev = hwmgr->adev; + +- smu_v11_0_i2c_eeprom_control_fini(&adev->pm.smu_i2c); ++ if (adev->psp.ras.ras) ++ smu_v11_0_i2c_eeprom_control_fini(&adev->pm.smu_i2c); + + if (priv) { + amdgpu_bo_free_kernel(&priv->smu_tables.entry[TABLE_PPTABLE].handle, diff --git a/queue-5.7/drm-amdgpu-atomfirmware-fix-vram_info-fetching-for-renoir.patch b/queue-5.7/drm-amdgpu-atomfirmware-fix-vram_info-fetching-for-renoir.patch new file mode 100644 index 00000000000..d5896411942 --- /dev/null +++ b/queue-5.7/drm-amdgpu-atomfirmware-fix-vram_info-fetching-for-renoir.patch @@ -0,0 +1,34 @@ +From d7a6634a4cfba073ff6a526cb4265d6e58ece234 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Thu, 25 Jun 2020 17:55:57 -0400 +Subject: drm/amdgpu/atomfirmware: fix vram_info fetching for renoir + +From: Alex Deucher + +commit d7a6634a4cfba073ff6a526cb4265d6e58ece234 upstream. + +Renoir uses integrated_system_info table v12. The table +has the same layout as v11 with respect to this data. Just +reuse the existing code for v12 for stable. + +Fixes incorrectly reported vram info in the driver output. + +Acked-by: Evan Quan +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c +@@ -204,6 +204,7 @@ amdgpu_atomfirmware_get_vram_info(struct + (mode_info->atom_context->bios + data_offset); + switch (crev) { + case 11: ++ case 12: + mem_channel_number = igp_info->v11.umachannelnumber; + /* channel width is 64 */ + if (vram_width) diff --git a/queue-5.7/drm-amdgpu-use-u-rather-than-d-for-sclk-mclk.patch b/queue-5.7/drm-amdgpu-use-u-rather-than-d-for-sclk-mclk.patch new file mode 100644 index 00000000000..8b1f4b8a21a --- /dev/null +++ b/queue-5.7/drm-amdgpu-use-u-rather-than-d-for-sclk-mclk.patch @@ -0,0 +1,42 @@ +From beaf10efca64ac824240838ab1f054dfbefab5e6 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 1 Jul 2020 12:00:08 -0400 +Subject: drm/amdgpu: use %u rather than %d for sclk/mclk + +From: Alex Deucher + +commit beaf10efca64ac824240838ab1f054dfbefab5e6 upstream. + +Large clock values may overflow and show up as negative. + +Reported by prOMiNd on IRC. + +Acked-by: Nirmoy Das +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c +@@ -2590,7 +2590,7 @@ static ssize_t amdgpu_hwmon_show_sclk(st + if (r) + return r; + +- return snprintf(buf, PAGE_SIZE, "%d\n", sclk * 10 * 1000); ++ return snprintf(buf, PAGE_SIZE, "%u\n", sclk * 10 * 1000); + } + + static ssize_t amdgpu_hwmon_show_sclk_label(struct device *dev, +@@ -2622,7 +2622,7 @@ static ssize_t amdgpu_hwmon_show_mclk(st + if (r) + return r; + +- return snprintf(buf, PAGE_SIZE, "%d\n", mclk * 10 * 1000); ++ return snprintf(buf, PAGE_SIZE, "%u\n", mclk * 10 * 1000); + } + + static ssize_t amdgpu_hwmon_show_mclk_label(struct device *dev, diff --git a/queue-5.7/drm-i915-include-asm-sources-for-ivb-hsw-_clear_kernel.c.patch b/queue-5.7/drm-i915-include-asm-sources-for-ivb-hsw-_clear_kernel.c.patch new file mode 100644 index 00000000000..f004864d83b --- /dev/null +++ b/queue-5.7/drm-i915-include-asm-sources-for-ivb-hsw-_clear_kernel.c.patch @@ -0,0 +1,392 @@ +From 55fd7e0222ea01246ef3e6aae28b5721fdfb790f Mon Sep 17 00:00:00 2001 +From: Rodrigo Vivi +Date: Wed, 10 Jun 2020 13:18:07 -0700 +Subject: drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c + +From: Rodrigo Vivi + +commit 55fd7e0222ea01246ef3e6aae28b5721fdfb790f upstream. + +Alexandre Oliva has recently removed these files from Linux Libre +with concerns that the sources weren't available. + +The sources are available on IGT repository, and only open source +tools are used to generate the {ivb,hsw}_clear_kernel.c files. + +However, the remaining concern from Alexandre Oliva was around +GPL license and the source not been present when distributing +the code. + +So, it looks like 2 alternatives are possible, the use of +linux-firmware.git repository to store the blob or making sure +that the source is also present in our tree. Since the goal +is to limit the i915 firmware to only the micro-controller blobs +let's make sure that we do include the asm sources here in our tree. + +Btw, I tried to have some diligence here and make sure that the +asms that these commits are adding are truly the source for +the mentioned files: + +igt$ ./scripts/generate_clear_kernel.sh -g ivb \ + -m ~/mesa/build/src/intel/tools/i965_asm +Output file not specified - using default file "ivb-cb_assembled" + +Generating gen7 CB Kernel assembled file "ivb_clear_kernel.c" +for i915 driver... + +igt$ diff ~/i915/drm-tip/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c \ + ivb_clear_kernel.c + +< * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:29:32 AM UTC +> * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:00:54 AM PDT +61c61 +< }; +> }; +\ No newline at end of file + +igt$ ./scripts/generate_clear_kernel.sh -g hsw \ + -m ~/mesa/build/src/intel/tools/i965_asm +Output file not specified - using default file "hsw-cb_assembled" + +Generating gen7.5 CB Kernel assembled file "hsw_clear_kernel.c" +for i915 driver... + +igt$ diff ~/i915/drm-tip/drivers/gpu/drm/i915/gt/hsw_clear_kernel.c \ + hsw_clear_kernel.c +5c5 +< * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:30:13 AM UTC +> * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:01:42 AM PDT +61c61 +< }; +> }; +\ No newline at end of file + +Used IGT and Mesa master repositories from Fri Jun 5 2020) +IGT: 53e8c878a6fb ("tests/kms_chamelium: Force reprobe after replugging + the connector") +Mesa: 5d13c7477eb1 ("radv: set keep_statistic_info with + RADV_DEBUG=shaderstats") +Mesa built with: meson build -D platforms=drm,x11 -D dri-drivers=i965 \ + -D gallium-drivers=iris -D prefix=/usr \ + -D libdir=/usr/lib64/ -Dtools=intel \ + -Dkulkan-drivers=intel && ninja -C build + +v2: Header clean-up and include build instructions in a readme (Chris) + Modified commit message to respect check-patch + +Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003374.html +Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003375.html +Fixes: 47f8253d2b89 ("drm/i915/gen7: Clear all EU/L3 residual contexts") +Cc: # v5.7+ +Cc: Alexandre Oliva +Cc: Prathap Kumar Valsan +Cc: Akeem G Abodunrin +Cc: Mika Kuoppala +Cc: Chris Wilson +Cc: Jani Nikula +Cc: Joonas Lahtinen +Signed-off-by: Rodrigo Vivi +Reviewed-by: Jon Bloomfield +Link: https://patchwork.freedesktop.org/patch/msgid/20200610201807.191440-1-rodrigo.vivi@intel.com +(cherry picked from commit 5a7eeb8ba143d860050ecea924a8f074f02d8023) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/gt/shaders/README | 46 +++++++ + drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm | 119 +++++++++++++++++++ + drivers/gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm | 117 ++++++++++++++++++ + 3 files changed, 282 insertions(+) + +--- /dev/null ++++ b/drivers/gpu/drm/i915/gt/shaders/README +@@ -0,0 +1,46 @@ ++ASM sources for auto generated shaders ++====================================== ++ ++The i915/gt/hsw_clear_kernel.c and i915/gt/ivb_clear_kernel.c files contain ++pre-compiled batch chunks that will clear any residual render cache during ++context switch. ++ ++They are generated from their respective platform ASM files present on ++i915/gt/shaders/clear_kernel directory. ++ ++The generated .c files should never be modified directly. Instead, any modification ++needs to be done on the on their respective ASM files and build instructions below ++needes to be followed. ++ ++Building ++======== ++ ++Environment ++----------- ++ ++IGT GPU tool scripts and the Mesa's i965 instruction assembler tool are used ++on building. ++ ++Please make sure your Mesa tool is compiled with "-Dtools=intel" and ++"-Ddri-drivers=i965", and run this script from IGT source root directory" ++ ++The instructions bellow assume: ++ * IGT gpu tools source code is located on your home directory (~) as ~/igt ++ * Mesa source code is located on your home directory (~) as ~/mesa ++ and built under the ~/mesa/build directory ++ * Linux kernel source code is under your home directory (~) as ~/linux ++ ++Instructions ++------------ ++ ++~ $ cp ~/linux/drivers/gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm \ ++ ~/igt/lib/i915/shaders/clear_kernel/ivb.asm ++~ $ cd ~/igt ++igt $ ./scripts/generate_clear_kernel.sh -g ivb \ ++ -m ~/mesa/build/src/intel/tools/i965_asm ++ ++~ $ cp ~/linux/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm \ ++ ~/igt/lib/i915/shaders/clear_kernel/hsw.asm ++~ $ cd ~/igt ++igt $ ./scripts/generate_clear_kernel.sh -g hsw \ ++ -m ~/mesa/build/src/intel/tools/i965_asm +\ No newline at end of file +--- /dev/null ++++ b/drivers/gpu/drm/i915/gt/shaders/clear_kernel/hsw.asm +@@ -0,0 +1,119 @@ ++// SPDX-License-Identifier: MIT ++/* ++ * Copyright © 2020 Intel Corporation ++ */ ++ ++/* ++ * Kernel for PAVP buffer clear. ++ * ++ * 1. Clear all 64 GRF registers assigned to the kernel with designated value; ++ * 2. Write 32x16 block of all "0" to render target buffer which indirectly clears ++ * 512 bytes of Render Cache. ++ */ ++ ++/* Store designated "clear GRF" value */ ++mov(1) f0.1<1>UW g1.2<0,1,0>UW { align1 1N }; ++ ++/** ++ * Curbe Format ++ * ++ * DW 1.0 - Block Offset to write Render Cache ++ * DW 1.1 [15:0] - Clear Word ++ * DW 1.2 - Delay iterations ++ * DW 1.3 - Enable Instrumentation (only for debug) ++ * DW 1.4 - Rsvd (intended for context ID) ++ * DW 1.5 - [31:16]:SliceCount, [15:0]:SubSlicePerSliceCount ++ * DW 1.6 - Rsvd MBZ (intended for Enable Wait on Total Thread Count) ++ * DW 1.7 - Rsvd MBZ (inteded for Total Thread Count) ++ * ++ * Binding Table ++ * ++ * BTI 0: 2D Surface to help clear L3 (Render/Data Cache) ++ * BTI 1: Wait/Instrumentation Buffer ++ * Size : (SliceCount * SubSliceCount * 16 EUs/SubSlice) rows * (16 threads/EU) cols (Format R32_UINT) ++ * Expected to be initialized to 0 by driver/another kernel ++ * Layout: ++ * RowN: Histogram for EU-N: (SliceID*SubSlicePerSliceCount + SSID)*16 + EUID [assume max 16 EUs / SS] ++ * Col-k[DW-k]: Threads Executed on ThreadID-k for EU-N ++ */ ++add(1) g1.2<1>UD g1.2<0,1,0>UD 0x00000001UD { align1 1N }; /* Loop count to delay kernel: Init to (g1.2 + 1) */ ++cmp.z.f0.0(1) null<1>UD g1.3<0,1,0>UD 0x00000000UD { align1 1N }; ++(+f0.0) jmpi(1) 352D { align1 WE_all 1N }; ++ ++/** ++ * State Register has info on where this thread is running ++ * IVB: sr0.0 :: [15:13]: MBZ, 12: HSID (Half-Slice ID), [11:8]EUID, [2:0] ThreadSlotID ++ * HSW: sr0.0 :: 15: MBZ, [14:13]: SliceID, 12: HSID (Half-Slice ID), [11:8]EUID, [2:0] ThreadSlotID ++ */ ++mov(8) g3<1>UD 0x00000000UD { align1 1Q }; ++shr(1) g3<1>D sr0<0,1,0>D 12D { align1 1N }; ++and(1) g3<1>D g3<0,1,0>D 1D { align1 1N }; /* g3 has HSID */ ++shr(1) g3.1<1>D sr0<0,1,0>D 13D { align1 1N }; ++and(1) g3.1<1>D g3.1<0,1,0>D 3D { align1 1N }; /* g3.1 has sliceID */ ++mul(1) g3.5<1>D g3.1<0,1,0>D g1.10<0,1,0>UW { align1 1N }; ++add(1) g3<1>D g3<0,1,0>D g3.5<0,1,0>D { align1 1N }; /* g3 = sliceID * SubSlicePerSliceCount + HSID */ ++shr(1) g3.2<1>D sr0<0,1,0>D 8D { align1 1N }; ++and(1) g3.2<1>D g3.2<0,1,0>D 15D { align1 1N }; /* g3.2 = EUID */ ++mul(1) g3.4<1>D g3<0,1,0>D 16D { align1 1N }; ++add(1) g3.2<1>D g3.2<0,1,0>D g3.4<0,1,0>D { align1 1N }; /* g3.2 now points to EU row number (Y-pixel = V address ) in instrumentation surf */ ++ ++mov(8) g5<1>UD 0x00000000UD { align1 1Q }; ++and(1) g3.3<1>D sr0<0,1,0>D 7D { align1 1N }; ++mul(1) g3.3<1>D g3.3<0,1,0>D 4D { align1 1N }; ++ ++mov(8) g4<1>UD g0<8,8,1>UD { align1 1Q }; /* Initialize message header with g0 */ ++mov(1) g4<1>UD g3.3<0,1,0>UD { align1 1N }; /* Block offset */ ++mov(1) g4.1<1>UD g3.2<0,1,0>UD { align1 1N }; /* Block offset */ ++mov(1) g4.2<1>UD 0x00000003UD { align1 1N }; /* Block size (1 row x 4 bytes) */ ++and(1) g4.3<1>UD g4.3<0,1,0>UW 0xffffffffUD { align1 1N }; ++ ++/* Media block read to fetch current value at specified location in instrumentation buffer */ ++sendc(8) g5<1>UD g4<8,8,1>F 0x02190001 ++ ++ render MsgDesc: media block read MsgCtrl = 0x0 Surface = 1 mlen 1 rlen 1 { align1 1Q }; ++add(1) g5<1>D g5<0,1,0>D 1D { align1 1N }; ++ ++/* Media block write for updated value at specified location in instrumentation buffer */ ++sendc(8) g5<1>UD g4<8,8,1>F 0x040a8001 ++ render MsgDesc: media block write MsgCtrl = 0x0 Surface = 1 mlen 2 rlen 0 { align1 1Q }; ++ ++/* Delay thread for specified parameter */ ++add.nz.f0.0(1) g1.2<1>UD g1.2<0,1,0>UD -1D { align1 1N }; ++(+f0.0) jmpi(1) -32D { align1 WE_all 1N }; ++ ++/* Store designated "clear GRF" value */ ++mov(1) f0.1<1>UW g1.2<0,1,0>UW { align1 1N }; ++ ++/* Initialize looping parameters */ ++mov(1) a0<1>D 0D { align1 1N }; /* Initialize a0.0:w=0 */ ++mov(1) a0.4<1>W 127W { align1 1N }; /* Loop count. Each loop contains 16 GRF's */ ++ ++/* Write 32x16 all "0" block */ ++mov(8) g2<1>UD g0<8,8,1>UD { align1 1Q }; ++mov(8) g127<1>UD g0<8,8,1>UD { align1 1Q }; ++mov(2) g2<1>UD g1<2,2,1>UW { align1 1N }; ++mov(1) g2.2<1>UD 0x000f000fUD { align1 1N }; /* Block size (16x16) */ ++and(1) g2.3<1>UD g2.3<0,1,0>UW 0xffffffefUD { align1 1N }; ++mov(16) g3<1>UD 0x00000000UD { align1 1H }; ++mov(16) g4<1>UD 0x00000000UD { align1 1H }; ++mov(16) g5<1>UD 0x00000000UD { align1 1H }; ++mov(16) g6<1>UD 0x00000000UD { align1 1H }; ++mov(16) g7<1>UD 0x00000000UD { align1 1H }; ++mov(16) g8<1>UD 0x00000000UD { align1 1H }; ++mov(16) g9<1>UD 0x00000000UD { align1 1H }; ++mov(16) g10<1>UD 0x00000000UD { align1 1H }; ++sendc(8) null<1>UD g2<8,8,1>F 0x120a8000 ++ render MsgDesc: media block write MsgCtrl = 0x0 Surface = 0 mlen 9 rlen 0 { align1 1Q }; ++add(1) g2<1>UD g1<0,1,0>UW 0x0010UW { align1 1N }; ++sendc(8) null<1>UD g2<8,8,1>F 0x120a8000 ++ render MsgDesc: media block write MsgCtrl = 0x0 Surface = 0 mlen 9 rlen 0 { align1 1Q }; ++ ++/* Now, clear all GRF registers */ ++add.nz.f0.0(1) a0.4<1>W a0.4<0,1,0>W -1W { align1 1N }; ++mov(16) g[a0]<1>UW f0.1<0,1,0>UW { align1 1H }; ++add(1) a0<1>D a0<0,1,0>D 32D { align1 1N }; ++(+f0.0) jmpi(1) -64D { align1 WE_all 1N }; ++ ++/* Terminante the thread */ ++sendc(8) null<1>UD g127<8,8,1>F 0x82000010 ++ thread_spawner MsgDesc: mlen 1 rlen 0 { align1 1Q EOT }; +--- /dev/null ++++ b/drivers/gpu/drm/i915/gt/shaders/clear_kernel/ivb.asm +@@ -0,0 +1,117 @@ ++// SPDX-License-Identifier: MIT ++/* ++ * Copyright © 2020 Intel Corporation ++ */ ++ ++/* ++ * Kernel for PAVP buffer clear. ++ * ++ * 1. Clear all 64 GRF registers assigned to the kernel with designated value; ++ * 2. Write 32x16 block of all "0" to render target buffer which indirectly clears ++ * 512 bytes of Render Cache. ++ */ ++ ++/* Store designated "clear GRF" value */ ++mov(1) f0.1<1>UW g1.2<0,1,0>UW { align1 1N }; ++ ++/** ++ * Curbe Format ++ * ++ * DW 1.0 - Block Offset to write Render Cache ++ * DW 1.1 [15:0] - Clear Word ++ * DW 1.2 - Delay iterations ++ * DW 1.3 - Enable Instrumentation (only for debug) ++ * DW 1.4 - Rsvd (intended for context ID) ++ * DW 1.5 - [31:16]:SliceCount, [15:0]:SubSlicePerSliceCount ++ * DW 1.6 - Rsvd MBZ (intended for Enable Wait on Total Thread Count) ++ * DW 1.7 - Rsvd MBZ (inteded for Total Thread Count) ++ * ++ * Binding Table ++ * ++ * BTI 0: 2D Surface to help clear L3 (Render/Data Cache) ++ * BTI 1: Wait/Instrumentation Buffer ++ * Size : (SliceCount * SubSliceCount * 16 EUs/SubSlice) rows * (16 threads/EU) cols (Format R32_UINT) ++ * Expected to be initialized to 0 by driver/another kernel ++ * Layout : ++ * RowN: Histogram for EU-N: (SliceID*SubSlicePerSliceCount + SSID)*16 + EUID [assume max 16 EUs / SS] ++ * Col-k[DW-k]: Threads Executed on ThreadID-k for EU-N ++ */ ++add(1) g1.2<1>UD g1.2<0,1,0>UD 0x00000001UD { align1 1N }; /* Loop count to delay kernel: Init to (g1.2 + 1) */ ++cmp.z.f0.0(1) null<1>UD g1.3<0,1,0>UD 0x00000000UD { align1 1N }; ++(+f0.0) jmpi(1) 44D { align1 WE_all 1N }; ++ ++/** ++ * State Register has info on where this thread is running ++ * IVB: sr0.0 :: [15:13]: MBZ, 12: HSID (Half-Slice ID), [11:8]EUID, [2:0] ThreadSlotID ++ * HSW: sr0.0 :: 15: MBZ, [14:13]: SliceID, 12: HSID (Half-Slice ID), [11:8]EUID, [2:0] ThreadSlotID ++ */ ++mov(8) g3<1>UD 0x00000000UD { align1 1Q }; ++shr(1) g3<1>D sr0<0,1,0>D 12D { align1 1N }; ++and(1) g3<1>D g3<0,1,0>D 1D { align1 1N }; /* g3 has HSID */ ++shr(1) g3.1<1>D sr0<0,1,0>D 13D { align1 1N }; ++and(1) g3.1<1>D g3.1<0,1,0>D 3D { align1 1N }; /* g3.1 has sliceID */ ++mul(1) g3.5<1>D g3.1<0,1,0>D g1.10<0,1,0>UW { align1 1N }; ++add(1) g3<1>D g3<0,1,0>D g3.5<0,1,0>D { align1 1N }; /* g3 = sliceID * SubSlicePerSliceCount + HSID */ ++shr(1) g3.2<1>D sr0<0,1,0>D 8D { align1 1N }; ++and(1) g3.2<1>D g3.2<0,1,0>D 15D { align1 1N }; /* g3.2 = EUID */ ++mul(1) g3.4<1>D g3<0,1,0>D 16D { align1 1N }; ++add(1) g3.2<1>D g3.2<0,1,0>D g3.4<0,1,0>D { align1 1N }; /* g3.2 now points to EU row number (Y-pixel = V address ) in instrumentation surf */ ++ ++mov(8) g5<1>UD 0x00000000UD { align1 1Q }; ++and(1) g3.3<1>D sr0<0,1,0>D 7D { align1 1N }; ++mul(1) g3.3<1>D g3.3<0,1,0>D 4D { align1 1N }; ++ ++mov(8) g4<1>UD g0<8,8,1>UD { align1 1Q }; /* Initialize message header with g0 */ ++mov(1) g4<1>UD g3.3<0,1,0>UD { align1 1N }; /* Block offset */ ++mov(1) g4.1<1>UD g3.2<0,1,0>UD { align1 1N }; /* Block offset */ ++mov(1) g4.2<1>UD 0x00000003UD { align1 1N }; /* Block size (1 row x 4 bytes) */ ++and(1) g4.3<1>UD g4.3<0,1,0>UW 0xffffffffUD { align1 1N }; ++ ++/* Media block read to fetch current value at specified location in instrumentation buffer */ ++sendc(8) g5<1>UD g4<8,8,1>F 0x02190001 ++ render MsgDesc: media block read MsgCtrl = 0x0 Surface = 1 mlen 1 rlen 1 { align1 1Q }; ++add(1) g5<1>D g5<0,1,0>D 1D { align1 1N }; ++ ++/* Media block write for updated value at specified location in instrumentation buffer */ ++sendc(8) g5<1>UD g4<8,8,1>F 0x040a8001 ++ render MsgDesc: media block write MsgCtrl = 0x0 Surface = 1 mlen 2 rlen 0 { align1 1Q }; ++/* Delay thread for specified parameter */ ++add.nz.f0.0(1) g1.2<1>UD g1.2<0,1,0>UD -1D { align1 1N }; ++(+f0.0) jmpi(1) -4D { align1 WE_all 1N }; ++ ++/* Store designated "clear GRF" value */ ++mov(1) f0.1<1>UW g1.2<0,1,0>UW { align1 1N }; ++ ++/* Initialize looping parameters */ ++mov(1) a0<1>D 0D { align1 1N }; /* Initialize a0.0:w=0 */ ++mov(1) a0.4<1>W 127W { align1 1N }; /* Loop count. Each loop contains 16 GRF's */ ++ ++/* Write 32x16 all "0" block */ ++mov(8) g2<1>UD g0<8,8,1>UD { align1 1Q }; ++mov(8) g127<1>UD g0<8,8,1>UD { align1 1Q }; ++mov(2) g2<1>UD g1<2,2,1>UW { align1 1N }; ++mov(1) g2.2<1>UD 0x000f000fUD { align1 1N }; /* Block size (16x16) */ ++and(1) g2.3<1>UD g2.3<0,1,0>UW 0xffffffefUD { align1 1N }; ++mov(16) g3<1>UD 0x00000000UD { align1 1H }; ++mov(16) g4<1>UD 0x00000000UD { align1 1H }; ++mov(16) g5<1>UD 0x00000000UD { align1 1H }; ++mov(16) g6<1>UD 0x00000000UD { align1 1H }; ++mov(16) g7<1>UD 0x00000000UD { align1 1H }; ++mov(16) g8<1>UD 0x00000000UD { align1 1H }; ++mov(16) g9<1>UD 0x00000000UD { align1 1H }; ++mov(16) g10<1>UD 0x00000000UD { align1 1H }; ++sendc(8) null<1>UD g2<8,8,1>F 0x120a8000 ++ render MsgDesc: media block write MsgCtrl = 0x0 Surface = 0 mlen 9 rlen 0 { align1 1Q }; ++add(1) g2<1>UD g1<0,1,0>UW 0x0010UW { align1 1N }; ++sendc(8) null<1>UD g2<8,8,1>F 0x120a8000 ++ render MsgDesc: media block write MsgCtrl = 0x0 Surface = 0 mlen 9 rlen 0 { align1 1Q }; ++ ++/* Now, clear all GRF registers */ ++add.nz.f0.0(1) a0.4<1>W a0.4<0,1,0>W -1W { align1 1N }; ++mov(16) g[a0]<1>UW f0.1<0,1,0>UW { align1 1H }; ++add(1) a0<1>D a0<0,1,0>D 32D { align1 1N }; ++(+f0.0) jmpi(1) -8D { align1 WE_all 1N }; ++ ++/* Terminante the thread */ ++sendc(8) null<1>UD g127<8,8,1>F 0x82000010 ++ thread_spawner MsgDesc: mlen 1 rlen 0 { align1 1Q EOT }; diff --git a/queue-5.7/gfs2-fix-trans-slab-error-when-withdraw-occurs-inside-log_flush.patch b/queue-5.7/gfs2-fix-trans-slab-error-when-withdraw-occurs-inside-log_flush.patch new file mode 100644 index 00000000000..f012a048bc0 --- /dev/null +++ b/queue-5.7/gfs2-fix-trans-slab-error-when-withdraw-occurs-inside-log_flush.patch @@ -0,0 +1,48 @@ +From 58e08e8d83ab03a1ca25d53420bd0b87f2dfe458 Mon Sep 17 00:00:00 2001 +From: Bob Peterson +Date: Tue, 9 Jun 2020 09:55:11 -0400 +Subject: gfs2: fix trans slab error when withdraw occurs inside log_flush + +From: Bob Peterson + +commit 58e08e8d83ab03a1ca25d53420bd0b87f2dfe458 upstream. + +Log flush operations (gfs2_log_flush()) can target a specific transaction. +But if the function encounters errors (e.g. io errors) and withdraws, +the transaction was only freed it if was queued to one of the ail lists. +If the withdraw occurred before the transaction was queued to the ail1 +list, function ail_drain never freed it. The result was: + +BUG gfs2_trans: Objects remaining in gfs2_trans on __kmem_cache_shutdown() + +This patch makes log_flush() add the targeted transaction to the ail1 +list so that function ail_drain() will find and free it properly. + +Cc: stable@vger.kernel.org # v5.7+ +Signed-off-by: Bob Peterson +Signed-off-by: Andreas Gruenbacher +Signed-off-by: Greg Kroah-Hartman + +--- + fs/gfs2/log.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/fs/gfs2/log.c ++++ b/fs/gfs2/log.c +@@ -987,6 +987,16 @@ void gfs2_log_flush(struct gfs2_sbd *sdp + + out: + if (gfs2_withdrawn(sdp)) { ++ /** ++ * If the tr_list is empty, we're withdrawing during a log ++ * flush that targets a transaction, but the transaction was ++ * never queued onto any of the ail lists. Here we add it to ++ * ail1 just so that ail_drain() will find and free it. ++ */ ++ spin_lock(&sdp->sd_ail_lock); ++ if (tr && list_empty(&tr->tr_list)) ++ list_add(&tr->tr_list, &sdp->sd_ail1_list); ++ spin_unlock(&sdp->sd_ail_lock); + ail_drain(sdp); /* frees all transactions */ + tr = NULL; + } diff --git a/queue-5.7/hwmon-pmbus-fix-page-vs.-register-when-accessing-fans.patch b/queue-5.7/hwmon-pmbus-fix-page-vs.-register-when-accessing-fans.patch new file mode 100644 index 00000000000..801c80945e5 --- /dev/null +++ b/queue-5.7/hwmon-pmbus-fix-page-vs.-register-when-accessing-fans.patch @@ -0,0 +1,66 @@ +From b4c8af4c2a226fc9c25e1decbd26fdab1b0993ee Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Jan=20Kundr=C3=A1t?= +Date: Tue, 23 Jun 2020 09:47:39 +0200 +Subject: hwmon: (pmbus) Fix page vs. register when accessing fans +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jan Kundrát + +commit b4c8af4c2a226fc9c25e1decbd26fdab1b0993ee upstream. + +Commit 16358542f32f ("hwmon: (pmbus) Implement multi-phase support") +added support for multi-phase pmbus devices. However, when calling +pmbus_add_sensor() for fans, the patch swapped the `page` and `reg` +attributes. As a result, the fan speeds were reported as 0 RPM on my device. + +Signed-off-by: Jan Kundrát +Fixes: 16358542f32f ("hwmon: (pmbus) Implement multi-phase support") +Cc: stable@vger.kernel.org # v5.7+ +Link: https://lore.kernel.org/r/449bc9e6c0e4305581e45905ce9d043b356a9932.1592904387.git.jan.kundrat@cesnet.cz +[groeck: Fixed references to offending commit] +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/hwmon/pmbus/pmbus_core.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/hwmon/pmbus/pmbus_core.c ++++ b/drivers/hwmon/pmbus/pmbus_core.c +@@ -1869,7 +1869,7 @@ static int pmbus_add_fan_ctrl(struct i2c + struct pmbus_sensor *sensor; + + sensor = pmbus_add_sensor(data, "fan", "target", index, page, +- PMBUS_VIRT_FAN_TARGET_1 + id, 0xff, PSC_FAN, ++ 0xff, PMBUS_VIRT_FAN_TARGET_1 + id, PSC_FAN, + false, false, true); + + if (!sensor) +@@ -1880,14 +1880,14 @@ static int pmbus_add_fan_ctrl(struct i2c + return 0; + + sensor = pmbus_add_sensor(data, "pwm", NULL, index, page, +- PMBUS_VIRT_PWM_1 + id, 0xff, PSC_PWM, ++ 0xff, PMBUS_VIRT_PWM_1 + id, PSC_PWM, + false, false, true); + + if (!sensor) + return -ENOMEM; + + sensor = pmbus_add_sensor(data, "pwm", "enable", index, page, +- PMBUS_VIRT_PWM_ENABLE_1 + id, 0xff, PSC_PWM, ++ 0xff, PMBUS_VIRT_PWM_ENABLE_1 + id, PSC_PWM, + true, false, false); + + if (!sensor) +@@ -1929,7 +1929,7 @@ static int pmbus_add_fan_attributes(stru + continue; + + if (pmbus_add_sensor(data, "fan", "input", index, +- page, pmbus_fan_registers[f], 0xff, ++ page, 0xff, pmbus_fan_registers[f], + PSC_FAN, true, true, true) == NULL) + return -ENOMEM; + diff --git a/queue-5.7/irqchip-gic-atomically-update-affinity.patch b/queue-5.7/irqchip-gic-atomically-update-affinity.patch new file mode 100644 index 00000000000..ac891f5a64b --- /dev/null +++ b/queue-5.7/irqchip-gic-atomically-update-affinity.patch @@ -0,0 +1,61 @@ +From 005c34ae4b44f085120d7f371121ec7ded677761 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Sun, 21 Jun 2020 14:43:15 +0100 +Subject: irqchip/gic: Atomically update affinity + +From: Marc Zyngier + +commit 005c34ae4b44f085120d7f371121ec7ded677761 upstream. + +The GIC driver uses a RMW sequence to update the affinity, and +relies on the gic_lock_irqsave/gic_unlock_irqrestore sequences +to update it atomically. + +But these sequences only expand into anything meaningful if +the BL_SWITCHER option is selected, which almost never happens. + +It also turns out that using a RMW and locks is just as silly, +as the GIC distributor supports byte accesses for the GICD_TARGETRn +registers, which when used make the update atomic by definition. + +Drop the terminally broken code and replace it by a byte write. + +Fixes: 04c8b0f82c7d ("irqchip/gic: Make locking a BL_SWITCHER only feature") +Cc: stable@vger.kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-gic.c | 14 +++----------- + 1 file changed, 3 insertions(+), 11 deletions(-) + +--- a/drivers/irqchip/irq-gic.c ++++ b/drivers/irqchip/irq-gic.c +@@ -329,10 +329,8 @@ static int gic_irq_set_vcpu_affinity(str + static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val, + bool force) + { +- void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + (gic_irq(d) & ~3); +- unsigned int cpu, shift = (gic_irq(d) % 4) * 8; +- u32 val, mask, bit; +- unsigned long flags; ++ void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + gic_irq(d); ++ unsigned int cpu; + + if (!force) + cpu = cpumask_any_and(mask_val, cpu_online_mask); +@@ -342,13 +340,7 @@ static int gic_set_affinity(struct irq_d + if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids) + return -EINVAL; + +- gic_lock_irqsave(flags); +- mask = 0xff << shift; +- bit = gic_cpu_map[cpu] << shift; +- val = readl_relaxed(reg) & ~mask; +- writel_relaxed(val | bit, reg); +- gic_unlock_irqrestore(flags); +- ++ writeb_relaxed(gic_cpu_map[cpu], reg); + irq_data_update_effective_affinity(d, cpumask_of(cpu)); + + return IRQ_SET_MASK_OK_DONE; diff --git a/queue-5.7/mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch b/queue-5.7/mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch new file mode 100644 index 00000000000..d7d9494b055 --- /dev/null +++ b/queue-5.7/mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch @@ -0,0 +1,68 @@ +From fcec538ef8cca0ad0b84432235dccd9059c8e6f8 Mon Sep 17 00:00:00 2001 +From: Hauke Mehrtens +Date: Fri, 3 Jul 2020 00:53:34 +0200 +Subject: MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen + +From: Hauke Mehrtens + +commit fcec538ef8cca0ad0b84432235dccd9059c8e6f8 upstream. + +This resolves the hazard between the mtc0 in the change_c0_status() and +the mfc0 in configure_exception_vector(). Without resolving this hazard +configure_exception_vector() could read an old value and would restore +this old value again. This would revert the changes change_c0_status() +did. I checked this by printing out the read_c0_status() at the end of +per_cpu_trap_init() and the ST0_MX is not set without this patch. + +The hazard is documented in the MIPS Architecture Reference Manual Vol. +III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev +6.03 table 8.1 which includes: + + Producer | Consumer | Hazard + ----------|----------|---------------------------- + mtc0 | mfc0 | any coprocessor 0 register + +I saw this hazard on an Atheros AR9344 rev 2 SoC with a MIPS 74Kc CPU. +There the change_c0_status() function would activate the DSPen by +setting ST0_MX in the c0_status register. This was reverted and then the +system got a DSP exception when the DSP registers were saved in +save_dsp() in the first process switch. The crash looks like this: + +[ 0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) +[ 0.107070] Kernel panic - not syncing: Unexpected DSP exception +[ 0.113470] Rebooting in 1 seconds.. + +We saw this problem in OpenWrt only on the MIPS 74Kc based Atheros SoCs, +not on the 24Kc based SoCs. We only saw it with kernel 5.4 not with +kernel 4.19, in addition we had to use GCC 8.4 or 9.X, with GCC 8.3 it +did not happen. + +In the kernel I bisected this problem to commit 9012d011660e ("compiler: +allow all arches to enable CONFIG_OPTIMIZE_INLINING"), but when this was +reverted it also happened after commit 172dcd935c34b ("MIPS: Always +allocate exception vector for MIPSr2+"). + +Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.") +does similar changes to a different file. I am not sure if there are +more places affected by this problem. + +Signed-off-by: Hauke Mehrtens +Cc: +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman + +--- + arch/mips/kernel/traps.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/mips/kernel/traps.c ++++ b/arch/mips/kernel/traps.c +@@ -2121,6 +2121,7 @@ static void configure_status(void) + + change_c0_status(ST0_CU|ST0_MX|ST0_RE|ST0_FR|ST0_BEV|ST0_TS|ST0_KX|ST0_SX|ST0_UX, + status_set); ++ back_to_back_c0_hazard(); + } + + unsigned int hwrena; diff --git a/queue-5.7/mips-lantiq-xway-sysctrl-fix-the-gphy-clock-alias-names.patch b/queue-5.7/mips-lantiq-xway-sysctrl-fix-the-gphy-clock-alias-names.patch new file mode 100644 index 00000000000..20a78324c27 --- /dev/null +++ b/queue-5.7/mips-lantiq-xway-sysctrl-fix-the-gphy-clock-alias-names.patch @@ -0,0 +1,48 @@ +From 03e62fd67d3ab33f39573fc8787d89dc9b4d7255 Mon Sep 17 00:00:00 2001 +From: Martin Blumenstingl +Date: Sun, 7 Jun 2020 15:10:23 +0200 +Subject: MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names + +From: Martin Blumenstingl + +commit 03e62fd67d3ab33f39573fc8787d89dc9b4d7255 upstream. + +The dt-bindings for the GSWIP describe that the node should be named +"switch". Use the same name in sysctrl.c so the GSWIP driver can +actually find the "gphy0" and "gphy1" clocks. + +Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") +Cc: stable@vger.kernel.org +Signed-off-by: Martin Blumenstingl +Acked-by: Hauke Mehrtens +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman + +--- + arch/mips/lantiq/xway/sysctrl.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/mips/lantiq/xway/sysctrl.c ++++ b/arch/mips/lantiq/xway/sysctrl.c +@@ -514,8 +514,8 @@ void __init ltq_soc_init(void) + clkdev_add_pmu("1e10b308.eth", NULL, 0, 0, PMU_SWITCH | + PMU_PPE_DP | PMU_PPE_TC); + clkdev_add_pmu("1da00000.usif", "NULL", 1, 0, PMU_USIF); +- clkdev_add_pmu("1e108000.gswip", "gphy0", 0, 0, PMU_GPHY); +- clkdev_add_pmu("1e108000.gswip", "gphy1", 0, 0, PMU_GPHY); ++ clkdev_add_pmu("1e108000.switch", "gphy0", 0, 0, PMU_GPHY); ++ clkdev_add_pmu("1e108000.switch", "gphy1", 0, 0, PMU_GPHY); + clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU); + clkdev_add_pmu("1e116000.mei", "afe", 1, 2, PMU_ANALOG_DSL_AFE); + clkdev_add_pmu("1e116000.mei", "dfe", 1, 0, PMU_DFE); +@@ -538,8 +538,8 @@ void __init ltq_soc_init(void) + PMU_SWITCH | PMU_PPE_DPLUS | PMU_PPE_DPLUM | + PMU_PPE_EMA | PMU_PPE_TC | PMU_PPE_SLL01 | + PMU_PPE_QSB | PMU_PPE_TOP); +- clkdev_add_pmu("1e108000.gswip", "gphy0", 0, 0, PMU_GPHY); +- clkdev_add_pmu("1e108000.gswip", "gphy1", 0, 0, PMU_GPHY); ++ clkdev_add_pmu("1e108000.switch", "gphy0", 0, 0, PMU_GPHY); ++ clkdev_add_pmu("1e108000.switch", "gphy1", 0, 0, PMU_GPHY); + clkdev_add_pmu("1e103000.sdio", NULL, 1, 0, PMU_SDIO); + clkdev_add_pmu("1e103100.deu", NULL, 1, 0, PMU_DEU); + clkdev_add_pmu("1e116000.mei", "dfe", 1, 0, PMU_DFE); diff --git a/queue-5.7/mm-cma.c-use-exact_nid-true-to-fix-possible-per-numa-cma-leak.patch b/queue-5.7/mm-cma.c-use-exact_nid-true-to-fix-possible-per-numa-cma-leak.patch new file mode 100644 index 00000000000..070504af41e --- /dev/null +++ b/queue-5.7/mm-cma.c-use-exact_nid-true-to-fix-possible-per-numa-cma-leak.patch @@ -0,0 +1,83 @@ +From 40366bd70bbbbf822ca224dfc227a8c8e868c44f Mon Sep 17 00:00:00 2001 +From: Barry Song +Date: Fri, 3 Jul 2020 15:15:24 -0700 +Subject: mm/cma.c: use exact_nid true to fix possible per-numa cma leak + +From: Barry Song + +commit 40366bd70bbbbf822ca224dfc227a8c8e868c44f upstream. + +Calling cma_declare_contiguous_nid() with false exact_nid for per-numa +reservation can easily cause cma leak and various confusion. For example, +mm/hugetlb.c is trying to reserve per-numa cma for gigantic pages. But it +can easily leak cma and make users confused when system has memoryless +nodes. + +In case the system has 4 numa nodes, and only numa node0 has memory. if +we set hugetlb_cma=4G in bootargs, mm/hugetlb.c will get 4 cma areas for 4 +different numa nodes. since exact_nid=false in current code, all 4 numa +nodes will get cma successfully from node0, but hugetlb_cma[1 to 3] will +never be available to hugepage will only allocate memory from +hugetlb_cma[0]. + +In case the system has 4 numa nodes, both numa node0&2 has memory, other +nodes have no memory. if we set hugetlb_cma=4G in bootargs, mm/hugetlb.c +will get 4 cma areas for 4 different numa nodes. since exact_nid=false in +current code, all 4 numa nodes will get cma successfully from node0 or 2, +but hugetlb_cma[1] and [3] will never be available to hugepage as +mm/hugetlb.c will only allocate memory from hugetlb_cma[0] and +hugetlb_cma[2]. This causes permanent leak of the cma areas which are +supposed to be used by memoryless node. + +Of cource we can workaround the issue by letting mm/hugetlb.c scan all cma +areas in alloc_gigantic_page() even node_mask includes node0 only. that +means when node_mask includes node0 only, we can get page from +hugetlb_cma[1] to hugetlb_cma[3]. But this will cause kernel crash in +free_gigantic_page() while it wants to free page by: +cma_release(hugetlb_cma[page_to_nid(page)], page, 1 << order) + +On the other hand, exact_nid=false won't consider numa distance, it might +be not that useful to leverage cma areas on remote nodes. I feel it is +much simpler to make exact_nid true to make everything clear. After that, +memoryless nodes won't be able to reserve per-numa CMA from other nodes +which have memory. + +Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") +Signed-off-by: Barry Song +Signed-off-by: Andrew Morton +Acked-by: Roman Gushchin +Cc: Jonathan Cameron +Cc: Aslan Bakirov +Cc: Michal Hocko +Cc: Andreas Schaufler +Cc: Mike Kravetz +Cc: Rik van Riel +Cc: Joonsoo Kim +Cc: Robin Murphy +Cc: +Link: http://lkml.kernel.org/r/20200628074345.27228-1-song.bao.hua@hisilicon.com +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/cma.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/cma.c ++++ b/mm/cma.c +@@ -339,13 +339,13 @@ int __init cma_declare_contiguous_nid(ph + */ + if (base < highmem_start && limit > highmem_start) { + addr = memblock_alloc_range_nid(size, alignment, +- highmem_start, limit, nid, false); ++ highmem_start, limit, nid, true); + limit = highmem_start; + } + + if (!addr) { + addr = memblock_alloc_range_nid(size, alignment, base, +- limit, nid, false); ++ limit, nid, true); + if (!addr) { + ret = -ENOMEM; + goto err; diff --git a/queue-5.7/mm-hugetlb.c-fix-pages-per-hugetlb-calculation.patch b/queue-5.7/mm-hugetlb.c-fix-pages-per-hugetlb-calculation.patch new file mode 100644 index 00000000000..37aba8a8aa5 --- /dev/null +++ b/queue-5.7/mm-hugetlb.c-fix-pages-per-hugetlb-calculation.patch @@ -0,0 +1,47 @@ +From 1139d336fff425f9a20374945cdd28eb44d09fa8 Mon Sep 17 00:00:00 2001 +From: Mike Kravetz +Date: Fri, 3 Jul 2020 15:15:18 -0700 +Subject: mm/hugetlb.c: fix pages per hugetlb calculation + +From: Mike Kravetz + +commit 1139d336fff425f9a20374945cdd28eb44d09fa8 upstream. + +The routine hpage_nr_pages() was incorrectly used to calculate the number +of base pages in a hugetlb page. hpage_nr_pages is designed to be called +for THP pages and will return HPAGE_PMD_NR for hugetlb pages of any size. + +Due to the context in which hpage_nr_pages was called, it is unlikely to +produce a user visible error. The routine with the incorrect call is only +exercised in the case of hugetlb memory error or migration. In addition, +this would need to be on an architecture which supports huge page sizes +less than PMD_SIZE. And, the vma containing the huge page would also need +to smaller than PMD_SIZE. + +Fixes: c0d0381ade79 ("hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization") +Reported-by: Matthew Wilcox (Oracle) +Signed-off-by: Mike Kravetz +Signed-off-by: Andrew Morton +Reviewed-by: Matthew Wilcox (Oracle) +Cc: Michal Hocko +Cc: "Kirill A . Shutemov" +Cc: +Link: http://lkml.kernel.org/r/20200629185003.97202-1-mike.kravetz@oracle.com +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/hugetlb.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -1594,7 +1594,7 @@ static struct address_space *_get_hugetl + + /* Use first found vma */ + pgoff_start = page_to_pgoff(hpage); +- pgoff_end = pgoff_start + hpage_nr_pages(hpage) - 1; ++ pgoff_end = pgoff_start + pages_per_huge_page(page_hstate(hpage)) - 1; + anon_vma_interval_tree_foreach(avc, &anon_vma->rb_root, + pgoff_start, pgoff_end) { + struct vm_area_struct *vma = avc->vma; diff --git a/queue-5.7/padata-upgrade-smp_mb__after_atomic-to-smp_mb-in-padata_do_serial.patch b/queue-5.7/padata-upgrade-smp_mb__after_atomic-to-smp_mb-in-padata_do_serial.patch new file mode 100644 index 00000000000..77938e8bc49 --- /dev/null +++ b/queue-5.7/padata-upgrade-smp_mb__after_atomic-to-smp_mb-in-padata_do_serial.patch @@ -0,0 +1,52 @@ +From e04ec0de61c1eb9693179093e83ab8ca68a30d08 Mon Sep 17 00:00:00 2001 +From: Daniel Jordan +Date: Mon, 8 Jun 2020 17:26:52 -0400 +Subject: padata: upgrade smp_mb__after_atomic to smp_mb in padata_do_serial + +From: Daniel Jordan + +commit e04ec0de61c1eb9693179093e83ab8ca68a30d08 upstream. + +A 5.7 kernel hangs during a tcrypt test of padata that waits for an AEAD +request to finish. This is only seen on large machines running many +concurrent requests. + +The issue is that padata never serializes the request. The removal of +the reorder_objects atomic missed that the memory barrier in +padata_do_serial() depends on it. + +Upgrade the barrier from smp_mb__after_atomic to smp_mb to get correct +ordering again. + +Fixes: 3facced7aeed1 ("padata: remove reorder_objects") +Signed-off-by: Daniel Jordan +Cc: Steffen Klassert +Cc: linux-kernel@vger.kernel.org +Cc: +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/padata.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/padata.c ++++ b/kernel/padata.c +@@ -260,7 +260,7 @@ static void padata_reorder(struct parall + * + * Ensure reorder queue is read after pd->lock is dropped so we see + * new objects from another task in padata_do_serial. Pairs with +- * smp_mb__after_atomic in padata_do_serial. ++ * smp_mb in padata_do_serial. + */ + smp_mb(); + +@@ -342,7 +342,7 @@ void padata_do_serial(struct padata_priv + * with the trylock of pd->lock in padata_reorder. Pairs with smp_mb + * in padata_reorder. + */ +- smp_mb__after_atomic(); ++ smp_mb(); + + padata_reorder(pd); + } diff --git a/queue-5.7/series b/queue-5.7/series index 28e5055ae49..b21e1a77e81 100644 --- a/queue-5.7/series +++ b/queue-5.7/series @@ -85,3 +85,26 @@ io_uring-fix-regression-with-always-ignoring-signals.patch spi-spi-fsl-dspi-fix-external-abort-on-interrupt-in-resume-or-exit-paths.patch nfsd-apply-umask-on-fs-without-acl-support.patch revert-alsa-usb-audio-improve-frames-size-computation.patch +padata-upgrade-smp_mb__after_atomic-to-smp_mb-in-padata_do_serial.patch +smb3-honor-seal-flag-for-multiuser-mounts.patch +smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch +smb3-honor-lease-disabling-for-multiuser-mounts.patch +smb3-honor-handletimeout-flag-for-multiuser-mounts.patch +cifs-fix-the-target-file-was-deleted-when-rename-failed.patch +drivers-hv-change-flag-to-write-log-level-in-panic-msg-to-false.patch +hwmon-pmbus-fix-page-vs.-register-when-accessing-fans.patch +thermal-drivers-cpufreq_cooling-fix-wrong-frequency-converted-from-power.patch +acpi-fan-fix-tiger-lake-acpi-device-id.patch +gfs2-fix-trans-slab-error-when-withdraw-occurs-inside-log_flush.patch +x86-split_lock-don-t-write-msr_test_ctrl-on-cpus-that-aren-t-whitelisted.patch +mips-lantiq-xway-sysctrl-fix-the-gphy-clock-alias-names.patch +mips-add-missing-ehb-in-mtc0-mfc0-sequence-for-dspen.patch +drm-i915-include-asm-sources-for-ivb-hsw-_clear_kernel.c.patch +drm-amd-powerplay-fix-null-dereference-in-lock_bus-on-vega20-w-o-ras.patch +drm-amd-display-only-revalidate-bandwidth-on-medium-and-fast-updates.patch +drm-amdgpu-use-u-rather-than-d-for-sclk-mclk.patch +drm-amdgpu-atomfirmware-fix-vram_info-fetching-for-renoir.patch +dma-buf-move-dma_buf_release-from-fops-to-dentry_ops.patch +irqchip-gic-atomically-update-affinity.patch +mm-hugetlb.c-fix-pages-per-hugetlb-calculation.patch +mm-cma.c-use-exact_nid-true-to-fix-possible-per-numa-cma-leak.patch diff --git a/queue-5.7/smb3-honor-handletimeout-flag-for-multiuser-mounts.patch b/queue-5.7/smb3-honor-handletimeout-flag-for-multiuser-mounts.patch new file mode 100644 index 00000000000..5017cc1625d --- /dev/null +++ b/queue-5.7/smb3-honor-handletimeout-flag-for-multiuser-mounts.patch @@ -0,0 +1,30 @@ +From 6b356f6cf941d5054d7fab072cae4a5f8658e3db Mon Sep 17 00:00:00 2001 +From: Paul Aurich +Date: Fri, 26 Jun 2020 12:58:08 -0700 +Subject: SMB3: Honor 'handletimeout' flag for multiuser mounts + +From: Paul Aurich + +commit 6b356f6cf941d5054d7fab072cae4a5f8658e3db upstream. + +Fixes: ca567eb2b3f0 ("SMB3: Allow persistent handle timeout to be configurable on mount") +Signed-off-by: Paul Aurich +CC: Stable +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -5309,6 +5309,7 @@ cifs_construct_tcon(struct cifs_sb_info + vol_info->no_lease = master_tcon->no_lease; + vol_info->resilient = master_tcon->use_resilient; + vol_info->persistent = master_tcon->use_persistent; ++ vol_info->handle_timeout = master_tcon->handle_timeout; + vol_info->no_linux_ext = !master_tcon->unix_ext; + vol_info->linux_ext = master_tcon->posix_extensions; + vol_info->sectype = master_tcon->ses->sectype; diff --git a/queue-5.7/smb3-honor-lease-disabling-for-multiuser-mounts.patch b/queue-5.7/smb3-honor-lease-disabling-for-multiuser-mounts.patch new file mode 100644 index 00000000000..8103fc57774 --- /dev/null +++ b/queue-5.7/smb3-honor-lease-disabling-for-multiuser-mounts.patch @@ -0,0 +1,30 @@ +From ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 Mon Sep 17 00:00:00 2001 +From: Paul Aurich +Date: Fri, 26 Jun 2020 12:58:07 -0700 +Subject: SMB3: Honor lease disabling for multiuser mounts + +From: Paul Aurich + +commit ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 upstream. + +Fixes: 3e7a02d47872 ("smb3: allow disabling requesting leases") +Signed-off-by: Paul Aurich +CC: Stable +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -5306,6 +5306,7 @@ cifs_construct_tcon(struct cifs_sb_info + vol_info->nocase = master_tcon->nocase; + vol_info->nohandlecache = master_tcon->nohandlecache; + vol_info->local_lease = master_tcon->local_lease; ++ vol_info->no_lease = master_tcon->no_lease; + vol_info->resilient = master_tcon->use_resilient; + vol_info->persistent = master_tcon->use_persistent; + vol_info->no_linux_ext = !master_tcon->unix_ext; diff --git a/queue-5.7/smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch b/queue-5.7/smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch new file mode 100644 index 00000000000..cd0107ae49d --- /dev/null +++ b/queue-5.7/smb3-honor-persistent-resilient-handle-flags-for-multiuser-mounts.patch @@ -0,0 +1,36 @@ +From 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f Mon Sep 17 00:00:00 2001 +From: Paul Aurich +Date: Fri, 26 Jun 2020 12:58:06 -0700 +Subject: SMB3: Honor persistent/resilient handle flags for multiuser mounts + +From: Paul Aurich + +commit 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f upstream. + +Without this: + +- persistent handles will only be enabled for per-user tcons if the + server advertises the 'Continuous Availabity' capability +- resilient handles would never be enabled for per-user tcons + +Signed-off-by: Paul Aurich +CC: Stable +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -5306,6 +5306,8 @@ cifs_construct_tcon(struct cifs_sb_info + vol_info->nocase = master_tcon->nocase; + vol_info->nohandlecache = master_tcon->nohandlecache; + vol_info->local_lease = master_tcon->local_lease; ++ vol_info->resilient = master_tcon->use_resilient; ++ vol_info->persistent = master_tcon->use_persistent; + vol_info->no_linux_ext = !master_tcon->unix_ext; + vol_info->linux_ext = master_tcon->posix_extensions; + vol_info->sectype = master_tcon->ses->sectype; diff --git a/queue-5.7/smb3-honor-seal-flag-for-multiuser-mounts.patch b/queue-5.7/smb3-honor-seal-flag-for-multiuser-mounts.patch new file mode 100644 index 00000000000..2dcb6627fa1 --- /dev/null +++ b/queue-5.7/smb3-honor-seal-flag-for-multiuser-mounts.patch @@ -0,0 +1,35 @@ +From cc15461c73d7d044d56c47e869a215e49bd429c8 Mon Sep 17 00:00:00 2001 +From: Paul Aurich +Date: Fri, 26 Jun 2020 12:58:05 -0700 +Subject: SMB3: Honor 'seal' flag for multiuser mounts + +From: Paul Aurich + +commit cc15461c73d7d044d56c47e869a215e49bd429c8 upstream. + +Ensure multiuser SMB3 mounts use encryption for all users' tcons if the +mount options are configured to require encryption. Without this, only +the primary tcon and IPC tcons are guaranteed to be encrypted. Per-user +tcons would only be encrypted if the server was configured to require +encryption. + +Signed-off-by: Paul Aurich +CC: Stable +Signed-off-by: Steve French +Reviewed-by: Aurelien Aptel +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/connect.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/cifs/connect.c ++++ b/fs/cifs/connect.c +@@ -5310,6 +5310,7 @@ cifs_construct_tcon(struct cifs_sb_info + vol_info->linux_ext = master_tcon->posix_extensions; + vol_info->sectype = master_tcon->ses->sectype; + vol_info->sign = master_tcon->ses->sign; ++ vol_info->seal = master_tcon->seal; + + rc = cifs_set_vol_auth(vol_info, master_tcon->ses); + if (rc) { diff --git a/queue-5.7/thermal-drivers-cpufreq_cooling-fix-wrong-frequency-converted-from-power.patch b/queue-5.7/thermal-drivers-cpufreq_cooling-fix-wrong-frequency-converted-from-power.patch new file mode 100644 index 00000000000..346ef3cc6cc --- /dev/null +++ b/queue-5.7/thermal-drivers-cpufreq_cooling-fix-wrong-frequency-converted-from-power.patch @@ -0,0 +1,53 @@ +From 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb Mon Sep 17 00:00:00 2001 +From: Finley Xiao +Date: Fri, 19 Jun 2020 17:08:25 +0800 +Subject: thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power + +From: Finley Xiao + +commit 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb upstream. + +The function cpu_power_to_freq is used to find a frequency and set the +cooling device to consume at most the power to be converted. For example, +if the power to be converted is 80mW, and the em table is as follow. +struct em_cap_state table[] = { + /* KHz mW */ + { 1008000, 36, 0 }, + { 1200000, 49, 0 }, + { 1296000, 59, 0 }, + { 1416000, 72, 0 }, + { 1512000, 86, 0 }, +}; +The target frequency should be 1416000KHz, not 1512000KHz. + +Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power tables") +Cc: # v4.13+ +Signed-off-by: Finley Xiao +Acked-by: Viresh Kumar +Reviewed-by: Amit Kucheria +Signed-off-by: Daniel Lezcano +Link: https://lore.kernel.org/r/20200619090825.32747-1-finley.xiao@rock-chips.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/thermal/cpufreq_cooling.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/thermal/cpufreq_cooling.c ++++ b/drivers/thermal/cpufreq_cooling.c +@@ -123,12 +123,12 @@ static u32 cpu_power_to_freq(struct cpuf + { + int i; + +- for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) { +- if (power > cpufreq_cdev->em->table[i].power) ++ for (i = cpufreq_cdev->max_level; i >= 0; i--) { ++ if (power >= cpufreq_cdev->em->table[i].power) + break; + } + +- return cpufreq_cdev->em->table[i + 1].frequency; ++ return cpufreq_cdev->em->table[i].frequency; + } + + /** diff --git a/queue-5.7/x86-split_lock-don-t-write-msr_test_ctrl-on-cpus-that-aren-t-whitelisted.patch b/queue-5.7/x86-split_lock-don-t-write-msr_test_ctrl-on-cpus-that-aren-t-whitelisted.patch new file mode 100644 index 00000000000..b7ca91d54f5 --- /dev/null +++ b/queue-5.7/x86-split_lock-don-t-write-msr_test_ctrl-on-cpus-that-aren-t-whitelisted.patch @@ -0,0 +1,112 @@ +From 009bce1df0bb5eb970b9eb98d963861f7fe353c7 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 5 Jun 2020 12:26:05 -0700 +Subject: x86/split_lock: Don't write MSR_TEST_CTRL on CPUs that aren't whitelisted + +From: Sean Christopherson + +commit 009bce1df0bb5eb970b9eb98d963861f7fe353c7 upstream. + +Choo! Choo! All aboard the Split Lock Express, with direct service to +Wreckage! + +Skip split_lock_verify_msr() if the CPU isn't whitelisted as a possible +SLD-enabled CPU model to avoid writing MSR_TEST_CTRL. MSR_TEST_CTRL +exists, and is writable, on many generations of CPUs. Writing the MSR, +even with '0', can result in bizarre, undocumented behavior. + +This fixes a crash on Haswell when resuming from suspend with a live KVM +guest. Because APs use the standard SMP boot flow for resume, they will +go through split_lock_init() and the subsequent RDMSR/WRMSR sequence, +which runs even when sld_state==sld_off to ensure SLD is disabled. On +Haswell (at least, my Haswell), writing MSR_TEST_CTRL with '0' will +succeed and _may_ take the SMT _sibling_ out of VMX root mode. + +When KVM has an active guest, KVM performs VMXON as part of CPU onlining +(see kvm_starting_cpu()). Because SMP boot is serialized, the resulting +flow is effectively: + + on_each_ap_cpu() { + WRMSR(MSR_TEST_CTRL, 0) + VMXON + } + +As a result, the WRMSR can disable VMX on a different CPU that has +already done VMXON. This ultimately results in a #UD on VMPTRLD when +KVM regains control and attempt run its vCPUs. + +The above voodoo was confirmed by reworking KVM's VMXON flow to write +MSR_TEST_CTRL prior to VMXON, and to serialize the sequence as above. +Further verification of the insanity was done by redoing VMXON on all +APs after the initial WRMSR->VMXON sequence. The additional VMXON, +which should VM-Fail, occasionally succeeded, and also eliminated the +unexpected #UD on VMPTRLD. + +The damage done by writing MSR_TEST_CTRL doesn't appear to be limited +to VMX, e.g. after suspend with an active KVM guest, subsequent reboots +almost always hang (even when fudging VMXON), a #UD on a random Jcc was +observed, suspend/resume stability is qualitatively poor, and so on and +so forth. + + kernel BUG at arch/x86/kvm/x86.c:386! + CPU: 1 PID: 2592 Comm: CPU 6/KVM Tainted: G D + Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014 + RIP: 0010:kvm_spurious_fault+0xf/0x20 + Call Trace: + vmx_vcpu_load_vmcs+0x1fb/0x2b0 + vmx_vcpu_load+0x3e/0x160 + kvm_arch_vcpu_load+0x48/0x260 + finish_task_switch+0x140/0x260 + __schedule+0x460/0x720 + _cond_resched+0x2d/0x40 + kvm_arch_vcpu_ioctl_run+0x82e/0x1ca0 + kvm_vcpu_ioctl+0x363/0x5c0 + ksys_ioctl+0x88/0xa0 + __x64_sys_ioctl+0x16/0x20 + do_syscall_64+0x4c/0x170 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +Fixes: dbaba47085b0c ("x86/split_lock: Rework the initialization flow of split lock detection") +Signed-off-by: Sean Christopherson +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200605192605.7439-1-sean.j.christopherson@intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/intel.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/intel.c ++++ b/arch/x86/kernel/cpu/intel.c +@@ -49,6 +49,13 @@ static enum split_lock_detect_state sld_ + static u64 msr_test_ctrl_cache __ro_after_init; + + /* ++ * With a name like MSR_TEST_CTL it should go without saying, but don't touch ++ * MSR_TEST_CTL unless the CPU is one of the whitelisted models. Writing it ++ * on CPUs that do not support SLD can cause fireworks, even when writing '0'. ++ */ ++static bool cpu_model_supports_sld __ro_after_init; ++ ++/* + * Processors which have self-snooping capability can handle conflicting + * memory type across CPUs by snooping its own cache. However, there exists + * CPU models in which having conflicting memory types still leads to +@@ -1064,7 +1071,8 @@ static void sld_update_msr(bool on) + + static void split_lock_init(void) + { +- split_lock_verify_msr(sld_state != sld_off); ++ if (cpu_model_supports_sld) ++ split_lock_verify_msr(sld_state != sld_off); + } + + static void split_lock_warn(unsigned long ip) +@@ -1167,5 +1175,6 @@ void __init cpu_set_core_cap_bits(struct + return; + } + ++ cpu_model_supports_sld = true; + split_lock_setup(); + }