--- /dev/null
+From 0318e8374e87b32def1d5c279013ca7730a74982 Mon Sep 17 00:00:00 2001
+From: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
+Date: Tue, 30 Jun 2020 21:11:49 +0530
+Subject: ACPI: fan: Fix Tiger Lake ACPI device ID
+
+From: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
+
+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 <sumeet.r.pawnikar@intel.com>
+Cc: 5.6+ <stable@vger.kernel.org> # 5.6+
+[ rjw: Subject and changelog edits ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2 Mon Sep 17 00:00:00 2001
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Date: Sun, 28 Jun 2020 21:06:38 -0400
+Subject: cifs: Fix the target file was deleted when rename failed.
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+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 <hulkci@huawei.com>
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 4ab59c3c638c6c8952bf07739805d20eb6358a4d Mon Sep 17 00:00:00 2001
+From: Sumit Semwal <sumit.semwal@linaro.org>
+Date: Thu, 11 Jun 2020 17:14:18 +0530
+Subject: dma-buf: Move dma_buf_release() from fops to dentry_ops
+
+From: Sumit Semwal <sumit.semwal@linaro.org>
+
+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: <stable@vger.kernel.org> [5.3+]
+Cc: Arnd Bergmann <arnd@arndb.de>
+Reported-by: Charan Teja Reddy <charante@codeaurora.org>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
+Tested-by: Charan Teja Reddy <charante@codeaurora.org>
+Link: https://patchwork.freedesktop.org/patch/msgid/20200611114418.19852-1-sumit.semwal@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 77b48bea2fee47c15a835f6725dd8df0bc38375a Mon Sep 17 00:00:00 2001
+From: Joseph Salisbury <joseph.salisbury@microsoft.com>
+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 <joseph.salisbury@microsoft.com>
+
+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 <joseph.salisbury@microsoft.com>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/1593210497-114310-1-git-send-email-joseph.salisbury@microsoft.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 Mon Sep 17 00:00:00 2001
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+Date: Mon, 29 Jun 2020 13:03:52 -0400
+Subject: drm/amd/display: Only revalidate bandwidth on medium and fast updates
+
+From: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
+
+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 <nicholas.kazlauskas@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Roman Li <Roman.Li@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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(
--- /dev/null
+From 7e89e4aaa9ae83107d059c186955484b3aa6eb23 Mon Sep 17 00:00:00 2001
+From: Ivan Mironov <mironov.ivan@gmail.com>
+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 <mironov.ivan@gmail.com>
+
+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 <mironov.ivan@gmail.com>
+Tested-by: Bjorn Nostvold <bjorn.nostvold@gmail.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From d7a6634a4cfba073ff6a526cb4265d6e58ece234 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 25 Jun 2020 17:55:57 -0400
+Subject: drm/amdgpu/atomfirmware: fix vram_info fetching for renoir
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+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 <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From beaf10efca64ac824240838ab1f054dfbefab5e6 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 1 Jul 2020 12:00:08 -0400
+Subject: drm/amdgpu: use %u rather than %d for sclk/mclk
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit beaf10efca64ac824240838ab1f054dfbefab5e6 upstream.
+
+Large clock values may overflow and show up as negative.
+
+Reported by prOMiNd on IRC.
+
+Acked-by: Nirmoy Das <nirmoy.das@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 55fd7e0222ea01246ef3e6aae28b5721fdfb790f Mon Sep 17 00:00:00 2001
+From: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Date: Wed, 10 Jun 2020 13:18:07 -0700
+Subject: drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c
+
+From: Rodrigo Vivi <rodrigo.vivi@intel.com>
+
+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: <stable@vger.kernel.org> # v5.7+
+Cc: Alexandre Oliva <lxoliva@fsfla.org>
+Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
+Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
+Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Jani Nikula <jani.nikula@intel.com>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20200610201807.191440-1-rodrigo.vivi@intel.com
+(cherry picked from commit 5a7eeb8ba143d860050ecea924a8f074f02d8023)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 };
--- /dev/null
+From 58e08e8d83ab03a1ca25d53420bd0b87f2dfe458 Mon Sep 17 00:00:00 2001
+From: Bob Peterson <rpeterso@redhat.com>
+Date: Tue, 9 Jun 2020 09:55:11 -0400
+Subject: gfs2: fix trans slab error when withdraw occurs inside log_flush
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+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 <rpeterso@redhat.com>
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From b4c8af4c2a226fc9c25e1decbd26fdab1b0993ee Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jan=20Kundr=C3=A1t?= <jan.kundrat@cesnet.cz>
+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 <jan.kundrat@cesnet.cz>
+
+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 <jan.kundrat@cesnet.cz>
+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 <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From 005c34ae4b44f085120d7f371121ec7ded677761 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <maz@kernel.org>
+Date: Sun, 21 Jun 2020 14:43:15 +0100
+Subject: irqchip/gic: Atomically update affinity
+
+From: Marc Zyngier <maz@kernel.org>
+
+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 <maz@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From fcec538ef8cca0ad0b84432235dccd9059c8e6f8 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens <hauke@hauke-m.de>
+Date: Fri, 3 Jul 2020 00:53:34 +0200
+Subject: MIPS: Add missing EHB in mtc0 -> mfc0 sequence for DSPen
+
+From: Hauke Mehrtens <hauke@hauke-m.de>
+
+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 <hauke@hauke-m.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 03e62fd67d3ab33f39573fc8787d89dc9b4d7255 Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Sun, 7 Jun 2020 15:10:23 +0200
+Subject: MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+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 <martin.blumenstingl@googlemail.com>
+Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 40366bd70bbbbf822ca224dfc227a8c8e868c44f Mon Sep 17 00:00:00 2001
+From: Barry Song <song.bao.hua@hisilicon.com>
+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 <song.bao.hua@hisilicon.com>
+
+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 <song.bao.hua@hisilicon.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Acked-by: Roman Gushchin <guro@fb.com>
+Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Cc: Aslan Bakirov <aslan@fb.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Andreas Schaufler <andreas.schaufler@gmx.de>
+Cc: Mike Kravetz <mike.kravetz@oracle.com>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Joonsoo Kim <js1304@gmail.com>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: <stable@vger.kernel.org>
+Link: http://lkml.kernel.org/r/20200628074345.27228-1-song.bao.hua@hisilicon.com
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 1139d336fff425f9a20374945cdd28eb44d09fa8 Mon Sep 17 00:00:00 2001
+From: Mike Kravetz <mike.kravetz@oracle.com>
+Date: Fri, 3 Jul 2020 15:15:18 -0700
+Subject: mm/hugetlb.c: fix pages per hugetlb calculation
+
+From: Mike Kravetz <mike.kravetz@oracle.com>
+
+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) <willy@infradead.org>
+Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
+Cc: <stable@vger.kernel.org>
+Link: http://lkml.kernel.org/r/20200629185003.97202-1-mike.kravetz@oracle.com
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From e04ec0de61c1eb9693179093e83ab8ca68a30d08 Mon Sep 17 00:00:00 2001
+From: Daniel Jordan <daniel.m.jordan@oracle.com>
+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 <daniel.m.jordan@oracle.com>
+
+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 <daniel.m.jordan@oracle.com>
+Cc: Steffen Klassert <steffen.klassert@secunet.com>
+Cc: linux-kernel@vger.kernel.org
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
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
--- /dev/null
+From 6b356f6cf941d5054d7fab072cae4a5f8658e3db Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Fri, 26 Jun 2020 12:58:08 -0700
+Subject: SMB3: Honor 'handletimeout' flag for multiuser mounts
+
+From: Paul Aurich <paul@darkrain42.org>
+
+commit 6b356f6cf941d5054d7fab072cae4a5f8658e3db upstream.
+
+Fixes: ca567eb2b3f0 ("SMB3: Allow persistent handle timeout to be configurable on mount")
+Signed-off-by: Paul Aurich <paul@darkrain42.org>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Fri, 26 Jun 2020 12:58:07 -0700
+Subject: SMB3: Honor lease disabling for multiuser mounts
+
+From: Paul Aurich <paul@darkrain42.org>
+
+commit ad35f169db6cd5a4c5c0a5a42fb0cad3efeccb83 upstream.
+
+Fixes: 3e7a02d47872 ("smb3: allow disabling requesting leases")
+Signed-off-by: Paul Aurich <paul@darkrain42.org>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 00dfbc2f9c61185a2e662f27c45a0bb29b2a134f Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Fri, 26 Jun 2020 12:58:06 -0700
+Subject: SMB3: Honor persistent/resilient handle flags for multiuser mounts
+
+From: Paul Aurich <paul@darkrain42.org>
+
+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 <paul@darkrain42.org>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From cc15461c73d7d044d56c47e869a215e49bd429c8 Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Fri, 26 Jun 2020 12:58:05 -0700
+Subject: SMB3: Honor 'seal' flag for multiuser mounts
+
+From: Paul Aurich <paul@darkrain42.org>
+
+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 <paul@darkrain42.org>
+CC: Stable <stable@vger.kernel.org>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Reviewed-by: Aurelien Aptel <aaptel@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 371a3bc79c11b707d7a1b7a2c938dc3cc042fffb Mon Sep 17 00:00:00 2001
+From: Finley Xiao <finley.xiao@rock-chips.com>
+Date: Fri, 19 Jun 2020 17:08:25 +0800
+Subject: thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
+
+From: Finley Xiao <finley.xiao@rock-chips.com>
+
+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: <stable@vger.kernel.org> # v4.13+
+Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
+Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
+Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
+Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
+Link: https://lore.kernel.org/r/20200619090825.32747-1-finley.xiao@rock-chips.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
+ /**
--- /dev/null
+From 009bce1df0bb5eb970b9eb98d963861f7fe353c7 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+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 <sean.j.christopherson@intel.com>
+
+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 <sean.j.christopherson@intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+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 <gregkh@linuxfoundation.org>
+
+---
+ 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();
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
