]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 5.9
authorSasha Levin <sashal@kernel.org>
Sun, 8 Nov 2020 23:14:01 +0000 (18:14 -0500)
committerSasha Levin <sashal@kernel.org>
Sun, 8 Nov 2020 23:15:15 +0000 (18:15 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
34 files changed:
queue-5.9/acpi-nfit-fix-comparison-to-enxio.patch [new file with mode: 0644]
queue-5.9/arm-dts-mmp3-add-power-domain-for-the-camera.patch [new file with mode: 0644]
queue-5.9/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch [new file with mode: 0644]
queue-5.9/arm64-dts-amlogic-add-missing-ethernet-reset-id.patch [new file with mode: 0644]
queue-5.9/arm64-dts-amlogic-meson-g12-use-the-g12a-specific-dw.patch [new file with mode: 0644]
queue-5.9/arm64-dts-meson-add-missing-g12-rng-clock.patch [new file with mode: 0644]
queue-5.9/arm64-smp-move-rcu_cpu_starting-earlier.patch [new file with mode: 0644]
queue-5.9/blk-cgroup-fix-memleak-on-error-path.patch [new file with mode: 0644]
queue-5.9/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch [new file with mode: 0644]
queue-5.9/btrfs-add-a-helper-to-read-the-tree_root-commit-root.patch [new file with mode: 0644]
queue-5.9/btrfs-drop-the-path-before-adding-qgroup-items-when-.patch [new file with mode: 0644]
queue-5.9/drm-amd-display-adding-ddc_gpio_vga_reg_list-to-ddc-.patch [new file with mode: 0644]
queue-5.9/drm-amd-display-fixed-panic-during-seamless-boot.patch [new file with mode: 0644]
queue-5.9/drm-amdgpu-add-did-for-navi10-blockchain-sku.patch [new file with mode: 0644]
queue-5.9/drm-amdgpu-disable-dcn-and-vcn-for-navi10-blockchain.patch [new file with mode: 0644]
queue-5.9/drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch [new file with mode: 0644]
queue-5.9/drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch [new file with mode: 0644]
queue-5.9/drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch [new file with mode: 0644]
queue-5.9/drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch [new file with mode: 0644]
queue-5.9/drm-sun4i-frontend-rework-a-bit-the-phase-data.patch [new file with mode: 0644]
queue-5.9/drm-v3d-fix-double-free-in-v3d_submit_cl_ioctl.patch [new file with mode: 0644]
queue-5.9/drm-vc4-drv-add-error-handding-for-bind.patch [new file with mode: 0644]
queue-5.9/hyperv_fb-update-screen_info-after-removing-old-fram.patch [new file with mode: 0644]
queue-5.9/io_uring-don-t-miss-setting-io_wq_work_concurrent.patch [new file with mode: 0644]
queue-5.9/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch [new file with mode: 0644]
queue-5.9/nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch [new file with mode: 0644]
queue-5.9/of-fix-reserved-memory-overlap-detection.patch [new file with mode: 0644]
queue-5.9/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch [new file with mode: 0644]
queue-5.9/scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch [new file with mode: 0644]
queue-5.9/series
queue-5.9/staging-mmal-vchiq-fix-memory-leak-for-vchiq_instanc.patch [new file with mode: 0644]
queue-5.9/usb-cdns3-gadget-suspicious-implicit-sign-extension.patch [new file with mode: 0644]
queue-5.9/vsock-use-ns_capable_noaudit-on-socket-create.patch [new file with mode: 0644]
queue-5.9/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch [new file with mode: 0644]

diff --git a/queue-5.9/acpi-nfit-fix-comparison-to-enxio.patch b/queue-5.9/acpi-nfit-fix-comparison-to-enxio.patch
new file mode 100644 (file)
index 0000000..7c13b9b
--- /dev/null
@@ -0,0 +1,38 @@
+From 8f37f306cc875abb1e2a692503c316773fbd6f4a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 27 Oct 2020 21:49:01 +0800
+Subject: ACPI: NFIT: Fix comparison to '-ENXIO'
+
+From: Zhang Qilong <zhangqilong3@huawei.com>
+
+[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ]
+
+Initial value of rc is '-ENXIO', and we should
+use the initial value to check it.
+
+Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
+Reviewed-by: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
+Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
+[ rjw: Subject edit ]
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 26dd208a0d636..103ae7401f957 100644
+--- a/drivers/acpi/nfit/core.c
++++ b/drivers/acpi/nfit/core.c
+@@ -1564,7 +1564,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.9/arm-dts-mmp3-add-power-domain-for-the-camera.patch b/queue-5.9/arm-dts-mmp3-add-power-domain-for-the-camera.patch
new file mode 100644 (file)
index 0000000..1af8a4d
--- /dev/null
@@ -0,0 +1,47 @@
+From 1e8ed60d3d29c277619523da40b88da23fd6cdd2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 26 Sep 2020 01:48:04 +0200
+Subject: ARM: dts: mmp3: Add power domain for the camera
+
+From: Lubomir Rintel <lkundrak@v3.sk>
+
+[ Upstream commit 202f8e5c4975a95babf3bcdfb2c18952f06b030a ]
+
+The camera interfaces on MMP3 are on a separate power island that needs
+to be turned on for them to operate and, ideally, turned off when the
+cameras are not in use.
+
+This hooks the power island with the camera interfaces in the device
+tree.
+
+Link: https://lore.kernel.org/r/20200925234805.228251-2-lkundrak@v3.sk
+Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/mmp3.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm/boot/dts/mmp3.dtsi b/arch/arm/boot/dts/mmp3.dtsi
+index cc4efd0efabd2..4ae630d37d094 100644
+--- a/arch/arm/boot/dts/mmp3.dtsi
++++ b/arch/arm/boot/dts/mmp3.dtsi
+@@ -296,6 +296,7 @@
+                               interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+                               clocks = <&soc_clocks MMP2_CLK_CCIC0>;
+                               clock-names = "axi";
++                              power-domains = <&soc_clocks MMP3_POWER_DOMAIN_CAMERA>;
+                               #clock-cells = <0>;
+                               clock-output-names = "mclk";
+                               status = "disabled";
+@@ -307,6 +308,7 @@
+                               interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+                               clocks = <&soc_clocks MMP2_CLK_CCIC1>;
+                               clock-names = "axi";
++                              power-domains = <&soc_clocks MMP3_POWER_DOMAIN_CAMERA>;
+                               #clock-cells = <0>;
+                               clock-output-names = "mclk";
+                               status = "disabled";
+-- 
+2.27.0
+
diff --git a/queue-5.9/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch b/queue-5.9/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch
new file mode 100644 (file)
index 0000000..0cab554
--- /dev/null
@@ -0,0 +1,43 @@
+From 819c3d6f223c51b2abdc64fc51847f4a3eaaff8b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <peron.clem@gmail.com>
+
+[ 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 <peron.clem@gmail.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 0f95a6ef8543a..1c5a666c54b53 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.9/arm64-dts-amlogic-add-missing-ethernet-reset-id.patch b/queue-5.9/arm64-dts-amlogic-add-missing-ethernet-reset-id.patch
new file mode 100644 (file)
index 0000000..12c5ba5
--- /dev/null
@@ -0,0 +1,74 @@
+From 2d8135294267a379b5ce618a7b4b3cb7670f5c2b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 20 Oct 2020 14:01:41 +0200
+Subject: arm64: dts: amlogic: add missing ethernet reset ID
+
+From: Anand Moon <linux.amoon@gmail.com>
+
+[ Upstream commit f3362f0c18174a1f334a419ab7d567a36bd1b3f3 ]
+
+Add reset external reset of the ethernet mac controller
+
+Signed-off-by: Anand Moon <linux.amoon@gmail.com>
+Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
+Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Link: https://lore.kernel.org/r/20201020120141.298240-1-jbrunet@baylibre.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/amlogic/meson-axg.dtsi        | 2 ++
+ arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 ++
+ arch/arm64/boot/dts/amlogic/meson-gx.dtsi         | 3 +++
+ 3 files changed, 7 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+index b9efc8469265d..8e134cb470d3b 100644
+--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
++++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+@@ -187,6 +187,8 @@
+                                     "timing-adjustment";
+                       rx-fifo-depth = <4096>;
+                       tx-fifo-depth = <2048>;
++                      resets = <&reset RESET_ETHERNET>;
++                      reset-names = "stmmaceth";
+                       status = "disabled";
+               };
+diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+index c95ebe6151766..8514fe6a275a3 100644
+--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
++++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+@@ -224,6 +224,8 @@
+                                     "timing-adjustment";
+                       rx-fifo-depth = <4096>;
+                       tx-fifo-depth = <2048>;
++                      resets = <&reset RESET_ETHERNET>;
++                      reset-names = "stmmaceth";
+                       status = "disabled";
+                       mdio0: mdio {
+diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+index 0edd137151f89..726b91d3a905a 100644
+--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
++++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+@@ -13,6 +13,7 @@
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/meson-gxbb-power.h>
++#include <dt-bindings/reset/amlogic,meson-gxbb-reset.h>
+ #include <dt-bindings/thermal/thermal.h>
+ / {
+@@ -575,6 +576,8 @@
+                       interrupt-names = "macirq";
+                       rx-fifo-depth = <4096>;
+                       tx-fifo-depth = <2048>;
++                      resets = <&reset RESET_ETHERNET>;
++                      reset-names = "stmmaceth";
+                       power-domains = <&pwrc PWRC_GXBB_ETHERNET_MEM_ID>;
+                       status = "disabled";
+               };
+-- 
+2.27.0
+
diff --git a/queue-5.9/arm64-dts-amlogic-meson-g12-use-the-g12a-specific-dw.patch b/queue-5.9/arm64-dts-amlogic-meson-g12-use-the-g12a-specific-dw.patch
new file mode 100644 (file)
index 0000000..ba1b609
--- /dev/null
@@ -0,0 +1,43 @@
+From 7483e40ef9f09e34328f4cc27972e8809fdc61b5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 25 Sep 2020 23:17:43 +0200
+Subject: arm64: dts: amlogic: meson-g12: use the G12A specific dwmac
+ compatible
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+[ Upstream commit 1fdc97ae450ede2b4911d6737a57e6fca63b5f4a ]
+
+We have a dedicated "amlogic,meson-g12a-dwmac" compatible string for the
+Ethernet controller since commit 3efdb92426bf4 ("dt-bindings: net:
+dwmac-meson: Add a compatible string for G12A onwards").
+Using the AXG compatible string worked fine so far because the
+dwmac-meson8b driver doesn't handle the newly introduced register bits
+for G12A. However, once that changes the driver must be probed with the
+correct compatible string to manage these new register bits.
+
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Link: https://lore.kernel.org/r/20200925211743.537496-1-martin.blumenstingl@googlemail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+index 81f490e404ca5..c95ebe6151766 100644
+--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
++++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+@@ -209,7 +209,7 @@
+               };
+               ethmac: ethernet@ff3f0000 {
+-                      compatible = "amlogic,meson-axg-dwmac",
++                      compatible = "amlogic,meson-g12a-dwmac",
+                                    "snps,dwmac-3.70a",
+                                    "snps,dwmac";
+                       reg = <0x0 0xff3f0000 0x0 0x10000>,
+-- 
+2.27.0
+
diff --git a/queue-5.9/arm64-dts-meson-add-missing-g12-rng-clock.patch b/queue-5.9/arm64-dts-meson-add-missing-g12-rng-clock.patch
new file mode 100644 (file)
index 0000000..5705d5e
--- /dev/null
@@ -0,0 +1,40 @@
+From 6646e77d8866a16deb5cf66a9027afc1f27987a4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 25 Sep 2020 01:43:53 -0700
+Subject: arm64: dts: meson: add missing g12 rng clock
+
+From: Scott K Logan <logans@cottsay.net>
+
+[ 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 <logans@cottsay.net>
+Suggested-by: Neil Armstrong <narmstrong@baylibre.com>
+Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
+Signed-off-by: Kevin Hilman <khilman@baylibre.com>
+Link: https://lore.kernel.org/r/520a1a8ec7a958b3d918d89563ec7e93a4100a45.camel@cottsay.net
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 1e83ec5b8c91a..81f490e404ca5 100644
+--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
++++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+@@ -282,6 +282,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.9/arm64-smp-move-rcu_cpu_starting-earlier.patch b/queue-5.9/arm64-smp-move-rcu_cpu_starting-earlier.patch
new file mode 100644 (file)
index 0000000..b0adc0e
--- /dev/null
@@ -0,0 +1,67 @@
+From fbea36661357dfdd8567565f59f8bd007366ec8d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 28 Oct 2020 14:26:14 -0400
+Subject: arm64/smp: Move rcu_cpu_starting() earlier
+
+From: Qian Cai <cai@redhat.com>
+
+[ 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 <cai@redhat.com>
+Acked-by: Paul E. McKenney <paulmck@kernel.org>
+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 <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 355ee9eed4dde..98c059b6bacae 100644
+--- a/arch/arm64/kernel/smp.c
++++ b/arch/arm64/kernel/smp.c
+@@ -213,6 +213,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.9/blk-cgroup-fix-memleak-on-error-path.patch b/queue-5.9/blk-cgroup-fix-memleak-on-error-path.patch
new file mode 100644 (file)
index 0000000..0075a17
--- /dev/null
@@ -0,0 +1,35 @@
+From 4f283241cf5890e20d442ce9062156445a8644cf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 16:58:41 -0400
+Subject: blk-cgroup: Fix memleak on error path
+
+From: Gabriel Krisman Bertazi <krisman@collabora.com>
+
+[ 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 <tj@kernel.org>
+Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/blk-cgroup.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
+index c195365c98172..7b2df042220d4 100644
+--- a/block/blk-cgroup.c
++++ b/block/blk-cgroup.c
+@@ -654,6 +654,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.9/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch b/queue-5.9/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch
new file mode 100644 (file)
index 0000000..503edba
--- /dev/null
@@ -0,0 +1,82 @@
+From e6073d3e1406ca04aded2ca4234057f8dd61bbe9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 16:58:42 -0400
+Subject: blk-cgroup: Pre-allocate tree node on blkg_conf_prep
+
+From: Gabriel Krisman Bertazi <krisman@collabora.com>
+
+[ 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 <tj@kernel.org>
+Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 7b2df042220d4..c85fbb666e40a 100644
+--- a/block/blk-cgroup.c
++++ b/block/blk-cgroup.c
+@@ -648,6 +648,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);
+@@ -655,7 +661,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) {
+@@ -664,10 +670,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;
+       }
+@@ -677,6 +685,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.9/btrfs-add-a-helper-to-read-the-tree_root-commit-root.patch b/queue-5.9/btrfs-add-a-helper-to-read-the-tree_root-commit-root.patch
new file mode 100644 (file)
index 0000000..4dc5188
--- /dev/null
@@ -0,0 +1,424 @@
+From 495675c94e332f5aebcd68302d8bb20f158047a7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 19 Oct 2020 16:02:31 -0400
+Subject: btrfs: add a helper to read the tree_root commit root for backref
+ lookup
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit 49d11bead7d596e031fbd34051d8765587cd645b ]
+
+I got the following lockdep splat with tree locks converted to rwsem
+patches on btrfs/104:
+
+  ======================================================
+  WARNING: possible circular locking dependency detected
+  5.9.0+ #102 Not tainted
+  ------------------------------------------------------
+  btrfs-cleaner/903 is trying to acquire lock:
+  ffff8e7fab6ffe30 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x32/0x170
+
+  but task is already holding lock:
+  ffff8e7fab628a88 (&fs_info->commit_root_sem){++++}-{3:3}, at: btrfs_find_all_roots+0x41/0x80
+
+  which lock already depends on the new lock.
+
+  the existing dependency chain (in reverse order) is:
+
+  -> #3 (&fs_info->commit_root_sem){++++}-{3:3}:
+        down_read+0x40/0x130
+        caching_thread+0x53/0x5a0
+        btrfs_work_helper+0xfa/0x520
+        process_one_work+0x238/0x540
+        worker_thread+0x55/0x3c0
+        kthread+0x13a/0x150
+        ret_from_fork+0x1f/0x30
+
+  -> #2 (&caching_ctl->mutex){+.+.}-{3:3}:
+        __mutex_lock+0x7e/0x7b0
+        btrfs_cache_block_group+0x1e0/0x510
+        find_free_extent+0xb6e/0x12f0
+        btrfs_reserve_extent+0xb3/0x1b0
+        btrfs_alloc_tree_block+0xb1/0x330
+        alloc_tree_block_no_bg_flush+0x4f/0x60
+        __btrfs_cow_block+0x11d/0x580
+        btrfs_cow_block+0x10c/0x220
+        commit_cowonly_roots+0x47/0x2e0
+        btrfs_commit_transaction+0x595/0xbd0
+        sync_filesystem+0x74/0x90
+        generic_shutdown_super+0x22/0x100
+        kill_anon_super+0x14/0x30
+        btrfs_kill_super+0x12/0x20
+        deactivate_locked_super+0x36/0xa0
+        cleanup_mnt+0x12d/0x190
+        task_work_run+0x5c/0xa0
+        exit_to_user_mode_prepare+0x1df/0x200
+        syscall_exit_to_user_mode+0x54/0x280
+        entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+  -> #1 (&space_info->groups_sem){++++}-{3:3}:
+        down_read+0x40/0x130
+        find_free_extent+0x2ed/0x12f0
+        btrfs_reserve_extent+0xb3/0x1b0
+        btrfs_alloc_tree_block+0xb1/0x330
+        alloc_tree_block_no_bg_flush+0x4f/0x60
+        __btrfs_cow_block+0x11d/0x580
+        btrfs_cow_block+0x10c/0x220
+        commit_cowonly_roots+0x47/0x2e0
+        btrfs_commit_transaction+0x595/0xbd0
+        sync_filesystem+0x74/0x90
+        generic_shutdown_super+0x22/0x100
+        kill_anon_super+0x14/0x30
+        btrfs_kill_super+0x12/0x20
+        deactivate_locked_super+0x36/0xa0
+        cleanup_mnt+0x12d/0x190
+        task_work_run+0x5c/0xa0
+        exit_to_user_mode_prepare+0x1df/0x200
+        syscall_exit_to_user_mode+0x54/0x280
+        entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+  -> #0 (btrfs-root-00){++++}-{3:3}:
+        __lock_acquire+0x1167/0x2150
+        lock_acquire+0xb9/0x3d0
+        down_read_nested+0x43/0x130
+        __btrfs_tree_read_lock+0x32/0x170
+        __btrfs_read_lock_root_node+0x3a/0x50
+        btrfs_search_slot+0x614/0x9d0
+        btrfs_find_root+0x35/0x1b0
+        btrfs_read_tree_root+0x61/0x120
+        btrfs_get_root_ref+0x14b/0x600
+        find_parent_nodes+0x3e6/0x1b30
+        btrfs_find_all_roots_safe+0xb4/0x130
+        btrfs_find_all_roots+0x60/0x80
+        btrfs_qgroup_trace_extent_post+0x27/0x40
+        btrfs_add_delayed_data_ref+0x3fd/0x460
+        btrfs_free_extent+0x42/0x100
+        __btrfs_mod_ref+0x1d7/0x2f0
+        walk_up_proc+0x11c/0x400
+        walk_up_tree+0xf0/0x180
+        btrfs_drop_snapshot+0x1c7/0x780
+        btrfs_clean_one_deleted_snapshot+0xfb/0x110
+        cleaner_kthread+0xd4/0x140
+        kthread+0x13a/0x150
+        ret_from_fork+0x1f/0x30
+
+  other info that might help us debug this:
+
+  Chain exists of:
+    btrfs-root-00 --> &caching_ctl->mutex --> &fs_info->commit_root_sem
+
+   Possible unsafe locking scenario:
+
+        CPU0                    CPU1
+        ----                    ----
+    lock(&fs_info->commit_root_sem);
+                                lock(&caching_ctl->mutex);
+                                lock(&fs_info->commit_root_sem);
+    lock(btrfs-root-00);
+
+   *** DEADLOCK ***
+
+  3 locks held by btrfs-cleaner/903:
+   #0: ffff8e7fab628838 (&fs_info->cleaner_mutex){+.+.}-{3:3}, at: cleaner_kthread+0x6e/0x140
+   #1: ffff8e7faadac640 (sb_internal){.+.+}-{0:0}, at: start_transaction+0x40b/0x5c0
+   #2: ffff8e7fab628a88 (&fs_info->commit_root_sem){++++}-{3:3}, at: btrfs_find_all_roots+0x41/0x80
+
+  stack backtrace:
+  CPU: 0 PID: 903 Comm: btrfs-cleaner Not tainted 5.9.0+ #102
+  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
+  Call Trace:
+   dump_stack+0x8b/0xb0
+   check_noncircular+0xcf/0xf0
+   __lock_acquire+0x1167/0x2150
+   ? __bfs+0x42/0x210
+   lock_acquire+0xb9/0x3d0
+   ? __btrfs_tree_read_lock+0x32/0x170
+   down_read_nested+0x43/0x130
+   ? __btrfs_tree_read_lock+0x32/0x170
+   __btrfs_tree_read_lock+0x32/0x170
+   __btrfs_read_lock_root_node+0x3a/0x50
+   btrfs_search_slot+0x614/0x9d0
+   ? find_held_lock+0x2b/0x80
+   btrfs_find_root+0x35/0x1b0
+   ? do_raw_spin_unlock+0x4b/0xa0
+   btrfs_read_tree_root+0x61/0x120
+   btrfs_get_root_ref+0x14b/0x600
+   find_parent_nodes+0x3e6/0x1b30
+   btrfs_find_all_roots_safe+0xb4/0x130
+   btrfs_find_all_roots+0x60/0x80
+   btrfs_qgroup_trace_extent_post+0x27/0x40
+   btrfs_add_delayed_data_ref+0x3fd/0x460
+   btrfs_free_extent+0x42/0x100
+   __btrfs_mod_ref+0x1d7/0x2f0
+   walk_up_proc+0x11c/0x400
+   walk_up_tree+0xf0/0x180
+   btrfs_drop_snapshot+0x1c7/0x780
+   ? btrfs_clean_one_deleted_snapshot+0x73/0x110
+   btrfs_clean_one_deleted_snapshot+0xfb/0x110
+   cleaner_kthread+0xd4/0x140
+   ? btrfs_alloc_root+0x50/0x50
+   kthread+0x13a/0x150
+   ? kthread_create_worker_on_cpu+0x40/0x40
+   ret_from_fork+0x1f/0x30
+  BTRFS info (device sdb): disk space caching is enabled
+  BTRFS info (device sdb): has skinny extents
+
+This happens because qgroups does a backref lookup when we create a
+delayed ref.  From here it may have to look up a root from an indirect
+ref, which does a normal lookup on the tree_root, which takes the read
+lock on the tree_root nodes.
+
+To fix this we need to add a variant for looking up roots that searches
+the commit root of the tree_root.  Then when we do the backref search
+using the commit root we are sure to not take any locks on the tree_root
+nodes.  This gets rid of the lockdep splat when running btrfs/104.
+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/backref.c |  13 ++++-
+ fs/btrfs/disk-io.c | 139 ++++++++++++++++++++++++++++++++-------------
+ fs/btrfs/disk-io.h |   3 +
+ 3 files changed, 114 insertions(+), 41 deletions(-)
+
+diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
+index ea1c28ccb44ff..b948df7a929eb 100644
+--- a/fs/btrfs/backref.c
++++ b/fs/btrfs/backref.c
+@@ -544,7 +544,18 @@ static int resolve_indirect_ref(struct btrfs_fs_info *fs_info,
+       int level = ref->level;
+       struct btrfs_key search_key = ref->key_for_search;
+-      root = btrfs_get_fs_root(fs_info, ref->root_id, false);
++      /*
++       * If we're search_commit_root we could possibly be holding locks on
++       * other tree nodes.  This happens when qgroups does backref walks when
++       * adding new delayed refs.  To deal with this we need to look in cache
++       * for the root, and if we don't find it then we need to search the
++       * tree_root's commit root, thus the btrfs_get_fs_root_commit_root usage
++       * here.
++       */
++      if (path->search_commit_root)
++              root = btrfs_get_fs_root_commit_root(fs_info, path, ref->root_id);
++      else
++              root = btrfs_get_fs_root(fs_info, ref->root_id, false);
+       if (IS_ERR(root)) {
+               ret = PTR_ERR(root);
+               goto out_free;
+diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
+index 7882c07645014..2a0a1c032a72c 100644
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -1338,32 +1338,26 @@ int btrfs_add_log_tree(struct btrfs_trans_handle *trans,
+       return 0;
+ }
+-struct btrfs_root *btrfs_read_tree_root(struct btrfs_root *tree_root,
+-                                      struct btrfs_key *key)
++static struct btrfs_root *read_tree_root_path(struct btrfs_root *tree_root,
++                                            struct btrfs_path *path,
++                                            struct btrfs_key *key)
+ {
+       struct btrfs_root *root;
+       struct btrfs_fs_info *fs_info = tree_root->fs_info;
+-      struct btrfs_path *path;
+       u64 generation;
+       int ret;
+       int level;
+-      path = btrfs_alloc_path();
+-      if (!path)
+-              return ERR_PTR(-ENOMEM);
+-
+       root = btrfs_alloc_root(fs_info, key->objectid, GFP_NOFS);
+-      if (!root) {
+-              ret = -ENOMEM;
+-              goto alloc_fail;
+-      }
++      if (!root)
++              return ERR_PTR(-ENOMEM);
+       ret = btrfs_find_root(tree_root, key, path,
+                             &root->root_item, &root->root_key);
+       if (ret) {
+               if (ret > 0)
+                       ret = -ENOENT;
+-              goto find_fail;
++              goto fail;
+       }
+       generation = btrfs_root_generation(&root->root_item);
+@@ -1374,21 +1368,31 @@ struct btrfs_root *btrfs_read_tree_root(struct btrfs_root *tree_root,
+       if (IS_ERR(root->node)) {
+               ret = PTR_ERR(root->node);
+               root->node = NULL;
+-              goto find_fail;
++              goto fail;
+       } else if (!btrfs_buffer_uptodate(root->node, generation, 0)) {
+               ret = -EIO;
+-              goto find_fail;
++              goto fail;
+       }
+       root->commit_root = btrfs_root_node(root);
+-out:
+-      btrfs_free_path(path);
+       return root;
+-
+-find_fail:
++fail:
+       btrfs_put_root(root);
+-alloc_fail:
+-      root = ERR_PTR(ret);
+-      goto out;
++      return ERR_PTR(ret);
++}
++
++struct btrfs_root *btrfs_read_tree_root(struct btrfs_root *tree_root,
++                                      struct btrfs_key *key)
++{
++      struct btrfs_root *root;
++      struct btrfs_path *path;
++
++      path = btrfs_alloc_path();
++      if (!path)
++              return ERR_PTR(-ENOMEM);
++      root = read_tree_root_path(tree_root, path, key);
++      btrfs_free_path(path);
++
++      return root;
+ }
+ /*
+@@ -1476,6 +1480,31 @@ static struct btrfs_root *btrfs_lookup_fs_root(struct btrfs_fs_info *fs_info,
+       return root;
+ }
++static struct btrfs_root *btrfs_get_global_root(struct btrfs_fs_info *fs_info,
++                                              u64 objectid)
++{
++      if (objectid == BTRFS_ROOT_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->tree_root);
++      if (objectid == BTRFS_EXTENT_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->extent_root);
++      if (objectid == BTRFS_CHUNK_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->chunk_root);
++      if (objectid == BTRFS_DEV_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->dev_root);
++      if (objectid == BTRFS_CSUM_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->csum_root);
++      if (objectid == BTRFS_QUOTA_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->quota_root) ?
++                      fs_info->quota_root : ERR_PTR(-ENOENT);
++      if (objectid == BTRFS_UUID_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->uuid_root) ?
++                      fs_info->uuid_root : ERR_PTR(-ENOENT);
++      if (objectid == BTRFS_FREE_SPACE_TREE_OBJECTID)
++              return btrfs_grab_root(fs_info->free_space_root) ?
++                      fs_info->free_space_root : ERR_PTR(-ENOENT);
++      return NULL;
++}
++
+ int btrfs_insert_fs_root(struct btrfs_fs_info *fs_info,
+                        struct btrfs_root *root)
+ {
+@@ -1573,25 +1602,9 @@ static struct btrfs_root *btrfs_get_root_ref(struct btrfs_fs_info *fs_info,
+       struct btrfs_key key;
+       int ret;
+-      if (objectid == BTRFS_ROOT_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->tree_root);
+-      if (objectid == BTRFS_EXTENT_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->extent_root);
+-      if (objectid == BTRFS_CHUNK_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->chunk_root);
+-      if (objectid == BTRFS_DEV_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->dev_root);
+-      if (objectid == BTRFS_CSUM_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->csum_root);
+-      if (objectid == BTRFS_QUOTA_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->quota_root) ?
+-                      fs_info->quota_root : ERR_PTR(-ENOENT);
+-      if (objectid == BTRFS_UUID_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->uuid_root) ?
+-                      fs_info->uuid_root : ERR_PTR(-ENOENT);
+-      if (objectid == BTRFS_FREE_SPACE_TREE_OBJECTID)
+-              return btrfs_grab_root(fs_info->free_space_root) ?
+-                      fs_info->free_space_root : ERR_PTR(-ENOENT);
++      root = btrfs_get_global_root(fs_info, objectid);
++      if (root)
++              return root;
+ again:
+       root = btrfs_lookup_fs_root(fs_info, objectid);
+       if (root) {
+@@ -1676,6 +1689,52 @@ struct btrfs_root *btrfs_get_new_fs_root(struct btrfs_fs_info *fs_info,
+       return btrfs_get_root_ref(fs_info, objectid, anon_dev, true);
+ }
++/*
++ * btrfs_get_fs_root_commit_root - return a root for the given objectid
++ * @fs_info:  the fs_info
++ * @objectid: the objectid we need to lookup
++ *
++ * This is exclusively used for backref walking, and exists specifically because
++ * of how qgroups does lookups.  Qgroups will do a backref lookup at delayed ref
++ * creation time, which means we may have to read the tree_root in order to look
++ * up a fs root that is not in memory.  If the root is not in memory we will
++ * read the tree root commit root and look up the fs root from there.  This is a
++ * temporary root, it will not be inserted into the radix tree as it doesn't
++ * have the most uptodate information, it'll simply be discarded once the
++ * backref code is finished using the root.
++ */
++struct btrfs_root *btrfs_get_fs_root_commit_root(struct btrfs_fs_info *fs_info,
++                                               struct btrfs_path *path,
++                                               u64 objectid)
++{
++      struct btrfs_root *root;
++      struct btrfs_key key;
++
++      ASSERT(path->search_commit_root && path->skip_locking);
++
++      /*
++       * This can return -ENOENT if we ask for a root that doesn't exist, but
++       * since this is called via the backref walking code we won't be looking
++       * up a root that doesn't exist, unless there's corruption.  So if root
++       * != NULL just return it.
++       */
++      root = btrfs_get_global_root(fs_info, objectid);
++      if (root)
++              return root;
++
++      root = btrfs_lookup_fs_root(fs_info, objectid);
++      if (root)
++              return root;
++
++      key.objectid = objectid;
++      key.type = BTRFS_ROOT_ITEM_KEY;
++      key.offset = (u64)-1;
++      root = read_tree_root_path(fs_info->tree_root, path, &key);
++      btrfs_release_path(path);
++
++      return root;
++}
++
+ /*
+  * called by the kthread helper functions to finally call the bio end_io
+  * functions.  This is where read checksum verification actually happens
+diff --git a/fs/btrfs/disk-io.h b/fs/btrfs/disk-io.h
+index 00dc39d47ed34..2e6da9ae8462f 100644
+--- a/fs/btrfs/disk-io.h
++++ b/fs/btrfs/disk-io.h
+@@ -69,6 +69,9 @@ struct btrfs_root *btrfs_get_fs_root(struct btrfs_fs_info *fs_info,
+                                    u64 objectid, bool check_ref);
+ struct btrfs_root *btrfs_get_new_fs_root(struct btrfs_fs_info *fs_info,
+                                        u64 objectid, dev_t anon_dev);
++struct btrfs_root *btrfs_get_fs_root_commit_root(struct btrfs_fs_info *fs_info,
++                                               struct btrfs_path *path,
++                                               u64 objectid);
+ void btrfs_free_fs_info(struct btrfs_fs_info *fs_info);
+ int btrfs_cleanup_fs_roots(struct btrfs_fs_info *fs_info);
+-- 
+2.27.0
+
diff --git a/queue-5.9/btrfs-drop-the-path-before-adding-qgroup-items-when-.patch b/queue-5.9/btrfs-drop-the-path-before-adding-qgroup-items-when-.patch
new file mode 100644 (file)
index 0000000..c96fed0
--- /dev/null
@@ -0,0 +1,163 @@
+From 7fb0b343ccfe49cc62d6b61d14dd67766f30fcec Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 19 Oct 2020 16:02:29 -0400
+Subject: btrfs: drop the path before adding qgroup items when enabling qgroups
+
+From: Josef Bacik <josef@toxicpanda.com>
+
+[ Upstream commit 5223cc60b40ae525ae6c94e98824129f1a5b4ae5 ]
+
+When enabling qgroups we walk the tree_root and then add a qgroup item
+for every root that we have.  This creates a lock dependency on the
+tree_root and qgroup_root, which results in the following lockdep splat
+(with tree locks using rwsem), eg. in tests btrfs/017 or btrfs/022:
+
+  ======================================================
+  WARNING: possible circular locking dependency detected
+  5.9.0-default+ #1299 Not tainted
+  ------------------------------------------------------
+  btrfs/24552 is trying to acquire lock:
+  ffff9142dfc5f630 (btrfs-quota-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+
+  but task is already holding lock:
+  ffff9142dfc5d0b0 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+
+  which lock already depends on the new lock.
+
+  the existing dependency chain (in reverse order) is:
+
+  -> #1 (btrfs-root-00){++++}-{3:3}:
+        __lock_acquire+0x3fb/0x730
+        lock_acquire.part.0+0x6a/0x130
+        down_read_nested+0x46/0x130
+        __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+        __btrfs_read_lock_root_node+0x3a/0x50 [btrfs]
+        btrfs_search_slot_get_root+0x11d/0x290 [btrfs]
+        btrfs_search_slot+0xc3/0x9f0 [btrfs]
+        btrfs_insert_item+0x6e/0x140 [btrfs]
+        btrfs_create_tree+0x1cb/0x240 [btrfs]
+        btrfs_quota_enable+0xcd/0x790 [btrfs]
+        btrfs_ioctl_quota_ctl+0xc9/0xe0 [btrfs]
+        __x64_sys_ioctl+0x83/0xa0
+        do_syscall_64+0x2d/0x70
+        entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+  -> #0 (btrfs-quota-00){++++}-{3:3}:
+        check_prev_add+0x91/0xc30
+        validate_chain+0x491/0x750
+        __lock_acquire+0x3fb/0x730
+        lock_acquire.part.0+0x6a/0x130
+        down_read_nested+0x46/0x130
+        __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+        __btrfs_read_lock_root_node+0x3a/0x50 [btrfs]
+        btrfs_search_slot_get_root+0x11d/0x290 [btrfs]
+        btrfs_search_slot+0xc3/0x9f0 [btrfs]
+        btrfs_insert_empty_items+0x58/0xa0 [btrfs]
+        add_qgroup_item.part.0+0x72/0x210 [btrfs]
+        btrfs_quota_enable+0x3bb/0x790 [btrfs]
+        btrfs_ioctl_quota_ctl+0xc9/0xe0 [btrfs]
+        __x64_sys_ioctl+0x83/0xa0
+        do_syscall_64+0x2d/0x70
+        entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+  other info that might help us debug this:
+
+   Possible unsafe locking scenario:
+
+        CPU0                    CPU1
+        ----                    ----
+    lock(btrfs-root-00);
+                                lock(btrfs-quota-00);
+                                lock(btrfs-root-00);
+    lock(btrfs-quota-00);
+
+   *** DEADLOCK ***
+
+  5 locks held by btrfs/24552:
+   #0: ffff9142df431478 (sb_writers#10){.+.+}-{0:0}, at: mnt_want_write_file+0x22/0xa0
+   #1: ffff9142f9b10cc0 (&fs_info->subvol_sem){++++}-{3:3}, at: btrfs_ioctl_quota_ctl+0x7b/0xe0 [btrfs]
+   #2: ffff9142f9b11a08 (&fs_info->qgroup_ioctl_lock){+.+.}-{3:3}, at: btrfs_quota_enable+0x3b/0x790 [btrfs]
+   #3: ffff9142df431698 (sb_internal#2){.+.+}-{0:0}, at: start_transaction+0x406/0x510 [btrfs]
+   #4: ffff9142dfc5d0b0 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+
+  stack backtrace:
+  CPU: 1 PID: 24552 Comm: btrfs Not tainted 5.9.0-default+ #1299
+  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
+  Call Trace:
+   dump_stack+0x77/0x97
+   check_noncircular+0xf3/0x110
+   check_prev_add+0x91/0xc30
+   validate_chain+0x491/0x750
+   __lock_acquire+0x3fb/0x730
+   lock_acquire.part.0+0x6a/0x130
+   ? __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+   ? lock_acquire+0xc4/0x140
+   ? __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+   down_read_nested+0x46/0x130
+   ? __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+   __btrfs_tree_read_lock+0x35/0x1c0 [btrfs]
+   ? btrfs_root_node+0xd9/0x200 [btrfs]
+   __btrfs_read_lock_root_node+0x3a/0x50 [btrfs]
+   btrfs_search_slot_get_root+0x11d/0x290 [btrfs]
+   btrfs_search_slot+0xc3/0x9f0 [btrfs]
+   btrfs_insert_empty_items+0x58/0xa0 [btrfs]
+   add_qgroup_item.part.0+0x72/0x210 [btrfs]
+   btrfs_quota_enable+0x3bb/0x790 [btrfs]
+   btrfs_ioctl_quota_ctl+0xc9/0xe0 [btrfs]
+   __x64_sys_ioctl+0x83/0xa0
+   do_syscall_64+0x2d/0x70
+   entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+Fix this by dropping the path whenever we find a root item, add the
+qgroup item, and then re-lookup the root item we found and continue
+processing roots.
+
+Reported-by: David Sterba <dsterba@suse.com>
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Josef Bacik <josef@toxicpanda.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/qgroup.c | 18 ++++++++++++++++++
+ 1 file changed, 18 insertions(+)
+
+diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
+index c0f350c3a0cf4..db953cb947bc4 100644
+--- a/fs/btrfs/qgroup.c
++++ b/fs/btrfs/qgroup.c
+@@ -1026,6 +1026,10 @@ int btrfs_quota_enable(struct btrfs_fs_info *fs_info)
+               btrfs_item_key_to_cpu(leaf, &found_key, slot);
+               if (found_key.type == BTRFS_ROOT_REF_KEY) {
++
++                      /* Release locks on tree_root before we access quota_root */
++                      btrfs_release_path(path);
++
+                       ret = add_qgroup_item(trans, quota_root,
+                                             found_key.offset);
+                       if (ret) {
+@@ -1044,6 +1048,20 @@ int btrfs_quota_enable(struct btrfs_fs_info *fs_info)
+                               btrfs_abort_transaction(trans, ret);
+                               goto out_free_path;
+                       }
++                      ret = btrfs_search_slot_for_read(tree_root, &found_key,
++                                                       path, 1, 0);
++                      if (ret < 0) {
++                              btrfs_abort_transaction(trans, ret);
++                              goto out_free_path;
++                      }
++                      if (ret > 0) {
++                              /*
++                               * Shouldn't happen, but in case it does we
++                               * don't need to do the btrfs_next_item, just
++                               * continue.
++                               */
++                              continue;
++                      }
+               }
+               ret = btrfs_next_item(tree_root, path);
+               if (ret < 0) {
+-- 
+2.27.0
+
diff --git a/queue-5.9/drm-amd-display-adding-ddc_gpio_vga_reg_list-to-ddc-.patch b/queue-5.9/drm-amd-display-adding-ddc_gpio_vga_reg_list-to-ddc-.patch
new file mode 100644 (file)
index 0000000..3b2567b
--- /dev/null
@@ -0,0 +1,56 @@
+From 08e0720ac1e506611acb93f170161a6c6cc35bed Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 7 Oct 2020 12:17:22 -0400
+Subject: drm/amd/display: adding ddc_gpio_vga_reg_list to ddc reg def'ns
+
+From: Martin Leung <martin.leung@amd.com>
+
+[ Upstream commit a1d2afc5dde29a943d32bf92eb0408c9f19541fc ]
+
+why:
+oem-related ddc read/write fails without these regs
+
+how:
+copy from hw_factory_dcn20.c
+
+Signed-off-by: Martin Leung <martin.leung@amd.com>
+Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+diff --git a/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c b/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
+index 7e7fb65721073..9d3665f88c523 100644
+--- a/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
++++ b/drivers/gpu/drm/amd/display/dc/gpio/dcn30/hw_factory_dcn30.c
+@@ -117,6 +117,12 @@ static const struct ddc_registers ddc_data_regs_dcn[] = {
+       ddc_data_regs_dcn2(4),
+       ddc_data_regs_dcn2(5),
+       ddc_data_regs_dcn2(6),
++      {
++                      DDC_GPIO_VGA_REG_LIST(DATA),
++                      .ddc_setup = 0,
++                      .phy_aux_cntl = 0,
++                      .dc_gpio_aux_ctrl_5 = 0
++      }
+ };
+ static const struct ddc_registers ddc_clk_regs_dcn[] = {
+@@ -126,6 +132,12 @@ static const struct ddc_registers ddc_clk_regs_dcn[] = {
+       ddc_clk_regs_dcn2(4),
+       ddc_clk_regs_dcn2(5),
+       ddc_clk_regs_dcn2(6),
++      {
++                      DDC_GPIO_VGA_REG_LIST(CLK),
++                      .ddc_setup = 0,
++                      .phy_aux_cntl = 0,
++                      .dc_gpio_aux_ctrl_5 = 0
++      }
+ };
+ static const struct ddc_sh_mask ddc_shift[] = {
+-- 
+2.27.0
+
diff --git a/queue-5.9/drm-amd-display-fixed-panic-during-seamless-boot.patch b/queue-5.9/drm-amd-display-fixed-panic-during-seamless-boot.patch
new file mode 100644 (file)
index 0000000..4b507a7
--- /dev/null
@@ -0,0 +1,41 @@
+From fb1c71990330b1fa1329b951677efc0a28c5300c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 29 Apr 2020 13:31:12 -0400
+Subject: drm/amd/display: Fixed panic during seamless boot.
+
+From: David Galiffi <David.Galiffi@amd.com>
+
+[ Upstream commit 866e09f0110c6e86071954033e3067975946592a ]
+
+[why]
+get_pixel_clk_frequency_100hz is undefined in clock_source_funcs.
+
+[how]
+set function pointer: ".get_pixel_clk_frequency_100hz = get_pixel_clk_frequency_100hz"
+
+Signed-off-by: David Galiffi <David.Galiffi@amd.com>
+Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
+Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+index 9cc65dc1970f8..49ae5ff12da63 100644
+--- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
++++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c
+@@ -1149,7 +1149,8 @@ static uint32_t dcn3_get_pix_clk_dividers(
+ static const struct clock_source_funcs dcn3_clk_src_funcs = {
+       .cs_power_down = dce110_clock_source_power_down,
+       .program_pix_clk = dcn3_program_pix_clk,
+-      .get_pix_clk_dividers = dcn3_get_pix_clk_dividers
++      .get_pix_clk_dividers = dcn3_get_pix_clk_dividers,
++      .get_pixel_clk_frequency_100hz = get_pixel_clk_frequency_100hz
+ };
+ #endif
+ /*****************************************/
+-- 
+2.27.0
+
diff --git a/queue-5.9/drm-amdgpu-add-did-for-navi10-blockchain-sku.patch b/queue-5.9/drm-amdgpu-add-did-for-navi10-blockchain-sku.patch
new file mode 100644 (file)
index 0000000..5870825
--- /dev/null
@@ -0,0 +1,33 @@
+From d7b3671e5adfd123356e12b503296098dfec34aa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Oct 2020 17:05:50 +0800
+Subject: drm/amdgpu: add DID for navi10 blockchain SKU
+
+From: Tianci.Yin <tianci.yin@amd.com>
+
+[ Upstream commit 8942881144a7365143f196f5eafed24783a424a3 ]
+
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Guchun Chen <guchun.chen@amd.com>
+Signed-off-by: Tianci.Yin <tianci.yin@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 321032d3a51a2..06a5b6ae1c43e 100644
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+@@ -1033,6 +1033,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.9/drm-amdgpu-disable-dcn-and-vcn-for-navi10-blockchain.patch b/queue-5.9/drm-amdgpu-disable-dcn-and-vcn-for-navi10-blockchain.patch
new file mode 100644 (file)
index 0000000..f846ead
--- /dev/null
@@ -0,0 +1,61 @@
+From d3803b6983ffae12df20030f76b5b321bf620e3b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 11:40:26 +0800
+Subject: drm/amdgpu: disable DCN and VCN for navi10 blockchain SKU(v3)
+
+From: Tianci.Yin <tianci.yin@amd.com>
+
+[ Upstream commit a305e7dc5fa86ff9cf6cd2da30215a92d43c9285 ]
+
+The blockchain SKU has no display and video support, remove them.
+
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Tianci.Yin <tianci.yin@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/amdgpu/nv.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
+index ca11253e787ca..8254f42146890 100644
+--- a/drivers/gpu/drm/amd/amdgpu/nv.c
++++ b/drivers/gpu/drm/amd/amdgpu/nv.c
+@@ -488,6 +488,14 @@ void nv_set_virt_ops(struct amdgpu_device *adev)
+       adev->virt.ops = &xgpu_nv_virt_ops;
+ }
++static bool nv_is_blockchain_sku(struct pci_dev *pdev)
++{
++      if (pdev->device == 0x731E &&
++          (pdev->revision == 0xC6 || pdev->revision == 0xC7))
++              return true;
++      return false;
++}
++
+ int nv_set_ip_blocks(struct amdgpu_device *adev)
+ {
+       int r;
+@@ -516,7 +524,8 @@ int nv_set_ip_blocks(struct amdgpu_device *adev)
+               if (adev->enable_virtual_display || amdgpu_sriov_vf(adev))
+                       amdgpu_device_ip_block_add(adev, &dce_virtual_ip_block);
+ #if defined(CONFIG_DRM_AMD_DC)
+-              else if (amdgpu_device_has_dc_support(adev))
++              else if (amdgpu_device_has_dc_support(adev) &&
++                       !nv_is_blockchain_sku(adev->pdev))
+                       amdgpu_device_ip_block_add(adev, &dm_ip_block);
+ #endif
+               amdgpu_device_ip_block_add(adev, &gfx_v10_0_ip_block);
+@@ -524,7 +533,8 @@ int nv_set_ip_blocks(struct amdgpu_device *adev)
+               if (adev->firmware.load_type == AMDGPU_FW_LOAD_DIRECT &&
+                   !amdgpu_sriov_vf(adev))
+                       amdgpu_device_ip_block_add(adev, &smu_v11_0_ip_block);
+-              amdgpu_device_ip_block_add(adev, &vcn_v2_0_ip_block);
++              if (!nv_is_blockchain_sku(adev->pdev))
++                      amdgpu_device_ip_block_add(adev, &vcn_v2_0_ip_block);
+               amdgpu_device_ip_block_add(adev, &jpeg_v2_0_ip_block);
+               if (adev->enable_mes)
+                       amdgpu_device_ip_block_add(adev, &mes_v10_1_ip_block);
+-- 
+2.27.0
+
diff --git a/queue-5.9/drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch b/queue-5.9/drm-nouveau-gem-fix-refcount_t-underflow-use-after-f.patch
new file mode 100644 (file)
index 0000000..d2a81ab
--- /dev/null
@@ -0,0 +1,36 @@
+From d8fb225bf0a70e57932634651deae67a4c0144ea Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 7 Oct 2020 00:08:09 +0200
+Subject: drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"
+
+From: Karol Herbst <kherbst@redhat.com>
+
+[ 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 <kherbst@redhat.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 81f111ad3f4fd..124d3dcc5c590 100644
+--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
++++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
+@@ -198,7 +198,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.9/drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch b/queue-5.9/drm-nouveau-nouveau-fix-the-start-end-range-for-migr.patch
new file mode 100644 (file)
index 0000000..f13b207
--- /dev/null
@@ -0,0 +1,73 @@
+From 4d10698be91bd76c786eb2859a2687f7e8af36f0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Aug 2020 13:31:11 -0700
+Subject: drm/nouveau/nouveau: fix the start/end range for migration
+
+From: Ralph Campbell <rcampbell@nvidia.com>
+
+[ 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 <rcampbell@nvidia.com>
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 2df1c04605594..4f69e4c3dafde 100644
+--- a/drivers/gpu/drm/nouveau/nouveau_svm.c
++++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
+@@ -105,11 +105,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)
+@@ -118,8 +118,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;
+@@ -151,12 +149,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
+@@ -171,7 +163,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.9/drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch b/queue-5.9/drm-sun4i-frontend-fix-the-scaler-phase-on-a33.patch
new file mode 100644 (file)
index 0000000..f6a5fa5
--- /dev/null
@@ -0,0 +1,36 @@
+From 7685618b10771275414a28b5afc13c63a2fa7907 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 15 Oct 2020 11:36:42 +0200
+Subject: drm/sun4i: frontend: Fix the scaler phase on A33
+
+From: Maxime Ripard <maxime@cerno.tech>
+
+[ 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 <maxime@cerno.tech>
+Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-maxime@cerno.tech
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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.9/drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch b/queue-5.9/drm-sun4i-frontend-reuse-the-ch0-phase-for-rgb-forma.patch
new file mode 100644 (file)
index 0000000..d6be3b7
--- /dev/null
@@ -0,0 +1,73 @@
+From ae78e858e31c54d5bf9215029d75282f5da9356b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 15 Oct 2020 11:36:41 +0200
+Subject: drm/sun4i: frontend: Reuse the ch0 phase for RGB formats
+
+From: Maxime Ripard <maxime@cerno.tech>
+
+[ 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 <tpgalchenko@gmail.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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.9/drm-sun4i-frontend-rework-a-bit-the-phase-data.patch b/queue-5.9/drm-sun4i-frontend-rework-a-bit-the-phase-data.patch
new file mode 100644 (file)
index 0000000..69603ed
--- /dev/null
@@ -0,0 +1,115 @@
+From e525c8e1d1734ee507a3327e8de4bef781a22926 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 15 Oct 2020 11:36:40 +0200
+Subject: drm/sun4i: frontend: Rework a bit the phase data
+
+From: Maxime Ripard <maxime@cerno.tech>
+
+[ 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 <maxime@cerno.tech>
+Acked-by: Jernej Skrabec <jernej.skrabec@siol.net>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-maxime@cerno.tech
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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.9/drm-v3d-fix-double-free-in-v3d_submit_cl_ioctl.patch b/queue-5.9/drm-v3d-fix-double-free-in-v3d_submit_cl_ioctl.patch
new file mode 100644 (file)
index 0000000..125cc70
--- /dev/null
@@ -0,0 +1,35 @@
+From cc9e2df40be5822a9e3a579aec4aa59d6d5483f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Oct 2020 12:49:05 +0300
+Subject: drm/v3d: Fix double free in v3d_submit_cl_ioctl()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 897dbea6b716c0f2c5bcd4ba1eb4d809caba290c ]
+
+Originally this error path used to leak "bin" but then we accidentally
+applied two separate commits to fix it and ended up with a double free.
+
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201026094905.GA1634423@mwanda
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/v3d/v3d_gem.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
+index 915f8bfdb58ca..182c586525eb8 100644
+--- a/drivers/gpu/drm/v3d/v3d_gem.c
++++ b/drivers/gpu/drm/v3d/v3d_gem.c
+@@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
+               ret = v3d_job_init(v3d, file_priv, &bin->base,
+                                  v3d_job_free, args->in_sync_bcl);
+               if (ret) {
+-                      kfree(bin);
+                       v3d_job_put(&render->base);
+                       kfree(bin);
+                       return ret;
+-- 
+2.27.0
+
diff --git a/queue-5.9/drm-vc4-drv-add-error-handding-for-bind.patch b/queue-5.9/drm-vc4-drv-add-error-handding-for-bind.patch
new file mode 100644 (file)
index 0000000..14ac2a1
--- /dev/null
@@ -0,0 +1,35 @@
+From 40c6ee6b353960d65a5172699c272b9dc12e6800 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 27 Oct 2020 13:14:42 +0900
+Subject: drm/vc4: drv: Add error handding for bind
+
+From: Hoegeun Kwon <hoegeun.kwon@samsung.com>
+
+[ 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 <hoegeun.kwon@samsung.com>
+Signed-off-by: Maxime Ripard <maxime@cerno.tech>
+Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 38343d2fb4fb4..f6995e7f6eb6e 100644
+--- a/drivers/gpu/drm/vc4/vc4_drv.c
++++ b/drivers/gpu/drm/vc4/vc4_drv.c
+@@ -310,6 +310,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.9/hyperv_fb-update-screen_info-after-removing-old-fram.patch b/queue-5.9/hyperv_fb-update-screen_info-after-removing-old-fram.patch
new file mode 100644 (file)
index 0000000..0fb6095
--- /dev/null
@@ -0,0 +1,56 @@
+From 8bbe02ec012e34dc2867d1a454b02d87a0eddf46 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 14 Oct 2020 17:24:29 +0800
+Subject: hyperv_fb: Update screen_info after removing old framebuffer
+
+From: Kairui Song <kasong@redhat.com>
+
+[ Upstream commit 3cb73bc3fa2a3cb80b88aa63b48409939e0d996b ]
+
+On gen2 HyperV VM, hyperv_fb will remove the old framebuffer, and the
+new allocated framebuffer address could be at a differnt location,
+and it might be no longer a VGA framebuffer.
+
+Update screen_info so that after kexec the kernel won't try to reuse
+the old invalid/stale framebuffer address as VGA, corrupting memory.
+
+[ mingo: Tidied up the changelog. ]
+
+Signed-off-by: Kairui Song <kasong@redhat.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Cc: Dexuan Cui <decui@microsoft.com>
+Cc: Jake Oshins <jakeo@microsoft.com>
+Cc: Wei Hu <weh@microsoft.com>
+Cc: "K. Y. Srinivasan" <kys@microsoft.com>
+Cc: Haiyang Zhang <haiyangz@microsoft.com>
+Cc: Stephen Hemminger <sthemmin@microsoft.com>
+Link: https://lore.kernel.org/r/20201014092429.1415040-3-kasong@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/hyperv_fb.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
+index 02411d89cb462..e36fb1a0ecdbd 100644
+--- a/drivers/video/fbdev/hyperv_fb.c
++++ b/drivers/video/fbdev/hyperv_fb.c
+@@ -1114,8 +1114,15 @@ static int hvfb_getmem(struct hv_device *hdev, struct fb_info *info)
+ getmem_done:
+       remove_conflicting_framebuffers(info->apertures,
+                                       KBUILD_MODNAME, false);
+-      if (!gen2vm)
++
++      if (gen2vm) {
++              /* framebuffer is reallocated, clear screen_info to avoid misuse from kexec */
++              screen_info.lfb_size = 0;
++              screen_info.lfb_base = 0;
++              screen_info.orig_video_isVGA = 0;
++      } else {
+               pci_dev_put(pdev);
++      }
+       kfree(info->apertures);
+       return 0;
+-- 
+2.27.0
+
diff --git a/queue-5.9/io_uring-don-t-miss-setting-io_wq_work_concurrent.patch b/queue-5.9/io_uring-don-t-miss-setting-io_wq_work_concurrent.patch
new file mode 100644 (file)
index 0000000..02879ef
--- /dev/null
@@ -0,0 +1,50 @@
+From e63ec78577b6c4bdbc8766240625d60696937027 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 16:47:16 +0100
+Subject: io_uring: don't miss setting IO_WQ_WORK_CONCURRENT
+
+From: Pavel Begunkov <asml.silence@gmail.com>
+
+[ Upstream commit feaadc4fc2ebdbd53ffed1735077725855a2af53 ]
+
+Set IO_WQ_WORK_CONCURRENT for all REQ_F_FORCE_ASYNC requests, do that in
+that is also looks better.
+
+Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/io_uring.c | 10 +++-------
+ 1 file changed, 3 insertions(+), 7 deletions(-)
+
+diff --git a/fs/io_uring.c b/fs/io_uring.c
+index 64f214a3dc9dd..eba5f65493a10 100644
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -1140,6 +1140,9 @@ static void io_prep_async_work(struct io_kiocb *req)
+       io_req_init_async(req);
++      if (req->flags & REQ_F_FORCE_ASYNC)
++              req->work.flags |= IO_WQ_WORK_CONCURRENT;
++
+       if (req->flags & REQ_F_ISREG) {
+               if (def->hash_reg_file || (req->ctx->flags & IORING_SETUP_IOPOLL))
+                       io_wq_hash_work(&req->work, file_inode(req->file));
+@@ -6281,13 +6284,6 @@ static void io_queue_sqe(struct io_kiocb *req, const struct io_uring_sqe *sqe,
+                       if (unlikely(ret))
+                               goto fail_req;
+               }
+-
+-              /*
+-               * Never try inline submit of IOSQE_ASYNC is set, go straight
+-               * to async execution.
+-               */
+-              io_req_init_async(req);
+-              req->work.flags |= IO_WQ_WORK_CONCURRENT;
+               io_queue_async_work(req);
+       } else {
+               __io_queue_sqe(req, sqe, cs);
+-- 
+2.27.0
+
diff --git a/queue-5.9/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch b/queue-5.9/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch
new file mode 100644 (file)
index 0000000..c7fb581
--- /dev/null
@@ -0,0 +1,56 @@
+From 5b5911b44629a306aae487f8fba310f2317845d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 25 Oct 2020 19:51:24 +0800
+Subject: nvme-rdma: handle unexpected nvme completion data length
+
+From: zhenwei pi <pizhenwei@bytedance.com>
+
+[ 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:
+ <IRQ>
+ 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 <pizhenwei@bytedance.com>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 116902b1b2c34..3a598e91e816d 100644
+--- a/drivers/nvme/host/rdma.c
++++ b/drivers/nvme/host/rdma.c
+@@ -1767,6 +1767,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.9/nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch b/queue-5.9/nvmet-fix-a-null-pointer-dereference-when-tracing-th.patch
new file mode 100644 (file)
index 0000000..f8fbf5d
--- /dev/null
@@ -0,0 +1,148 @@
+From 54d042d4822d7f403668995b8e6dfc6f49987b48 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 16:58:21 -0700
+Subject: nvmet: fix a NULL pointer dereference when tracing the flush command
+
+From: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
+
+[ 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 <chaitanya.kulkarni@wdc.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 90e0c84df2af9..754287709ec49 100644
+--- a/drivers/nvme/target/core.c
++++ b/drivers/nvme/target/core.c
+@@ -907,8 +907,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);
+@@ -938,6 +936,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 0458046d65017..c14e3249a14dc 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.9/of-fix-reserved-memory-overlap-detection.patch b/queue-5.9/of-fix-reserved-memory-overlap-detection.patch
new file mode 100644 (file)
index 0000000..9660a10
--- /dev/null
@@ -0,0 +1,85 @@
+From 643fd1c8513f016e5f77c207920f1999d988554f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 21 Oct 2020 11:53:59 +0200
+Subject: of: Fix reserved-memory overlap detection
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ 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 <vincent.whitchurch@axis.com>
+Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 46b9371c8a332..6530b8b9160f1 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.9/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch b/queue-5.9/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch
new file mode 100644 (file)
index 0000000..d4b752a
--- /dev/null
@@ -0,0 +1,75 @@
+From 6b61198167abd1dd444053e5c39723e31b9e679d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 10 Oct 2020 11:25:39 +0800
+Subject: scsi: core: Don't start concurrent async scan on same host
+
+From: Ming Lei <ming.lei@redhat.com>
+
+[ 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 <hch@lst.de>
+Cc: Ewan D. Milne <emilne@redhat.com>
+Cc: Hannes Reinecke <hare@suse.de>
+Cc: Bart Van Assche <bvanassche@acm.org>
+Reviewed-by: Lee Duncan <lduncan@suse.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 f2437a7570ce8..9af50e6f94c4c 100644
+--- a/drivers/scsi/scsi_scan.c
++++ b/drivers/scsi/scsi_scan.c
+@@ -1714,15 +1714,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);
+@@ -1733,7 +1734,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);
+@@ -1748,6 +1748,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.9/scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch b/queue-5.9/scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch
new file mode 100644 (file)
index 0000000..bf2b463
--- /dev/null
@@ -0,0 +1,149 @@
+From 9d5e1281ff2b5e4f9b93a780e2d19d25ef02f67f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 24 Oct 2020 19:13:55 -0500
+Subject: scsi: ibmvscsi: Fix potential race after loss of transport
+
+From: Tyrel Datwyler <tyreld@linux.ibm.com>
+
+[ 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 <tyreld@linux.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 b1f3017b6547a..29fcc44be2d57 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
+
index 1ccad0883cb4cb50f6541b3d879cd8324e371ad3..58f2fc852309a79338a1a92484cc41990905f0ed 100644 (file)
@@ -69,3 +69,36 @@ 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
 x86-lib-change-.weak-to-sym_func_start_weak-for-arch-x86-lib-mem-_64.s.patch
+arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch
+arm64-dts-meson-add-missing-g12-rng-clock.patch
+arm64-dts-amlogic-meson-g12-use-the-g12a-specific-dw.patch
+x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch
+hyperv_fb-update-screen_info-after-removing-old-fram.patch
+arm64-dts-amlogic-add-missing-ethernet-reset-id.patch
+io_uring-don-t-miss-setting-io_wq_work_concurrent.patch
+of-fix-reserved-memory-overlap-detection.patch
+arm-dts-mmp3-add-power-domain-for-the-camera.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
+drm-v3d-fix-double-free-in-v3d_submit_cl_ioctl.patch
+blk-cgroup-fix-memleak-on-error-path.patch
+blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch
+btrfs-drop-the-path-before-adding-qgroup-items-when-.patch
+btrfs-add-a-helper-to-read-the-tree_root-commit-root.patch
+scsi-core-don-t-start-concurrent-async-scan-on-same-.patch
+drm-amdgpu-disable-dcn-and-vcn-for-navi10-blockchain.patch
+drm-amdgpu-add-did-for-navi10-blockchain-sku.patch
+drm-amd-display-fixed-panic-during-seamless-boot.patch
+scsi-ibmvscsi-fix-potential-race-after-loss-of-trans.patch
+drm-amd-display-adding-ddc_gpio_vga_reg_list-to-ddc-.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
+staging-mmal-vchiq-fix-memory-leak-for-vchiq_instanc.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
diff --git a/queue-5.9/staging-mmal-vchiq-fix-memory-leak-for-vchiq_instanc.patch b/queue-5.9/staging-mmal-vchiq-fix-memory-leak-for-vchiq_instanc.patch
new file mode 100644 (file)
index 0000000..2746525
--- /dev/null
@@ -0,0 +1,90 @@
+From bb61b246940e3d639ebfabe30ce38cf7f1f57f24 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 26 Oct 2020 18:55:50 +0900
+Subject: staging: mmal-vchiq: Fix memory leak for vchiq_instance
+
+From: Seung-Woo Kim <sw0312.kim@samsung.com>
+
+[ Upstream commit b6ae84d648954fae096d94faea1ddb6518b27841 ]
+
+The vchiq_instance is allocated with vchiq_initialise() but never
+freed properly. Fix memory leak for the vchiq_instance.
+
+Reported-by: Jaehoon Chung <jh80.chung@samsung.com>
+Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
+Link: https://lore.kernel.org/r/1603706150-10806-1-git-send-email-sw0312.kim@samsung.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../vc04_services/vchiq-mmal/mmal-vchiq.c     | 19 +++++++++++++++----
+ 1 file changed, 15 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+index e798d494f00ff..bbf033ca47362 100644
+--- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
++++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
+@@ -179,6 +179,9 @@ struct vchiq_mmal_instance {
+       /* ordered workqueue to process all bulk operations */
+       struct workqueue_struct *bulk_wq;
++
++      /* handle for a vchiq instance */
++      struct vchiq_instance *vchiq_instance;
+ };
+ static struct mmal_msg_context *
+@@ -1840,6 +1843,7 @@ int vchiq_mmal_finalise(struct vchiq_mmal_instance *instance)
+       mutex_unlock(&instance->vchiq_mutex);
++      vchiq_shutdown(instance->vchiq_instance);
+       flush_workqueue(instance->bulk_wq);
+       destroy_workqueue(instance->bulk_wq);
+@@ -1856,6 +1860,7 @@ EXPORT_SYMBOL_GPL(vchiq_mmal_finalise);
+ int vchiq_mmal_init(struct vchiq_mmal_instance **out_instance)
+ {
+       int status;
++      int err = -ENODEV;
+       struct vchiq_mmal_instance *instance;
+       static struct vchiq_instance *vchiq_instance;
+       struct vchiq_service_params params = {
+@@ -1890,17 +1895,21 @@ int vchiq_mmal_init(struct vchiq_mmal_instance **out_instance)
+       status = vchiq_connect(vchiq_instance);
+       if (status) {
+               pr_err("Failed to connect VCHI instance (status=%d)\n", status);
+-              return -EIO;
++              err = -EIO;
++              goto err_shutdown_vchiq;
+       }
+       instance = kzalloc(sizeof(*instance), GFP_KERNEL);
+-      if (!instance)
+-              return -ENOMEM;
++      if (!instance) {
++              err = -ENOMEM;
++              goto err_shutdown_vchiq;
++      }
+       mutex_init(&instance->vchiq_mutex);
+       instance->bulk_scratch = vmalloc(PAGE_SIZE);
++      instance->vchiq_instance = vchiq_instance;
+       mutex_init(&instance->context_map_lock);
+       idr_init_base(&instance->context_map, 1);
+@@ -1932,7 +1941,9 @@ int vchiq_mmal_init(struct vchiq_mmal_instance **out_instance)
+ err_free:
+       vfree(instance->bulk_scratch);
+       kfree(instance);
+-      return -ENODEV;
++err_shutdown_vchiq:
++      vchiq_shutdown(vchiq_instance);
++      return err;
+ }
+ EXPORT_SYMBOL_GPL(vchiq_mmal_init);
+-- 
+2.27.0
+
diff --git a/queue-5.9/usb-cdns3-gadget-suspicious-implicit-sign-extension.patch b/queue-5.9/usb-cdns3-gadget-suspicious-implicit-sign-extension.patch
new file mode 100644 (file)
index 0000000..7c4d6b8
--- /dev/null
@@ -0,0 +1,48 @@
+From fe517b967f74dc406bcd92536c7e574a78e22364 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 22 Oct 2020 08:55:03 +0800
+Subject: usb: cdns3: gadget: suspicious implicit sign extension
+
+From: Peter Chen <peter.chen@nxp.com>
+
+[ 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 <jun.li@nxp.com>
+Signed-off-by: Peter Chen <peter.chen@nxp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 8212bddf6c8d1..5be0ff2ae079c 100644
+--- a/drivers/usb/cdns3/gadget.h
++++ b/drivers/usb/cdns3/gadget.h
+@@ -1067,7 +1067,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.9/vsock-use-ns_capable_noaudit-on-socket-create.patch b/queue-5.9/vsock-use-ns_capable_noaudit-on-socket-create.patch
new file mode 100644 (file)
index 0000000..056c71c
--- /dev/null
@@ -0,0 +1,46 @@
+From 7f80e058fc1391cbd8267febfa3263f7f565a9e8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 23 Oct 2020 16:37:57 +0200
+Subject: vsock: use ns_capable_noaudit() on socket create
+
+From: Jeff Vander Stoep <jeffv@google.com>
+
+[ 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 <rkir@google.com>
+https://android-review.googlesource.com/c/device/generic/goldfish/+/1468545/
+Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
+Reviewed-by: James Morris <jamorris@linux.microsoft.com>
+Link: https://lore.kernel.org/r/20201023143757.377574-1-jeffv@google.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 9e93bc201cc07..b4d7b8aba0037 100644
+--- a/net/vmw_vsock/af_vsock.c
++++ b/net/vmw_vsock/af_vsock.c
+@@ -739,7 +739,7 @@ static struct sock *__vsock_create(struct net *net,
+               vsk->buffer_min_size = psk->buffer_min_size;
+               vsk->buffer_max_size = psk->buffer_max_size;
+       } 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;
+               vsk->buffer_size = VSOCK_DEFAULT_BUFFER_SIZE;
+-- 
+2.27.0
+
diff --git a/queue-5.9/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch b/queue-5.9/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch
new file mode 100644 (file)
index 0000000..8379f2d
--- /dev/null
@@ -0,0 +1,50 @@
+From 784fe395c792a9857c6156c4c27b507b5665743f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <kasong@redhat.com>
+
+[ 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 <kasong@redhat.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Link: https://lore.kernel.org/r/20201014092429.1415040-2-kasong@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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 57c2ecf431343..ce831f9448e71 100644
+--- a/arch/x86/kernel/kexec-bzimage64.c
++++ b/arch/x86/kernel/kexec-bzimage64.c
+@@ -200,8 +200,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(&params->screen_info, &boot_params.screen_info,
+-                              sizeof(struct screen_info));
++      memcpy(&params->screen_info, &screen_info, sizeof(struct screen_info));
+       /* Fill in memsize later */
+       params->screen_info.ext_mem_k = 0;
+-- 
+2.27.0
+