From fd449cec476020fb65b4c5b75dce8388ad48dfd9 Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Sun, 8 Nov 2020 18:14:02 -0500 Subject: [PATCH] Fixes for 5.4 Signed-off-by: Sasha Levin --- .../acpi-nfit-fix-comparison-to-enxio.patch | 38 +++++ ...-sun4i-a10-fix-cpu_alert-temperature.patch | 43 +++++ ...-dts-meson-add-missing-g12-rng-clock.patch | 40 +++++ ...64-smp-move-rcu_cpu_starting-earlier.patch | 67 ++++++++ ...blk-cgroup-fix-memleak-on-error-path.patch | 35 ++++ ...allocate-tree-node-on-blkg_conf_prep.patch | 82 +++++++++ ...pu-add-did-for-navi10-blockchain-sku.patch | 33 ++++ ...fix-refcount_t-underflow-use-after-f.patch | 36 ++++ ...eau-fix-the-start-end-range-for-migr.patch | 73 ++++++++ ...frontend-fix-the-scaler-phase-on-a33.patch | 36 ++++ ...nd-reuse-the-ch0-phase-for-rgb-forma.patch | 73 ++++++++ ...frontend-rework-a-bit-the-phase-data.patch | 115 +++++++++++++ ...-vc4-drv-add-error-handding-for-bind.patch | 35 ++++ ...-unexpected-nvme-completion-data-len.patch | 56 +++++++ ...-pointer-dereference-when-tracing-th.patch | 148 +++++++++++++++++ ...ix-reserved-memory-overlap-detection.patch | 85 ++++++++++ ...-make-sysfs-functional-on-topologies.patch | 156 ++++++++++++++++++ ...start-concurrent-async-scan-on-same-.patch | 75 +++++++++ ...x-potential-race-after-loss-of-trans.patch | 149 +++++++++++++++++ queue-5.4/series | 22 +++ ...t-suspicious-implicit-sign-extension.patch | 48 ++++++ ...-ns_capable_noaudit-on-socket-create.patch | 46 ++++++ ...-to-dated-screen_info-copy-to-fill-b.patch | 50 ++++++ 23 files changed, 1541 insertions(+) create mode 100644 queue-5.4/acpi-nfit-fix-comparison-to-enxio.patch create mode 100644 queue-5.4/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch create mode 100644 queue-5.4/arm64-dts-meson-add-missing-g12-rng-clock.patch create mode 100644 queue-5.4/arm64-smp-move-rcu_cpu_starting-earlier.patch create mode 100644 queue-5.4/blk-cgroup-fix-memleak-on-error-path.patch create mode 100644 queue-5.4/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch create mode 100644 queue-5.4/drm-amdgpu-add-did-for-navi10-blockchain-sku.patch create mode 100644 queue-5.4/drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch create mode 100644 queue-5.4/drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch create mode 100644 queue-5.4/drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch create mode 100644 queue-5.4/drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch create mode 100644 queue-5.4/drm-sun4i-frontend-rework-a-bit-the-phase-data.patch create mode 100644 queue-5.4/drm-vc4-drv-add-error-handding-for-bind.patch create mode 100644 queue-5.4/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch create mode 100644 queue-5.4/nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch create mode 100644 queue-5.4/of-fix-reserved-memory-overlap-detection.patch create mode 100644 queue-5.4/revert-coresight-make-sysfs-functional-on-topologies.patch create mode 100644 queue-5.4/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch create mode 100644 queue-5.4/scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch create mode 100644 queue-5.4/usb-cdns3-gadget-suspicious-implicit-sign-extension.patch create mode 100644 queue-5.4/vsock-use-ns_capable_noaudit-on-socket-create.patch create mode 100644 queue-5.4/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch diff --git a/queue-5.4/acpi-nfit-fix-comparison-to-enxio.patch b/queue-5.4/acpi-nfit-fix-comparison-to-enxio.patch new file mode 100644 index 00000000000..97b180d764f --- /dev/null +++ b/queue-5.4/acpi-nfit-fix-comparison-to-enxio.patch @@ -0,0 +1,38 @@ +From d4abebe7198b1030d47e119ddf2effac2dc0cedb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 27 Oct 2020 21:49:01 +0800 +Subject: ACPI: NFIT: Fix comparison to '-ENXIO' + +From: Zhang Qilong + +[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ] + +Initial value of rc is '-ENXIO', and we should +use the initial value to check it. + +Signed-off-by: Zhang Qilong +Reviewed-by: Pankaj Gupta +Reviewed-by: Vishal Verma +[ rjw: Subject edit ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/nfit/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c +index 12d980aafc5ff..9d78f29cf9967 100644 +--- a/drivers/acpi/nfit/core.c ++++ b/drivers/acpi/nfit/core.c +@@ -1553,7 +1553,7 @@ static ssize_t format1_show(struct device *dev, + le16_to_cpu(nfit_dcr->dcr->code)); + break; + } +- if (rc != ENXIO) ++ if (rc != -ENXIO) + break; + } + mutex_unlock(&acpi_desc->init_mutex); +-- +2.27.0 + diff --git a/queue-5.4/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch b/queue-5.4/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch new file mode 100644 index 00000000000..7097563f09c --- /dev/null +++ b/queue-5.4/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch @@ -0,0 +1,43 @@ +From 49a311353442688acff2301071f68adb13e6279c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 3 Oct 2020 12:03:32 +0200 +Subject: ARM: dts: sun4i-a10: fix cpu_alert temperature +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Clément Péron + +[ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ] + +When running dtbs_check thermal_zone warn about the +temperature declared. + +thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000 + +It's indeed wrong the real value is 85°C and not 850°C. + +Signed-off-by: Clément Péron +Signed-off-by: Maxime Ripard +Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/sun4i-a10.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi +index e0a9b371c248f..2265ca24c0c71 100644 +--- a/arch/arm/boot/dts/sun4i-a10.dtsi ++++ b/arch/arm/boot/dts/sun4i-a10.dtsi +@@ -143,7 +143,7 @@ + trips { + cpu_alert0: cpu-alert0 { + /* milliCelsius */ +- temperature = <850000>; ++ temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; +-- +2.27.0 + diff --git a/queue-5.4/arm64-dts-meson-add-missing-g12-rng-clock.patch b/queue-5.4/arm64-dts-meson-add-missing-g12-rng-clock.patch new file mode 100644 index 00000000000..ff9d3a35ac0 --- /dev/null +++ b/queue-5.4/arm64-dts-meson-add-missing-g12-rng-clock.patch @@ -0,0 +1,40 @@ +From 135e1ae84ce295a8db1c541b56a1f60bd6963a70 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 25 Sep 2020 01:43:53 -0700 +Subject: arm64: dts: meson: add missing g12 rng clock + +From: Scott K Logan + +[ Upstream commit a1afbbb0285797e01313779c71287d936d069245 ] + +This adds the missing perpheral clock for the RNG for Amlogic G12. As +stated in amlogic,meson-rng.yaml, this isn't always necessary for the +RNG to function, but is better to have in case the clock is disabled for +some reason prior to loading. + +Signed-off-by: Scott K Logan +Suggested-by: Neil Armstrong +Reviewed-by: Neil Armstrong +Signed-off-by: Kevin Hilman +Link: https://lore.kernel.org/r/520a1a8ec7a958b3d918d89563ec7e93a4100a45.camel@cottsay.net +Signed-off-by: Sasha Levin +--- + arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi +index 1234bc7974294..354ef2f3eac67 100644 +--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi ++++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi +@@ -167,6 +167,8 @@ + hwrng: rng@218 { + compatible = "amlogic,meson-rng"; + reg = <0x0 0x218 0x0 0x4>; ++ clocks = <&clkc CLKID_RNG0>; ++ clock-names = "core"; + }; + }; + +-- +2.27.0 + diff --git a/queue-5.4/arm64-smp-move-rcu_cpu_starting-earlier.patch b/queue-5.4/arm64-smp-move-rcu_cpu_starting-earlier.patch new file mode 100644 index 00000000000..1836212ff66 --- /dev/null +++ b/queue-5.4/arm64-smp-move-rcu_cpu_starting-earlier.patch @@ -0,0 +1,67 @@ +From f0ab8e361949a428f44506f767ec24e54415b4aa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 28 Oct 2020 14:26:14 -0400 +Subject: arm64/smp: Move rcu_cpu_starting() earlier + +From: Qian Cai + +[ Upstream commit ce3d31ad3cac765484463b4f5a0b6b1f8f1a963e ] + +The call to rcu_cpu_starting() in secondary_start_kernel() is not early +enough in the CPU-hotplug onlining process, which results in lockdep +splats as follows: + + WARNING: suspicious RCU usage + ----------------------------- + kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!! + + other info that might help us debug this: + + RCU used illegally from offline CPU! + rcu_scheduler_active = 1, debug_locks = 1 + no locks held by swapper/1/0. + + Call trace: + dump_backtrace+0x0/0x3c8 + show_stack+0x14/0x60 + dump_stack+0x14c/0x1c4 + lockdep_rcu_suspicious+0x134/0x14c + __lock_acquire+0x1c30/0x2600 + lock_acquire+0x274/0xc48 + _raw_spin_lock+0xc8/0x140 + vprintk_emit+0x90/0x3d0 + vprintk_default+0x34/0x40 + vprintk_func+0x378/0x590 + printk+0xa8/0xd4 + __cpuinfo_store_cpu+0x71c/0x868 + cpuinfo_store_cpu+0x2c/0xc8 + secondary_start_kernel+0x244/0x318 + +This is avoided by moving the call to rcu_cpu_starting up near the +beginning of the secondary_start_kernel() function. + +Signed-off-by: Qian Cai +Acked-by: Paul E. McKenney +Link: https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/ +Link: https://lore.kernel.org/r/20201028182614.13655-1-cai@redhat.com +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + arch/arm64/kernel/smp.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c +index 102dc3e7f2e1d..426409e0d0713 100644 +--- a/arch/arm64/kernel/smp.c ++++ b/arch/arm64/kernel/smp.c +@@ -215,6 +215,7 @@ asmlinkage notrace void secondary_start_kernel(void) + if (system_uses_irq_prio_masking()) + init_gic_priority_masking(); + ++ rcu_cpu_starting(cpu); + preempt_disable(); + trace_hardirqs_off(); + +-- +2.27.0 + diff --git a/queue-5.4/blk-cgroup-fix-memleak-on-error-path.patch b/queue-5.4/blk-cgroup-fix-memleak-on-error-path.patch new file mode 100644 index 00000000000..574b280daee --- /dev/null +++ b/queue-5.4/blk-cgroup-fix-memleak-on-error-path.patch @@ -0,0 +1,35 @@ +From 40674f045a5004fe37a3f2e1b655de3c550e376f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Oct 2020 16:58:41 -0400 +Subject: blk-cgroup: Fix memleak on error path + +From: Gabriel Krisman Bertazi + +[ Upstream commit 52abfcbd57eefdd54737fc8c2dc79d8f46d4a3e5 ] + +If new_blkg allocation raced with blk_policy change and +blkg_lookup_check fails, new_blkg is leaked. + +Acked-by: Tejun Heo +Signed-off-by: Gabriel Krisman Bertazi +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + block/blk-cgroup.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c +index 0c7addcd19859..a4793cfb68f28 100644 +--- a/block/blk-cgroup.c ++++ b/block/blk-cgroup.c +@@ -861,6 +861,7 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + blkg = blkg_lookup_check(pos, pol, q); + if (IS_ERR(blkg)) { + ret = PTR_ERR(blkg); ++ blkg_free(new_blkg); + goto fail_unlock; + } + +-- +2.27.0 + diff --git a/queue-5.4/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch b/queue-5.4/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch new file mode 100644 index 00000000000..b834db72ffc --- /dev/null +++ b/queue-5.4/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch @@ -0,0 +1,82 @@ +From f97692974860afcd772909a577a48b90691c9c9c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Oct 2020 16:58:42 -0400 +Subject: blk-cgroup: Pre-allocate tree node on blkg_conf_prep + +From: Gabriel Krisman Bertazi + +[ Upstream commit f255c19b3ab46d3cad3b1b2e1036f4c926cb1d0c ] + +Similarly to commit 457e490f2b741 ("blkcg: allocate struct blkcg_gq +outside request queue spinlock"), blkg_create can also trigger +occasional -ENOMEM failures at the radix insertion because any +allocation inside blkg_create has to be non-blocking, making it more +likely to fail. This causes trouble for userspace tools trying to +configure io weights who need to deal with this condition. + +This patch reduces the occurrence of -ENOMEMs on this path by preloading +the radix tree element on a GFP_KERNEL context, such that we guarantee +the later non-blocking insertion won't fail. + +A similar solution exists in blkcg_init_queue for the same situation. + +Acked-by: Tejun Heo +Signed-off-by: Gabriel Krisman Bertazi +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + block/blk-cgroup.c | 14 ++++++++++++-- + 1 file changed, 12 insertions(+), 2 deletions(-) + +diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c +index a4793cfb68f28..3d34ac02d76ef 100644 +--- a/block/blk-cgroup.c ++++ b/block/blk-cgroup.c +@@ -855,6 +855,12 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + goto fail; + } + ++ if (radix_tree_preload(GFP_KERNEL)) { ++ blkg_free(new_blkg); ++ ret = -ENOMEM; ++ goto fail; ++ } ++ + rcu_read_lock(); + spin_lock_irq(&q->queue_lock); + +@@ -862,7 +868,7 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + if (IS_ERR(blkg)) { + ret = PTR_ERR(blkg); + blkg_free(new_blkg); +- goto fail_unlock; ++ goto fail_preloaded; + } + + if (blkg) { +@@ -871,10 +877,12 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + blkg = blkg_create(pos, q, new_blkg); + if (IS_ERR(blkg)) { + ret = PTR_ERR(blkg); +- goto fail_unlock; ++ goto fail_preloaded; + } + } + ++ radix_tree_preload_end(); ++ + if (pos == blkcg) + goto success; + } +@@ -884,6 +892,8 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + ctx->body = input; + return 0; + ++fail_preloaded: ++ radix_tree_preload_end(); + fail_unlock: + spin_unlock_irq(&q->queue_lock); + rcu_read_unlock(); +-- +2.27.0 + diff --git a/queue-5.4/drm-amdgpu-add-did-for-navi10-blockchain-sku.patch b/queue-5.4/drm-amdgpu-add-did-for-navi10-blockchain-sku.patch new file mode 100644 index 00000000000..17fb9ec624c --- /dev/null +++ b/queue-5.4/drm-amdgpu-add-did-for-navi10-blockchain-sku.patch @@ -0,0 +1,33 @@ +From 68d05d0ff97c2ba4c9a8f436aec9531ae77a1b60 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 14 Oct 2020 17:05:50 +0800 +Subject: drm/amdgpu: add DID for navi10 blockchain SKU + +From: Tianci.Yin + +[ Upstream commit 8942881144a7365143f196f5eafed24783a424a3 ] + +Reviewed-by: Alex Deucher +Reviewed-by: Guchun Chen +Signed-off-by: Tianci.Yin +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +index fa2c0f29ad4de..e8e1720104160 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +@@ -1011,6 +1011,7 @@ static const struct pci_device_id pciidlist[] = { + {0x1002, 0x7319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10}, + {0x1002, 0x731A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10}, + {0x1002, 0x731B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10}, ++ {0x1002, 0x731E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10}, + {0x1002, 0x731F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI10}, + /* Navi14 */ + {0x1002, 0x7340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_NAVI14}, +-- +2.27.0 + diff --git a/queue-5.4/drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch b/queue-5.4/drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch new file mode 100644 index 00000000000..a0b6e61a73a --- /dev/null +++ b/queue-5.4/drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch @@ -0,0 +1,36 @@ +From 22e345266f612aaa4523b8662804e2c41a15277e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 7 Oct 2020 00:08:09 +0200 +Subject: drm/nouveau/gem: fix "refcount_t: underflow; use-after-free" + +From: Karol Herbst + +[ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ] + +we can't use nouveau_bo_ref here as no ttm object was allocated and +nouveau_bo_ref mainly deals with that. Simply deallocate the object. + +Signed-off-by: Karol Herbst +Signed-off-by: Ben Skeggs +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c +index 7d39d4949ee77..2dd9fcab464b1 100644 +--- a/drivers/gpu/drm/nouveau/nouveau_gem.c ++++ b/drivers/gpu/drm/nouveau/nouveau_gem.c +@@ -197,7 +197,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int align, uint32_t domain, + * to the caller, instead of a normal nouveau_bo ttm reference. */ + ret = drm_gem_object_init(drm->dev, &nvbo->bo.base, size); + if (ret) { +- nouveau_bo_ref(NULL, &nvbo); ++ drm_gem_object_release(&nvbo->bo.base); ++ kfree(nvbo); + return ret; + } + +-- +2.27.0 + diff --git a/queue-5.4/drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch b/queue-5.4/drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch new file mode 100644 index 00000000000..af2a78d2ed3 --- /dev/null +++ b/queue-5.4/drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch @@ -0,0 +1,73 @@ +From d1167f36c87181a3391e11e7fae51d143efe2c32 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Aug 2020 13:31:11 -0700 +Subject: drm/nouveau/nouveau: fix the start/end range for migration + +From: Ralph Campbell + +[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ] + +The user level OpenCL code shouldn't have to align start and end +addresses to a page boundary. That is better handled in the nouveau +driver. The npages field is also redundant since it can be computed +from the start and end addresses. + +Signed-off-by: Ralph Campbell +Signed-off-by: Ben Skeggs +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/nouveau/nouveau_svm.c | 14 +++----------- + 1 file changed, 3 insertions(+), 11 deletions(-) + +diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c b/drivers/gpu/drm/nouveau/nouveau_svm.c +index 824654742a604..0be4668c780bf 100644 +--- a/drivers/gpu/drm/nouveau/nouveau_svm.c ++++ b/drivers/gpu/drm/nouveau/nouveau_svm.c +@@ -112,11 +112,11 @@ nouveau_svmm_bind(struct drm_device *dev, void *data, + struct nouveau_cli *cli = nouveau_cli(file_priv); + struct drm_nouveau_svm_bind *args = data; + unsigned target, cmd, priority; +- unsigned long addr, end, size; ++ unsigned long addr, end; + struct mm_struct *mm; + + args->va_start &= PAGE_MASK; +- args->va_end &= PAGE_MASK; ++ args->va_end = ALIGN(args->va_end, PAGE_SIZE); + + /* Sanity check arguments */ + if (args->reserved0 || args->reserved1) +@@ -125,8 +125,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data, + return -EINVAL; + if (args->va_start >= args->va_end) + return -EINVAL; +- if (!args->npages) +- return -EINVAL; + + cmd = args->header >> NOUVEAU_SVM_BIND_COMMAND_SHIFT; + cmd &= NOUVEAU_SVM_BIND_COMMAND_MASK; +@@ -158,12 +156,6 @@ nouveau_svmm_bind(struct drm_device *dev, void *data, + if (args->stride) + return -EINVAL; + +- size = ((unsigned long)args->npages) << PAGE_SHIFT; +- if ((args->va_start + size) <= args->va_start) +- return -EINVAL; +- if ((args->va_start + size) > args->va_end) +- return -EINVAL; +- + /* + * Ok we are ask to do something sane, for now we only support migrate + * commands but we will add things like memory policy (what to do on +@@ -178,7 +170,7 @@ nouveau_svmm_bind(struct drm_device *dev, void *data, + return -EINVAL; + } + +- for (addr = args->va_start, end = args->va_start + size; addr < end;) { ++ for (addr = args->va_start, end = args->va_end; addr < end;) { + struct vm_area_struct *vma; + unsigned long next; + +-- +2.27.0 + diff --git a/queue-5.4/drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch b/queue-5.4/drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch new file mode 100644 index 00000000000..a776cee6114 --- /dev/null +++ b/queue-5.4/drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch @@ -0,0 +1,36 @@ +From 9d3f6359e0fbb621e4fde3832d05441bf6ec5774 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 15 Oct 2020 11:36:42 +0200 +Subject: drm/sun4i: frontend: Fix the scaler phase on A33 + +From: Maxime Ripard + +[ Upstream commit e3190b5e9462067714d267c40d8c8c1d0463dda3 ] + +The A33 has a different phase parameter in the Allwinner BSP on the +channel1 than the one currently applied. Fix this. + +Signed-off-by: Maxime Ripard +Acked-by: Jernej Skrabec +Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-maxime@cerno.tech +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c +index c4959d9e16391..7186ba73d8e14 100644 +--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c ++++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c +@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend = { + }; + + static const struct sun4i_frontend_data sun8i_a33_frontend = { +- .ch_phase = { 0x400, 0x400 }, ++ .ch_phase = { 0x400, 0xfc400 }, + .has_coef_access_ctrl = true, + }; + +-- +2.27.0 + diff --git a/queue-5.4/drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch b/queue-5.4/drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch new file mode 100644 index 00000000000..8fb08a7f11e --- /dev/null +++ b/queue-5.4/drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch @@ -0,0 +1,73 @@ +From 972ae359778aebdd1589f44af8ce7360678b312b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 15 Oct 2020 11:36:41 +0200 +Subject: drm/sun4i: frontend: Reuse the ch0 phase for RGB formats + +From: Maxime Ripard + +[ Upstream commit 2db9ef9d9e6ea89a9feb5338f58d1f8f83875577 ] + +When using the scaler on the A10-like frontend with single-planar formats, +the current code will setup the channel 0 filter (used for the R or Y +component) with a different phase parameter than the channel 1 filter (used +for the G/B or U/V components). + +This creates a bleed out that keeps repeating on of the last line of the +RGB plane across the rest of the display. The Allwinner BSP either applies +the same phase parameter over both channels or use a separate one, the +condition being whether the input format is YUV420 or not. + +Since YUV420 is both subsampled and multi-planar, and since YUYV is +subsampled but single-planar, we can rule out the subsampling and assume +that the condition is actually whether the format is single or +multi-planar. And it looks like applying the same phase parameter over both +channels for single-planar formats fixes our issue, while we keep the +multi-planar formats working properly. + +Reported-by: Taras Galchenko +Signed-off-by: Maxime Ripard +Acked-by: Jernej Skrabec +Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c +index 7462801b1fa8e..c4959d9e16391 100644 +--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c ++++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c +@@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, + struct drm_framebuffer *fb = state->fb; + const struct drm_format_info *format = fb->format; + uint64_t modifier = fb->modifier; ++ unsigned int ch1_phase_idx; + u32 out_fmt_val; + u32 in_fmt_val, in_mod_val, in_ps_val; + unsigned int i; +@@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, + * I have no idea what this does exactly, but it seems to be + * related to the scaler FIR filter phase parameters. + */ ++ ch1_phase_idx = (format->num_planes > 1) ? 1 : 0; + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, + frontend->data->ch_phase[0]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, +- frontend->data->ch_phase[1]); ++ frontend->data->ch_phase[ch1_phase_idx]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, + frontend->data->ch_phase[0]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, +- frontend->data->ch_phase[1]); ++ frontend->data->ch_phase[ch1_phase_idx]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, + frontend->data->ch_phase[0]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, +- frontend->data->ch_phase[1]); ++ frontend->data->ch_phase[ch1_phase_idx]); + + /* + * Checking the input format is sufficient since we currently only +-- +2.27.0 + diff --git a/queue-5.4/drm-sun4i-frontend-rework-a-bit-the-phase-data.patch b/queue-5.4/drm-sun4i-frontend-rework-a-bit-the-phase-data.patch new file mode 100644 index 00000000000..5933cb126ad --- /dev/null +++ b/queue-5.4/drm-sun4i-frontend-rework-a-bit-the-phase-data.patch @@ -0,0 +1,115 @@ +From ddaa67db435aad193f6d180ab51f949e398f1c82 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 15 Oct 2020 11:36:40 +0200 +Subject: drm/sun4i: frontend: Rework a bit the phase data + +From: Maxime Ripard + +[ Upstream commit 84c971b356379c621df595bd00c3114579dfa59f ] + +The scaler filter phase setup in the allwinner kernel has two different +cases for setting up the scaler filter, the first one using different phase +parameters for the two channels, and the second one reusing the first +channel parameters on the second channel. + +The allwinner kernel has a third option where the horizontal phase of the +second channel will be set to a different value than the vertical one (and +seems like it's the same value than one used on the first channel). +However, that code path seems to never be taken, so we can ignore it for +now, and it's essentially what we're doing so far as well. + +Since we will have always the same values across each components of the +filter setup for a given channel, we can simplify a bit our frontend +structure by only storing the phase value we want to apply to a given +channel. + +Signed-off-by: Maxime Ripard +Acked-by: Jernej Skrabec +Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-maxime@cerno.tech +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++++++-------------------- + drivers/gpu/drm/sun4i/sun4i_frontend.h | 6 +---- + 2 files changed, 9 insertions(+), 31 deletions(-) + +diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c b/drivers/gpu/drm/sun4i/sun4i_frontend.c +index ec2a032e07b97..7462801b1fa8e 100644 +--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c ++++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c +@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend *frontend, + * related to the scaler FIR filter phase parameters. + */ + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG, +- frontend->data->ch_phase[0].horzphase); ++ frontend->data->ch_phase[0]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG, +- frontend->data->ch_phase[1].horzphase); ++ frontend->data->ch_phase[1]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG, +- frontend->data->ch_phase[0].vertphase[0]); ++ frontend->data->ch_phase[0]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG, +- frontend->data->ch_phase[1].vertphase[0]); ++ frontend->data->ch_phase[1]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG, +- frontend->data->ch_phase[0].vertphase[1]); ++ frontend->data->ch_phase[0]); + regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG, +- frontend->data->ch_phase[1].vertphase[1]); ++ frontend->data->ch_phase[1]); + + /* + * Checking the input format is sufficient since we currently only +@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = { + }; + + static const struct sun4i_frontend_data sun4i_a10_frontend = { +- .ch_phase = { +- { +- .horzphase = 0, +- .vertphase = { 0, 0 }, +- }, +- { +- .horzphase = 0xfc000, +- .vertphase = { 0xfc000, 0xfc000 }, +- }, +- }, ++ .ch_phase = { 0x000, 0xfc000 }, + .has_coef_rdy = true, + }; + + static const struct sun4i_frontend_data sun8i_a33_frontend = { +- .ch_phase = { +- { +- .horzphase = 0x400, +- .vertphase = { 0x400, 0x400 }, +- }, +- { +- .horzphase = 0x400, +- .vertphase = { 0x400, 0x400 }, +- }, +- }, ++ .ch_phase = { 0x400, 0x400 }, + .has_coef_access_ctrl = true, + }; + +diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h b/drivers/gpu/drm/sun4i/sun4i_frontend.h +index 0c382c1ddb0fe..2e7b76e50c2ba 100644 +--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h ++++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h +@@ -115,11 +115,7 @@ struct reset_control; + struct sun4i_frontend_data { + bool has_coef_access_ctrl; + bool has_coef_rdy; +- +- struct { +- u32 horzphase; +- u32 vertphase[2]; +- } ch_phase[2]; ++ u32 ch_phase[2]; + }; + + struct sun4i_frontend { +-- +2.27.0 + diff --git a/queue-5.4/drm-vc4-drv-add-error-handding-for-bind.patch b/queue-5.4/drm-vc4-drv-add-error-handding-for-bind.patch new file mode 100644 index 00000000000..960d2b8ad09 --- /dev/null +++ b/queue-5.4/drm-vc4-drv-add-error-handding-for-bind.patch @@ -0,0 +1,35 @@ +From 1559d453545779e153afb08fb00c84b9d28caad3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 27 Oct 2020 13:14:42 +0900 +Subject: drm/vc4: drv: Add error handding for bind + +From: Hoegeun Kwon + +[ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] + +There is a problem that if vc4_drm bind fails, a memory leak occurs on +the drm_property_create side. Add error handding for drm_mode_config. + +Signed-off-by: Hoegeun Kwon +Signed-off-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/vc4/vc4_drv.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c +index 5e6fb6c2307f0..0d78ba017a29b 100644 +--- a/drivers/gpu/drm/vc4/vc4_drv.c ++++ b/drivers/gpu/drm/vc4/vc4_drv.c +@@ -309,6 +309,7 @@ static int vc4_drm_bind(struct device *dev) + component_unbind_all(dev, drm); + gem_destroy: + vc4_gem_destroy(drm); ++ drm_mode_config_cleanup(drm); + vc4_bo_cache_destroy(drm); + dev_put: + drm_dev_put(drm); +-- +2.27.0 + diff --git a/queue-5.4/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch b/queue-5.4/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch new file mode 100644 index 00000000000..0214e515750 --- /dev/null +++ b/queue-5.4/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch @@ -0,0 +1,56 @@ +From 4fa83b80894b46f350b767c24f7cbc7c10e7e6af Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 25 Oct 2020 19:51:24 +0800 +Subject: nvme-rdma: handle unexpected nvme completion data length + +From: zhenwei pi + +[ Upstream commit 25c1ca6ecaba3b751d3f7ff92d5cddff3b05f8d0 ] + +Receiving a zero length message leads to the following warnings because +the CQE is processed twice: + +refcount_t: underflow; use-after-free. +WARNING: CPU: 0 PID: 0 at lib/refcount.c:28 + +RIP: 0010:refcount_warn_saturate+0xd9/0xe0 +Call Trace: + + nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma] + __ib_process_cq+0x76/0x150 [ib_core] + ... + +Sanity check the received data length, to avoids this. + +Thanks to Chao Leng & Sagi for suggestions. + +Signed-off-by: zhenwei pi +Reviewed-by: Sagi Grimberg +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + drivers/nvme/host/rdma.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c +index a41ee9feab8e7..e957ad0a07f58 100644 +--- a/drivers/nvme/host/rdma.c ++++ b/drivers/nvme/host/rdma.c +@@ -1520,6 +1520,14 @@ static void nvme_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc) + return; + } + ++ /* sanity checking for received data length */ ++ if (unlikely(wc->byte_len < len)) { ++ dev_err(queue->ctrl->ctrl.device, ++ "Unexpected nvme completion length(%d)\n", wc->byte_len); ++ nvme_rdma_error_recovery(queue->ctrl); ++ return; ++ } ++ + ib_dma_sync_single_for_cpu(ibdev, qe->dma, len, DMA_FROM_DEVICE); + /* + * AEN requests are special as they don't time out and can +-- +2.27.0 + diff --git a/queue-5.4/nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch b/queue-5.4/nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch new file mode 100644 index 00000000000..12cb63db8b3 --- /dev/null +++ b/queue-5.4/nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch @@ -0,0 +1,148 @@ +From 9eaf850a0e8336a6f8dd1cc545492c84fe11cd04 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Oct 2020 16:58:21 -0700 +Subject: nvmet: fix a NULL pointer dereference when tracing the flush command + +From: Chaitanya Kulkarni + +[ Upstream commit 3c3751f2daf6675f6b5bee83b792354c272f5bd2 ] + +When target side trace in turned on and flush command is issued from the +host it results in the following Oops. + +[ 856.789724] BUG: kernel NULL pointer dereference, address: 0000000000000068 +[ 856.790686] #PF: supervisor read access in kernel mode +[ 856.791262] #PF: error_code(0x0000) - not-present page +[ 856.791863] PGD 6d7110067 P4D 6d7110067 PUD 66f0ad067 PMD 0 +[ 856.792527] Oops: 0000 [#1] SMP NOPTI +[ 856.792950] CPU: 15 PID: 7034 Comm: nvme Tainted: G OE 5.9.0nvme-5.9+ #71 +[ 856.793790] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e3214 +[ 856.794956] RIP: 0010:trace_event_raw_event_nvmet_req_init+0x13e/0x170 [nvmet] +[ 856.795734] Code: 41 5c 41 5d c3 31 d2 31 f6 e8 4e 9b b8 e0 e9 0e ff ff ff 49 8b 55 00 48 8b 38 8b 0 +[ 856.797740] RSP: 0018:ffffc90001be3a60 EFLAGS: 00010246 +[ 856.798375] RAX: 0000000000000000 RBX: ffff8887e7d2c01c RCX: 0000000000000000 +[ 856.799234] RDX: 0000000000000020 RSI: 0000000057e70ea2 RDI: ffff8887e7d2c034 +[ 856.800088] RBP: ffff88869f710578 R08: ffff888807500d40 R09: 00000000fffffffe +[ 856.800951] R10: 0000000064c66670 R11: 00000000ef955201 R12: ffff8887e7d2c034 +[ 856.801807] R13: ffff88869f7105c8 R14: 0000000000000040 R15: ffff88869f710440 +[ 856.802667] FS: 00007f6a22bd8780(0000) GS:ffff888813a00000(0000) knlGS:0000000000000000 +[ 856.803635] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 856.804367] CR2: 0000000000000068 CR3: 00000006d73e0000 CR4: 00000000003506e0 +[ 856.805283] Call Trace: +[ 856.805613] nvmet_req_init+0x27c/0x480 [nvmet] +[ 856.806200] nvme_loop_queue_rq+0xcb/0x1d0 [nvme_loop] +[ 856.806862] blk_mq_dispatch_rq_list+0x123/0x7b0 +[ 856.807459] ? kvm_sched_clock_read+0x14/0x30 +[ 856.808025] __blk_mq_sched_dispatch_requests+0xc7/0x170 +[ 856.808708] blk_mq_sched_dispatch_requests+0x30/0x60 +[ 856.809372] __blk_mq_run_hw_queue+0x70/0x100 +[ 856.809935] __blk_mq_delay_run_hw_queue+0x156/0x170 +[ 856.810574] blk_mq_run_hw_queue+0x86/0xe0 +[ 856.811104] blk_mq_sched_insert_request+0xef/0x160 +[ 856.811733] blk_execute_rq+0x69/0xc0 +[ 856.812212] ? blk_mq_rq_ctx_init+0xd0/0x230 +[ 856.812784] nvme_execute_passthru_rq+0x57/0x130 [nvme_core] +[ 856.813461] nvme_submit_user_cmd+0xeb/0x300 [nvme_core] +[ 856.814099] nvme_user_cmd.isra.82+0x11e/0x1a0 [nvme_core] +[ 856.814752] blkdev_ioctl+0x1dc/0x2c0 +[ 856.815197] block_ioctl+0x3f/0x50 +[ 856.815606] __x64_sys_ioctl+0x84/0xc0 +[ 856.816074] do_syscall_64+0x33/0x40 +[ 856.816533] entry_SYSCALL_64_after_hwframe+0x44/0xa9 +[ 856.817168] RIP: 0033:0x7f6a222ed107 +[ 856.817617] Code: 44 00 00 48 8b 05 81 cd 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 8 +[ 856.819901] RSP: 002b:00007ffca848f058 EFLAGS: 00000202 ORIG_RAX: 0000000000000010 +[ 856.820846] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f6a222ed107 +[ 856.821726] RDX: 00007ffca848f060 RSI: 00000000c0484e43 RDI: 0000000000000003 +[ 856.822603] RBP: 0000000000000003 R08: 000000000000003f R09: 0000000000000005 +[ 856.823478] R10: 00007ffca848ece0 R11: 0000000000000202 R12: 00007ffca84912d3 +[ 856.824359] R13: 00007ffca848f4d0 R14: 0000000000000002 R15: 000000000067e900 +[ 856.825236] Modules linked in: nvme_loop(OE) nvmet(OE) nvme_fabrics(OE) null_blk nvme(OE) nvme_corel + +Move the nvmet_req_init() tracepoint after we parse the command in +nvmet_req_init() so that we can get rid of the duplicate +nvmet_find_namespace() call. +Rename __assign_disk_name() -> __assign_req_name(). Now that we call +tracepoint after parsing the command simplify the newly added +__assign_req_name() which fixes this bug. + +Signed-off-by: Chaitanya Kulkarni +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + drivers/nvme/target/core.c | 4 ++-- + drivers/nvme/target/trace.h | 21 +++++++-------------- + 2 files changed, 9 insertions(+), 16 deletions(-) + +diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c +index 6b2f1e290fa73..cca5a00c098a8 100644 +--- a/drivers/nvme/target/core.c ++++ b/drivers/nvme/target/core.c +@@ -878,8 +878,6 @@ bool nvmet_req_init(struct nvmet_req *req, struct nvmet_cq *cq, + req->error_loc = NVMET_NO_ERROR_LOC; + req->error_slba = 0; + +- trace_nvmet_req_init(req, req->cmd); +- + /* no support for fused commands yet */ + if (unlikely(flags & (NVME_CMD_FUSE_FIRST | NVME_CMD_FUSE_SECOND))) { + req->error_loc = offsetof(struct nvme_common_command, flags); +@@ -913,6 +911,8 @@ bool nvmet_req_init(struct nvmet_req *req, struct nvmet_cq *cq, + if (status) + goto fail; + ++ trace_nvmet_req_init(req, req->cmd); ++ + if (unlikely(!percpu_ref_tryget_live(&sq->ref))) { + status = NVME_SC_INVALID_FIELD | NVME_SC_DNR; + goto fail; +diff --git a/drivers/nvme/target/trace.h b/drivers/nvme/target/trace.h +index e645caa882dd3..3f61b6657175e 100644 +--- a/drivers/nvme/target/trace.h ++++ b/drivers/nvme/target/trace.h +@@ -46,19 +46,12 @@ static inline struct nvmet_ctrl *nvmet_req_to_ctrl(struct nvmet_req *req) + return req->sq->ctrl; + } + +-static inline void __assign_disk_name(char *name, struct nvmet_req *req, +- bool init) ++static inline void __assign_req_name(char *name, struct nvmet_req *req) + { +- struct nvmet_ctrl *ctrl = nvmet_req_to_ctrl(req); +- struct nvmet_ns *ns; +- +- if ((init && req->sq->qid) || (!init && req->cq->qid)) { +- ns = nvmet_find_namespace(ctrl, req->cmd->rw.nsid); +- strncpy(name, ns->device_path, DISK_NAME_LEN); +- return; +- } +- +- memset(name, 0, DISK_NAME_LEN); ++ if (req->ns) ++ strncpy(name, req->ns->device_path, DISK_NAME_LEN); ++ else ++ memset(name, 0, DISK_NAME_LEN); + } + #endif + +@@ -81,7 +74,7 @@ TRACE_EVENT(nvmet_req_init, + TP_fast_assign( + __entry->cmd = cmd; + __entry->ctrl = nvmet_req_to_ctrl(req); +- __assign_disk_name(__entry->disk, req, true); ++ __assign_req_name(__entry->disk, req); + __entry->qid = req->sq->qid; + __entry->cid = cmd->common.command_id; + __entry->opcode = cmd->common.opcode; +@@ -121,7 +114,7 @@ TRACE_EVENT(nvmet_req_complete, + __entry->cid = req->cqe->command_id; + __entry->result = le64_to_cpu(req->cqe->result.u64); + __entry->status = le16_to_cpu(req->cqe->status) >> 1; +- __assign_disk_name(__entry->disk, req, false); ++ __assign_req_name(__entry->disk, req); + ), + TP_printk("nvmet%s: %sqid=%d, cmdid=%u, res=%#llx, status=%#x", + __print_ctrl_name(__entry->ctrl), +-- +2.27.0 + diff --git a/queue-5.4/of-fix-reserved-memory-overlap-detection.patch b/queue-5.4/of-fix-reserved-memory-overlap-detection.patch new file mode 100644 index 00000000000..5b586ff80d1 --- /dev/null +++ b/queue-5.4/of-fix-reserved-memory-overlap-detection.patch @@ -0,0 +1,85 @@ +From 670f750b66c3f6f1eb770cfba1a98af0e657de87 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Oct 2020 11:53:59 +0200 +Subject: of: Fix reserved-memory overlap detection + +From: Vincent Whitchurch + +[ Upstream commit ca05f33316559a04867295dd49f85aeedbfd6bfd ] + +The reserved-memory overlap detection code fails to detect overlaps if +either of the regions starts at address 0x0. The code explicitly checks +for and ignores such regions, apparently in order to ignore dynamically +allocated regions which have an address of 0x0 at this point. These +dynamically allocated regions also have a size of 0x0 at this point, so +fix this by removing the check and sorting the dynamically allocated +regions ahead of any static regions at address 0x0. + +For example, there are two overlaps in this case but they are not +currently reported: + + foo@0 { + reg = <0x0 0x2000>; + }; + + bar@0 { + reg = <0x0 0x1000>; + }; + + baz@1000 { + reg = <0x1000 0x1000>; + }; + + quux { + size = <0x1000>; + }; + +but they are after this patch: + + OF: reserved mem: OVERLAP DETECTED! + bar@0 (0x00000000--0x00001000) overlaps with foo@0 (0x00000000--0x00002000) + OF: reserved mem: OVERLAP DETECTED! + foo@0 (0x00000000--0x00002000) overlaps with baz@1000 (0x00001000--0x00002000) + +Signed-off-by: Vincent Whitchurch +Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com +Signed-off-by: Rob Herring +Signed-off-by: Sasha Levin +--- + drivers/of/of_reserved_mem.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c +index 6bd610ee2cd73..3fb5d8caffd53 100644 +--- a/drivers/of/of_reserved_mem.c ++++ b/drivers/of/of_reserved_mem.c +@@ -200,6 +200,16 @@ static int __init __rmem_cmp(const void *a, const void *b) + if (ra->base > rb->base) + return 1; + ++ /* ++ * Put the dynamic allocations (address == 0, size == 0) before static ++ * allocations at address 0x0 so that overlap detection works ++ * correctly. ++ */ ++ if (ra->size < rb->size) ++ return -1; ++ if (ra->size > rb->size) ++ return 1; ++ + return 0; + } + +@@ -217,8 +227,7 @@ static void __init __rmem_check_for_overlap(void) + + this = &reserved_mem[i]; + next = &reserved_mem[i + 1]; +- if (!(this->base && next->base)) +- continue; ++ + if (this->base + this->size > next->base) { + phys_addr_t this_end, next_end; + +-- +2.27.0 + diff --git a/queue-5.4/revert-coresight-make-sysfs-functional-on-topologies.patch b/queue-5.4/revert-coresight-make-sysfs-functional-on-topologies.patch new file mode 100644 index 00000000000..20fbf8a87c4 --- /dev/null +++ b/queue-5.4/revert-coresight-make-sysfs-functional-on-topologies.patch @@ -0,0 +1,156 @@ +From 1cbd89efcf4fa9c3db858efa087a69dd3d576016 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 8 Nov 2020 08:28:09 -0500 +Subject: Revert "coresight: Make sysfs functional on topologies with per core + sink" + +This reverts commit 8fd52a21ab570e80f84f39e12affce42a5300e91. + +Guenter Roeck writes: + +I get the following build warning in v5.4.75. + +drivers/hwtracing/coresight/coresight-etm-perf.c: In function 'etm_setup_aux': +drivers/hwtracing/coresight/coresight-etm-perf.c:226:37: warning: + passing argument 1 of 'coresight_get_enabled_sink' makes pointer from integer without a cast + +Actually, the warning is fatal, since the call is + sink = coresight_get_enabled_sink(true); +However, the argument to coresight_get_enabled_sink() is now a pointer. +The parameter change was introduced with commit 8fd52a21ab57 +("coresight: Make sysfs functional on topologies with per core sink"). + +In the upstream kernel, the call is removed with commit bb1860efc817 +("coresight: etm: perf: Sink selection using sysfs is deprecated"). +That commit alone would, however, likely not solve the problem. +It looks like at least two more commits would be needed. + +716f5652a131 coresight: etm: perf: Fix warning caused by etm_setup_aux failure +8e264c52e1da coresight: core: Allow the coresight core driver to be built as a module +39a7661dcf65 coresight: Fix uninitialised pointer bug in etm_setup_aux() + +Looking into the coresight code, I see several additional commits affecting +the sysfs interface since v5.4. I have no idea what would actually be needed +for stable code in v5.4.y, short of applying them all. + +With all this in mind, I would suggest to revert commit 8fd52a21ab57 +("coresight: Make sysfs functional on topologies with per core sink") +from v5.4.y, especially since it is not marked as bug fix or for stable. + +Signed-off-by: Sasha Levin +--- + drivers/hwtracing/coresight/coresight-priv.h | 3 +- + drivers/hwtracing/coresight/coresight.c | 62 +++++++++++--------- + 2 files changed, 36 insertions(+), 29 deletions(-) + +diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h +index dfd24b85a5775..82e563cdc8794 100644 +--- a/drivers/hwtracing/coresight/coresight-priv.h ++++ b/drivers/hwtracing/coresight/coresight-priv.h +@@ -147,8 +147,7 @@ static inline void coresight_write_reg_pair(void __iomem *addr, u64 val, + void coresight_disable_path(struct list_head *path); + int coresight_enable_path(struct list_head *path, u32 mode, void *sink_data); + struct coresight_device *coresight_get_sink(struct list_head *path); +-struct coresight_device * +-coresight_get_enabled_sink(struct coresight_device *source); ++struct coresight_device *coresight_get_enabled_sink(bool reset); + struct coresight_device *coresight_get_sink_by_id(u32 id); + struct list_head *coresight_build_path(struct coresight_device *csdev, + struct coresight_device *sink); +diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c +index 90ecd04a2f20b..0bbce0d291582 100644 +--- a/drivers/hwtracing/coresight/coresight.c ++++ b/drivers/hwtracing/coresight/coresight.c +@@ -481,46 +481,50 @@ struct coresight_device *coresight_get_sink(struct list_head *path) + return csdev; + } + +-static struct coresight_device * +-coresight_find_enabled_sink(struct coresight_device *csdev) ++static int coresight_enabled_sink(struct device *dev, const void *data) + { +- int i; +- struct coresight_device *sink; ++ const bool *reset = data; ++ struct coresight_device *csdev = to_coresight_device(dev); + + if ((csdev->type == CORESIGHT_DEV_TYPE_SINK || + csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) && +- csdev->activated) +- return csdev; +- +- /* +- * Recursively explore each port found on this element. +- */ +- for (i = 0; i < csdev->pdata->nr_outport; i++) { +- struct coresight_device *child_dev; ++ csdev->activated) { ++ /* ++ * Now that we have a handle on the sink for this session, ++ * disable the sysFS "enable_sink" flag so that possible ++ * concurrent perf session that wish to use another sink don't ++ * trip on it. Doing so has no ramification for the current ++ * session. ++ */ ++ if (*reset) ++ csdev->activated = false; + +- child_dev = csdev->pdata->conns[i].child_dev; +- if (child_dev) +- sink = coresight_find_enabled_sink(child_dev); +- if (sink) +- return sink; ++ return 1; + } + +- return NULL; ++ return 0; + } + + /** +- * coresight_get_enabled_sink - returns the first enabled sink using +- * connection based search starting from the source reference ++ * coresight_get_enabled_sink - returns the first enabled sink found on the bus ++ * @deactivate: Whether the 'enable_sink' flag should be reset + * +- * @source: Coresight source device reference ++ * When operated from perf the deactivate parameter should be set to 'true'. ++ * That way the "enabled_sink" flag of the sink that was selected can be reset, ++ * allowing for other concurrent perf sessions to choose a different sink. ++ * ++ * When operated from sysFS users have full control and as such the deactivate ++ * parameter should be set to 'false', hence mandating users to explicitly ++ * clear the flag. + */ +-struct coresight_device * +-coresight_get_enabled_sink(struct coresight_device *source) ++struct coresight_device *coresight_get_enabled_sink(bool deactivate) + { +- if (!source) +- return NULL; ++ struct device *dev = NULL; ++ ++ dev = bus_find_device(&coresight_bustype, NULL, &deactivate, ++ coresight_enabled_sink); + +- return coresight_find_enabled_sink(source); ++ return dev ? to_coresight_device(dev) : NULL; + } + + static int coresight_sink_by_id(struct device *dev, const void *data) +@@ -760,7 +764,11 @@ int coresight_enable(struct coresight_device *csdev) + goto out; + } + +- sink = coresight_get_enabled_sink(csdev); ++ /* ++ * Search for a valid sink for this session but don't reset the ++ * "enable_sink" flag in sysFS. Users get to do that explicitly. ++ */ ++ sink = coresight_get_enabled_sink(false); + if (!sink) { + ret = -EINVAL; + goto out; +-- +2.27.0 + diff --git a/queue-5.4/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch b/queue-5.4/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch new file mode 100644 index 00000000000..2954611062c --- /dev/null +++ b/queue-5.4/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch @@ -0,0 +1,75 @@ +From 05d487a4a2d69ecc35f77603fd5a28dd637f48ec Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 10 Oct 2020 11:25:39 +0800 +Subject: scsi: core: Don't start concurrent async scan on same host + +From: Ming Lei + +[ Upstream commit 831e3405c2a344018a18fcc2665acc5a38c3a707 ] + +The current scanning mechanism is supposed to fall back to a synchronous +host scan if an asynchronous scan is in progress. However, this rule isn't +strictly respected, scsi_prep_async_scan() doesn't hold scan_mutex when +checking shost->async_scan. When scsi_scan_host() is called concurrently, +two async scans on same host can be started and a hang in do_scan_async() +is observed. + +Fixes this issue by checking & setting shost->async_scan atomically with +shost->scan_mutex. + +Link: https://lore.kernel.org/r/20201010032539.426615-1-ming.lei@redhat.com +Cc: Christoph Hellwig +Cc: Ewan D. Milne +Cc: Hannes Reinecke +Cc: Bart Van Assche +Reviewed-by: Lee Duncan +Reviewed-by: Bart Van Assche +Signed-off-by: Ming Lei +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/scsi_scan.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c +index 058079f915f18..79232cef1af16 100644 +--- a/drivers/scsi/scsi_scan.c ++++ b/drivers/scsi/scsi_scan.c +@@ -1715,15 +1715,16 @@ static void scsi_sysfs_add_devices(struct Scsi_Host *shost) + */ + static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost) + { +- struct async_scan_data *data; ++ struct async_scan_data *data = NULL; + unsigned long flags; + + if (strncmp(scsi_scan_type, "sync", 4) == 0) + return NULL; + ++ mutex_lock(&shost->scan_mutex); + if (shost->async_scan) { + shost_printk(KERN_DEBUG, shost, "%s called twice\n", __func__); +- return NULL; ++ goto err; + } + + data = kmalloc(sizeof(*data), GFP_KERNEL); +@@ -1734,7 +1735,6 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost) + goto err; + init_completion(&data->prev_finished); + +- mutex_lock(&shost->scan_mutex); + spin_lock_irqsave(shost->host_lock, flags); + shost->async_scan = 1; + spin_unlock_irqrestore(shost->host_lock, flags); +@@ -1749,6 +1749,7 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost) + return data; + + err: ++ mutex_unlock(&shost->scan_mutex); + kfree(data); + return NULL; + } +-- +2.27.0 + diff --git a/queue-5.4/scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch b/queue-5.4/scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch new file mode 100644 index 00000000000..f6b0490624b --- /dev/null +++ b/queue-5.4/scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch @@ -0,0 +1,149 @@ +From fb3a2a235452fe3e56826069491b41d150b3c098 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 24 Oct 2020 19:13:55 -0500 +Subject: scsi: ibmvscsi: Fix potential race after loss of transport + +From: Tyrel Datwyler + +[ Upstream commit 665e0224a3d76f36da40bd9012270fa629aa42ed ] + +After a loss of transport due to an adapter migration or crash/disconnect +from the host partner there is a tiny window where we can race adjusting +the request_limit of the adapter. The request limit is atomically +increased/decreased to track the number of inflight requests against the +allowed limit of our VIOS partner. + +After a transport loss we set the request_limit to zero to reflect this +state. However, there is a window where the adapter may attempt to queue a +command because the transport loss event hasn't been fully processed yet +and request_limit is still greater than zero. The hypercall to send the +event will fail and the error path will increment the request_limit as a +result. If the adapter processes the transport event prior to this +increment the request_limit becomes out of sync with the adapter state and +can result in SCSI commands being submitted on the now reset connection +prior to an SRP Login resulting in a protocol violation. + +Fix this race by protecting request_limit with the host lock when changing +the value via atomic_set() to indicate no transport. + +Link: https://lore.kernel.org/r/20201025001355.4527-1-tyreld@linux.ibm.com +Signed-off-by: Tyrel Datwyler +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/ibmvscsi/ibmvscsi.c | 36 +++++++++++++++++++++++--------- + 1 file changed, 26 insertions(+), 10 deletions(-) + +diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c +index c5711c659b517..1ab0a61e3fb59 100644 +--- a/drivers/scsi/ibmvscsi/ibmvscsi.c ++++ b/drivers/scsi/ibmvscsi/ibmvscsi.c +@@ -806,6 +806,22 @@ static void purge_requests(struct ibmvscsi_host_data *hostdata, int error_code) + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + } + ++/** ++ * ibmvscsi_set_request_limit - Set the adapter request_limit in response to ++ * an adapter failure, reset, or SRP Login. Done under host lock to prevent ++ * race with SCSI command submission. ++ * @hostdata: adapter to adjust ++ * @limit: new request limit ++ */ ++static void ibmvscsi_set_request_limit(struct ibmvscsi_host_data *hostdata, int limit) ++{ ++ unsigned long flags; ++ ++ spin_lock_irqsave(hostdata->host->host_lock, flags); ++ atomic_set(&hostdata->request_limit, limit); ++ spin_unlock_irqrestore(hostdata->host->host_lock, flags); ++} ++ + /** + * ibmvscsi_reset_host - Reset the connection to the server + * @hostdata: struct ibmvscsi_host_data to reset +@@ -813,7 +829,7 @@ static void purge_requests(struct ibmvscsi_host_data *hostdata, int error_code) + static void ibmvscsi_reset_host(struct ibmvscsi_host_data *hostdata) + { + scsi_block_requests(hostdata->host); +- atomic_set(&hostdata->request_limit, 0); ++ ibmvscsi_set_request_limit(hostdata, 0); + + purge_requests(hostdata, DID_ERROR); + hostdata->action = IBMVSCSI_HOST_ACTION_RESET; +@@ -1146,13 +1162,13 @@ static void login_rsp(struct srp_event_struct *evt_struct) + dev_info(hostdata->dev, "SRP_LOGIN_REJ reason %u\n", + evt_struct->xfer_iu->srp.login_rej.reason); + /* Login failed. */ +- atomic_set(&hostdata->request_limit, -1); ++ ibmvscsi_set_request_limit(hostdata, -1); + return; + default: + dev_err(hostdata->dev, "Invalid login response typecode 0x%02x!\n", + evt_struct->xfer_iu->srp.login_rsp.opcode); + /* Login failed. */ +- atomic_set(&hostdata->request_limit, -1); ++ ibmvscsi_set_request_limit(hostdata, -1); + return; + } + +@@ -1163,7 +1179,7 @@ static void login_rsp(struct srp_event_struct *evt_struct) + * This value is set rather than added to request_limit because + * request_limit could have been set to -1 by this client. + */ +- atomic_set(&hostdata->request_limit, ++ ibmvscsi_set_request_limit(hostdata, + be32_to_cpu(evt_struct->xfer_iu->srp.login_rsp.req_lim_delta)); + + /* If we had any pending I/Os, kick them */ +@@ -1195,13 +1211,13 @@ static int send_srp_login(struct ibmvscsi_host_data *hostdata) + login->req_buf_fmt = cpu_to_be16(SRP_BUF_FORMAT_DIRECT | + SRP_BUF_FORMAT_INDIRECT); + +- spin_lock_irqsave(hostdata->host->host_lock, flags); + /* Start out with a request limit of 0, since this is negotiated in + * the login request we are just sending and login requests always + * get sent by the driver regardless of request_limit. + */ +- atomic_set(&hostdata->request_limit, 0); ++ ibmvscsi_set_request_limit(hostdata, 0); + ++ spin_lock_irqsave(hostdata->host->host_lock, flags); + rc = ibmvscsi_send_srp_event(evt_struct, hostdata, login_timeout * 2); + spin_unlock_irqrestore(hostdata->host->host_lock, flags); + dev_info(hostdata->dev, "sent SRP login\n"); +@@ -1781,7 +1797,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq, + return; + case VIOSRP_CRQ_XPORT_EVENT: /* Hypervisor telling us the connection is closed */ + scsi_block_requests(hostdata->host); +- atomic_set(&hostdata->request_limit, 0); ++ ibmvscsi_set_request_limit(hostdata, 0); + if (crq->format == 0x06) { + /* We need to re-setup the interpartition connection */ + dev_info(hostdata->dev, "Re-enabling adapter!\n"); +@@ -2137,12 +2153,12 @@ static void ibmvscsi_do_work(struct ibmvscsi_host_data *hostdata) + } + + hostdata->action = IBMVSCSI_HOST_ACTION_NONE; ++ spin_unlock_irqrestore(hostdata->host->host_lock, flags); + + if (rc) { +- atomic_set(&hostdata->request_limit, -1); ++ ibmvscsi_set_request_limit(hostdata, -1); + dev_err(hostdata->dev, "error after %s\n", action); + } +- spin_unlock_irqrestore(hostdata->host->host_lock, flags); + + scsi_unblock_requests(hostdata->host); + } +@@ -2226,7 +2242,7 @@ static int ibmvscsi_probe(struct vio_dev *vdev, const struct vio_device_id *id) + init_waitqueue_head(&hostdata->work_wait_q); + hostdata->host = host; + hostdata->dev = dev; +- atomic_set(&hostdata->request_limit, -1); ++ ibmvscsi_set_request_limit(hostdata, -1); + hostdata->host->max_sectors = IBMVSCSI_MAX_SECTORS_DEFAULT; + + if (map_persist_bufs(hostdata)) { +-- +2.27.0 + diff --git a/queue-5.4/series b/queue-5.4/series index 81166abbba2..4d18121499a 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -39,3 +39,25 @@ regulator-defer-probe-when-trying-to-get-voltage-from-unresolved-supply.patch spi-bcm2835-fix-gpio-cs-level-inversion.patch tracing-fix-out-of-bounds-write-in-get_trace_buf.patch futex-handle-transient-ownerless-rtmutex-state-correctly.patch +arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch +arm64-dts-meson-add-missing-g12-rng-clock.patch +x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch +of-fix-reserved-memory-overlap-detection.patch +drm-sun4i-frontend-rework-a-bit-the-phase-data.patch +drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch +drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch +blk-cgroup-fix-memleak-on-error-path.patch +blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch +scsi-core-don-t-start-concurrent-async-scan-on-same-.patch +drm-amdgpu-add-did-for-navi10-blockchain-sku.patch +scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch +vsock-use-ns_capable_noaudit-on-socket-create.patch +nvme-rdma-handle-unexpected-nvme-completion-data-len.patch +nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch +drm-vc4-drv-add-error-handding-for-bind.patch +acpi-nfit-fix-comparison-to-enxio.patch +usb-cdns3-gadget-suspicious-implicit-sign-extension.patch +drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch +drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch +arm64-smp-move-rcu_cpu_starting-earlier.patch +revert-coresight-make-sysfs-functional-on-topologies.patch diff --git a/queue-5.4/usb-cdns3-gadget-suspicious-implicit-sign-extension.patch b/queue-5.4/usb-cdns3-gadget-suspicious-implicit-sign-extension.patch new file mode 100644 index 00000000000..7b54db594fb --- /dev/null +++ b/queue-5.4/usb-cdns3-gadget-suspicious-implicit-sign-extension.patch @@ -0,0 +1,48 @@ +From 7fd33290e2e82995a82f897dedb8aa3d09dfd568 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Oct 2020 08:55:03 +0800 +Subject: usb: cdns3: gadget: suspicious implicit sign extension + +From: Peter Chen + +[ Upstream commit 5fca3f062879f8e5214c56f3e3e2be6727900f5d ] + +The code: +trb->length = cpu_to_le32(TRB_BURST_LEN(priv_ep->trb_burst_size) + | TRB_LEN(length)); + +TRB_BURST_LEN(priv_ep->trb_burst_size) may be overflow for int 32 if +priv_ep->trb_burst_size is equal or larger than 0x80; + +Below is the Coverity warning: +sign_extension: Suspicious implicit sign extension: priv_ep->trb_burst_size +with type u8 (8 bits, unsigned) is promoted in priv_ep->trb_burst_size << 24 +to type int (32 bits, signed), then sign-extended to type unsigned long +(64 bits, unsigned). If priv_ep->trb_burst_size << 24 is greater than 0x7FFFFFFF, +the upper bits of the result will all be 1. + +To fix it, it needs to add an explicit cast to unsigned int type for ((p) << 24). + +Reviewed-by: Jun Li +Signed-off-by: Peter Chen +Signed-off-by: Sasha Levin +--- + drivers/usb/cdns3/gadget.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/usb/cdns3/gadget.h b/drivers/usb/cdns3/gadget.h +index bc4024041ef26..ec5c05454531d 100644 +--- a/drivers/usb/cdns3/gadget.h ++++ b/drivers/usb/cdns3/gadget.h +@@ -1057,7 +1057,7 @@ struct cdns3_trb { + #define TRB_TDL_SS_SIZE_GET(p) (((p) & GENMASK(23, 17)) >> 17) + + /* transfer_len bitmasks - bits 31:24 */ +-#define TRB_BURST_LEN(p) (((p) << 24) & GENMASK(31, 24)) ++#define TRB_BURST_LEN(p) ((unsigned int)((p) << 24) & GENMASK(31, 24)) + #define TRB_BURST_LEN_GET(p) (((p) & GENMASK(31, 24)) >> 24) + + /* Data buffer pointer bitmasks*/ +-- +2.27.0 + diff --git a/queue-5.4/vsock-use-ns_capable_noaudit-on-socket-create.patch b/queue-5.4/vsock-use-ns_capable_noaudit-on-socket-create.patch new file mode 100644 index 00000000000..7d154bd64a9 --- /dev/null +++ b/queue-5.4/vsock-use-ns_capable_noaudit-on-socket-create.patch @@ -0,0 +1,46 @@ +From ed7d8d606cf25afa31c1a473c61fbad9dbf29f80 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 23 Oct 2020 16:37:57 +0200 +Subject: vsock: use ns_capable_noaudit() on socket create + +From: Jeff Vander Stoep + +[ Upstream commit af545bb5ee53f5261db631db2ac4cde54038bdaf ] + +During __vsock_create() CAP_NET_ADMIN is used to determine if the +vsock_sock->trusted should be set to true. This value is used later +for determing if a remote connection should be allowed to connect +to a restricted VM. Unfortunately, if the caller doesn't have +CAP_NET_ADMIN, an audit message such as an selinux denial is +generated even if the caller does not want a trusted socket. + +Logging errors on success is confusing. To avoid this, switch the +capable(CAP_NET_ADMIN) check to the noaudit version. + +Reported-by: Roman Kiryanov +https://android-review.googlesource.com/c/device/generic/goldfish/+/1468545/ +Signed-off-by: Jeff Vander Stoep +Reviewed-by: James Morris +Link: https://lore.kernel.org/r/20201023143757.377574-1-jeffv@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/vmw_vsock/af_vsock.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c +index 7bd6c8199ca67..3a074a03d3820 100644 +--- a/net/vmw_vsock/af_vsock.c ++++ b/net/vmw_vsock/af_vsock.c +@@ -621,7 +621,7 @@ struct sock *__vsock_create(struct net *net, + vsk->owner = get_cred(psk->owner); + vsk->connect_timeout = psk->connect_timeout; + } else { +- vsk->trusted = capable(CAP_NET_ADMIN); ++ vsk->trusted = ns_capable_noaudit(&init_user_ns, CAP_NET_ADMIN); + vsk->owner = get_current_cred(); + vsk->connect_timeout = VSOCK_DEFAULT_CONNECT_TIMEOUT; + } +-- +2.27.0 + diff --git a/queue-5.4/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch b/queue-5.4/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch new file mode 100644 index 00000000000..afbf50a6d1f --- /dev/null +++ b/queue-5.4/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch @@ -0,0 +1,50 @@ +From c5b2543080800a21bbbb9316647ac63d84f6a3e7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 14 Oct 2020 17:24:28 +0800 +Subject: x86/kexec: Use up-to-dated screen_info copy to fill boot params + +From: Kairui Song + +[ Upstream commit afc18069a2cb7ead5f86623a5f3d4ad6e21f940d ] + +kexec_file_load() currently reuses the old boot_params.screen_info, +but if drivers have change the hardware state, boot_param.screen_info +could contain invalid info. + +For example, the video type might be no longer VGA, or the frame buffer +address might be changed. If the kexec kernel keeps using the old screen_info, +kexec'ed kernel may attempt to write to an invalid framebuffer +memory region. + +There are two screen_info instances globally available, boot_params.screen_info +and screen_info. Later one is a copy, and is updated by drivers. + +So let kexec_file_load use the updated copy. + +[ mingo: Tidied up the changelog. ] + +Signed-off-by: Kairui Song +Signed-off-by: Ingo Molnar +Link: https://lore.kernel.org/r/20201014092429.1415040-2-kasong@redhat.com +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/kexec-bzimage64.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c +index d2f4e706a428c..b8b3b84308edc 100644 +--- a/arch/x86/kernel/kexec-bzimage64.c ++++ b/arch/x86/kernel/kexec-bzimage64.c +@@ -210,8 +210,7 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params, + params->hdr.hardware_subarch = boot_params.hdr.hardware_subarch; + + /* Copying screen_info will do? */ +- memcpy(¶ms->screen_info, &boot_params.screen_info, +- sizeof(struct screen_info)); ++ memcpy(¶ms->screen_info, &screen_info, sizeof(struct screen_info)); + + /* Fill in memsize later */ + params->screen_info.ext_mem_k = 0; +-- +2.27.0 + -- 2.47.3