5.8.10-rc1 review

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/mach-omap2/omap-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/mach-omap2/omap-iommu.c +1 -1

index 54aff33e55e6e..bfa5e1b8dba7f 100644
@@ -74,7 +74,7 @@ static struct powerdomain *_get_pwrdm(struct device *dev)
 		return pwrdm;
 
 	clk = of_clk_get(dev->of_node->parent, 0);
-	if (!clk) {
+	if (IS_ERR(clk)) {
 		dev_err(dev, "no fck found\n");
 		return NULL;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #2 lore raw

PATCH 2/177 ARM: dts: logicpd-torpedo-baseboard: Fix broken audio

From: Adam Ford <[email protected]>

[ Upstream commit d7dfee67688ac7f2dfd4c3bc70c053ee990c40b5 ]

Older versions of U-Boot would pinmux the whole board, but as the bootloader got updated, it started to only pinmux the pins it needed, and expected Linux to configure what it needed.

Unfortunately this caused an issue with the audio, because the mcbsp2 pins were configured in the device tree, they were never referenced by the driver. When U-Boot stopped muxing the audio pins, the audio died.

This patch adds the references to the associate the pin controller with the mcbsp2 driver which makes audio operate again.

Fixes 739f85bba5ab ("ARM: dts: Move most of logicpd-torpedo-37xx-devkit to logicpd-torpedo-baseboard")

Signed-off-by Adam Ford <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi | 2 ++
 1 file changed, 2 insertions(+)

arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi +2 -0

index 381f0e82bb706..b0f6613e6d549 100644
@@ -81,6 +81,8 @@
 };
 
 &mcbsp2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcbsp2_pins>;
 	status = "okay";
 };

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:51 UTC #3 lore raw

PATCH 3/177 ARM: dts: logicpd-som-lv-baseboard: Fix broken audio

From: Adam Ford <[email protected]>

[ Upstream commit 4d26e9a028e3d88223e06fa133c3d55af7ddbceb ]

Older versions of U-Boot would pinmux the whole board, but as the bootloader got updated, it started to only pinmux the pins it needed, and expected Linux to configure what it needed.

Unfortunately this caused an issue with the audio, because the mcbsp2 pins were configured in the device tree but never referenced by the driver. When U-Boot stopped muxing the audio pins, the audio died.

This patch adds the references to the associate the pin controller with the mcbsp2 driver which makes audio operate again.

Fixes 5cb8b0fa55a9 ("ARM: dts: Move most of logicpd-som-lv-37xx-devkit.dts to logicpd-som-lv-baseboard.dtsi")

Signed-off-by Adam Ford <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/logicpd-som-lv-baseboard.dtsi | 2 ++
 1 file changed, 2 insertions(+)

arch/arm/boot/dts/logicpd-som-lv-baseboard.dtsi +2 -0

index 100396f6c2feb..c310c33ca6f3f 100644
@@ -51,6 +51,8 @@
 
 &mcbsp2 {
 	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&mcbsp2_pins>;
 };
 
 &charger {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #4 lore raw

PATCH 4/177 ARM: dts: logicpd-som-lv-baseboard: Fix missing video

From: Adam Ford <[email protected]>

[ Upstream commit d1db7b80a6c8c5f81db0e80664d29b374750e2c6 ]

A previous commit removed the panel-dpi driver, which made the SOM-LV video stop working because it relied on the DPI driver for setting video timings. Now that the simple-panel driver is available in omap2plus, this patch migrates the SOM-LV dev kits to use a similar panel and remove the manual timing requirements. A similar patch was already done and applied to the Torpedo family.

Fixes 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")

Signed-off-by Adam Ford <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 .../boot/dts/logicpd-som-lv-baseboard.dtsi    | 27 ++++---------------
 1 file changed, 5 insertions(+), 22 deletions(-)

arch/arm/boot/dts/logicpd-som-lv-baseboard.dtsi +5 ~~-22~~

index c310c33ca6f3f..395e05f10d36c 100644
@@ -104,35 +104,18 @@
 		regulator-max-microvolt = <3300000>;
 	};
 
-	lcd0: display@0 {
-		compatible = "panel-dpi";
-		label = "28";
-		status = "okay";
-		/* default-on; */
+	lcd0: display {
+		/* This isn't the exact LCD, but the timings meet spec */
+		compatible = "logicpd,type28";
 		pinctrl-names = "default";
 		pinctrl-0 = <&lcd_enable_pin>;
-		enable-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;	/* gpio155, lcd INI */
+		backlight = <&bl>;
+		enable-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;
 		port {
 			lcd_in: endpoint {
 				remote-endpoint = <&dpi_out>;
 			};
 		};
-
-		panel-timing {
-			clock-frequency = <9000000>;
-			hactive = <480>;
-			vactive = <272>;
-			hfront-porch = <3>;
-			hback-porch = <2>;
-			hsync-len = <42>;
-			vback-porch = <3>;
-			vfront-porch = <2>;
-			vsync-len = <11>;
-			hsync-active = <1>;
-			vsync-active = <1>;
-			de-active = <1>;
-			pixelclk-active = <0>;
-		};
 	};
 
 	bl: backlight {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:48 UTC #5 lore raw

PATCH 5/177 regulator: push allocation in regulator_ena_gpio_request() out of lock

From: Michał Mirosław <[email protected]>

[ Upstream commit 467bf30142c64f2eb64e2ac67fa4595126230efd ]

Move another allocation out of regulator_list_mutex-protected region, as reclaim might want to take the same lock.

WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0

but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}-{0:0}:

       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       kmem_cache_alloc_trace+0x40/0x1e8
       regulator_register+0x384/0x1630
       devm_regulator_register+0x50/0x84
       reg_fixed_voltage_probe+0x248/0x35c

[...]
other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(regulator_list_mutex);
                               lock(fs_reclaim);

lock(regulator_list_mutex);

*** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50 #1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]

Fixes 541d052d7215 ("regulator: core: Only support passing enable GPIO descriptors")

[this commit only changes context]

Fixes f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")

[this is when the regulator_list_mutex was introduced in reclaim locking path]

Link https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/regulator/core.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

drivers/regulator/core.c +14 -5

index 720f28844795b..86107d2e1733e 100644
@@ -2222,10 +2222,13 @@ EXPORT_SYMBOL_GPL(regulator_bulk_unregister_supply_alias);
 static int regulator_ena_gpio_request(struct regulator_dev *rdev,
 				const struct regulator_config *config)
 {
-	struct regulator_enable_gpio *pin;
+	struct regulator_enable_gpio *pin, *new_pin;
 	struct gpio_desc *gpiod;
 
 	gpiod = config->ena_gpiod;
+	new_pin = kzalloc(sizeof(*new_pin), GFP_KERNEL);
+
+	mutex_lock(&regulator_list_mutex);
 
 	list_for_each_entry(pin, &regulator_ena_gpio_list, list) {
 		if (pin->gpiod == gpiod) {

@@ -2234,9 +2237,13 @@ static int regulator_ena_gpio_request(struct regulator_dev *rdev,
 		}
 	}
 
-	pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
-	if (pin == NULL)
+	if (new_pin == NULL) {
+		mutex_unlock(&regulator_list_mutex);
 		return -ENOMEM;
+	}
+
+	pin = new_pin;
+	new_pin = NULL;
 
 	pin->gpiod = gpiod;
 	list_add(&pin->list, &regulator_ena_gpio_list);

@@ -2244,6 +2251,10 @@ static int regulator_ena_gpio_request(struct regulator_dev *rdev,
 update_ena_gpio_to_rdev:
 	pin->request_count++;
 	rdev->ena_pin = pin;
+
+	mutex_unlock(&regulator_list_mutex);
+	kfree(new_pin);
+
 	return 0;
 }

@@ -5137,9 +5148,7 @@ regulator_register(const struct regulator_desc *regulator_desc,
 	}
 
 	if (config->ena_gpiod) {
-		mutex_lock(&regulator_list_mutex);
 		ret = regulator_ena_gpio_request(rdev, config);
-		mutex_unlock(&regulator_list_mutex);
 		if (ret != 0) {
 			rdev_err(rdev, "Failed to request enable GPIO: %d\n",
 				 ret);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:47 UTC #6 lore raw

PATCH 6/177 regulator: remove superfluous lock in regulator_resolve_coupling()

From: Michał Mirosław <[email protected]>

[ Upstream commit a577f3456c0a2fac3dee037c483753e6e68f3e49 ]

The code modifies rdev, but locks c_rdev instead. Remove the lock as this is held together by regulator_list_mutex taken in the caller.

Fixes f9503385b187 ("regulator: core: Mutually resolve regulators coupling")

Link https://lore.kernel.org/r/25eb81cefb37a646f3e44eaaf1d8ae8881cfde52.1597195321.git.mirq-linux@rere.qmqm.pl open here

Reviewed-by Dmitry Osipenko <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/regulator/core.c | 4 ----
 1 file changed, 4 deletions(-)

drivers/regulator/core.c +0 -4

index 86107d2e1733e..0ba5ca7082afd 100644
@@ -4891,13 +4891,9 @@ static void regulator_resolve_coupling(struct regulator_dev *rdev)
 			return;
 		}
 
-		regulator_lock(c_rdev);
-
 		c_desc->coupled_rdevs[i] = c_rdev;
 		c_desc->n_resolved++;
 
-		regulator_unlock(c_rdev);
-
 		regulator_resolve_coupling(c_rdev);
 	}
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:44 UTC #7 lore raw

PATCH 7/177 ARM: dts: socfpga: fix register entry for timer3 on Arria10

From: Dinh Nguyen <[email protected]>

[ Upstream commit 0ff5a4812be4ebd4782bbb555d369636eea164f7 ]

Fixes the register address for the timer3 entry on Arria10.

Fixes 475dc86d08de4 ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC")

Signed-off-by Dinh Nguyen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/socfpga_arria10.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/socfpga_arria10.dtsi +1 -1

index 8f614c4b0e3eb..9c71472c237bd 100644
@@ -819,7 +819,7 @@
 		timer3: timer3@ffd00100 {
 			compatible = "snps,dw-apb-timer";
 			interrupts = <0 118 IRQ_TYPE_LEVEL_HIGH>;
-			reg = <0xffd01000 0x100>;
+			reg = <0xffd00100 0x100>;
 			clocks = <&l4_sys_free_clk>;
 			clock-names = "timer";
 			resets = <&rst L4SYSTIMER1_RESET>;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:48 UTC #8 lore raw

PATCH 8/177 ARM: dts: omap5: Fix DSI base address and clocks

From: David Shah <[email protected]>

[ Upstream commit 6542e2b613c2b1952e83973dc434831332ce8e27 ]

DSI was not probing due to base address off by 0x1000, and sys_clk missing.

With this patch, the Pyra display works if HDMI is disabled in the device tree.

Fixes 5a507162f096 ("ARM: dts: Configure interconnect target module for omap5 dsi1")

Signed-off-by David Shah <[email protected]>

Tested-by H. Nikolaus Schaller <[email protected]>

[[email protected]: standardized subject line, added fixes tag]

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/omap5.dtsi | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

arch/arm/boot/dts/omap5.dtsi +11 -9

index fb889c5b00c9d..de55ac5e60f39 100644
@@ -463,11 +463,11 @@
 					};
 				};
 
-				target-module@5000 {
+				target-module@4000 {
 					compatible = "ti,sysc-omap2", "ti,sysc";
-					reg = <0x5000 0x4>,
-					      <0x5010 0x4>,
-					      <0x5014 0x4>;
+					reg = <0x4000 0x4>,
+					      <0x4010 0x4>,
+					      <0x4014 0x4>;
 					reg-names = "rev", "sysc", "syss";
 					ti,sysc-sidle = <SYSC_IDLE_FORCE>,
 							<SYSC_IDLE_NO>,

@@ -479,7 +479,7 @@
 					ti,syss-mask = <1>;
 					#address-cells = <1>;
 					#size-cells = <1>;
-					ranges = <0 0x5000 0x1000>;
+					ranges = <0 0x4000 0x1000>;
 
 					dsi1: encoder@0 {
 						compatible = "ti,omap5-dsi";

@@ -489,8 +489,9 @@
 						reg-names = "proto", "phy", "pll";
 						interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
 						status = "disabled";
-						clocks = <&dss_clkctrl OMAP5_DSS_CORE_CLKCTRL 8>;
-						clock-names = "fck";
+						clocks = <&dss_clkctrl OMAP5_DSS_CORE_CLKCTRL 8>,
+							 <&dss_clkctrl OMAP5_DSS_CORE_CLKCTRL 10>;
+						clock-names = "fck", "sys_clk";
 					};
 				};

@@ -520,8 +521,9 @@
 						reg-names = "proto", "phy", "pll";
 						interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
 						status = "disabled";
-						clocks = <&dss_clkctrl OMAP5_DSS_CORE_CLKCTRL 8>;
-						clock-names = "fck";
+						clocks = <&dss_clkctrl OMAP5_DSS_CORE_CLKCTRL 8>,
+							 <&dss_clkctrl OMAP5_DSS_CORE_CLKCTRL 10>;
+						clock-names = "fck", "sys_clk";
 					};
 				};

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:45 UTC #9 lore raw

PATCH 9/177 selftests/timers: Turn off timeout setting

https://bugs.launchpad.net/bugs/1864626

From: Po-Hsu Lin <[email protected]>

[ Upstream commit 5c1e4f7e9e49b6925b1fb5c507d2c614f3edb292 ]

The following 4 tests in timers can take longer than the default 45 seconds that added in commit 852c8cbf34d3 ("selftests/kselftest/runner.sh:
Add 45 second timeout per test") to run:
* nsleep-lat - 2m7.350s
* set-timer-lat - 2m0.66s
* inconsistency-check - 1m45.074s
* raw_skew - 2m0.013s

Thus they will be marked as failed with the current 45s setting:
not ok 3 selftests: timers: nsleep-lat # TIMEOUT
not ok 4 selftests: timers: set-timer-lat # TIMEOUT not ok 6 selftests: timers: inconsistency-check # TIMEOUT not ok 7 selftests: timers: raw_skew # TIMEOUT

Disable the timeout setting for timers can make these tests finish properly:
ok 3 selftests: timers: nsleep-lat
ok 4 selftests: timers: set-timer-lat
ok 6 selftests: timers: inconsistency-check
ok 7 selftests: timers: raw_skew

Fixes 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test")

Signed-off-by Po-Hsu Lin <[email protected]>

Acked-by John Stultz <[email protected]>

Signed-off-by Shuah Khan <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 tools/testing/selftests/timers/Makefile | 1 +
 tools/testing/selftests/timers/settings | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 tools/testing/selftests/timers/settings

tools/testing/selftests/timers/Makefile +1 -0

index 7656c7ce79d90..0e73a16874c4c 100644
@@ -13,6 +13,7 @@ DESTRUCTIVE_TESTS = alarmtimer-suspend valid-adjtimex adjtick change_skew \
 
 TEST_GEN_PROGS_EXTENDED = $(DESTRUCTIVE_TESTS)
 
+TEST_FILES := settings
 
 include ../lib.mk

tools/testing/selftests/timers/settings new file +1 -0

new file mode 100644
index 0000000000000..e7b9417537fbc
@@ -0,0 +1 @@
+timeout=0

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #10 lore raw

PATCH 10/177 ARM: dts: ls1021a: fix QuadSPI-memory reg range

From: Matthias Schiffer <[email protected]>

[ Upstream commit 81dbbb417da4d1ac407dca5b434d39d5b6b91ef3 ]

According to the Reference Manual, the correct size is 512 MiB.

Without this fix, probing the QSPI fails:

fsl-quadspi 1550000.spi: ioremap failed for resource
[mem 0x40000000-0x7fffffff]
fsl-quadspi 1550000.spi: Freescale QuadSPI probe failed
fsl-quadspi: probe of 1550000.spi failed with error -12

Fixes 85f8ee78ab72 ("ARM: dts: ls1021a: Add support for QSPI with ls1021a SoC")

Signed-off-by Matthias Schiffer <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/ls1021a.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/ls1021a.dtsi +1 -1

index b2ff27af090ec..9435ce527e855 100644
@@ -181,7 +181,7 @@
 			#address-cells = <1>;
 			#size-cells = <0>;
 			reg = <0x0 0x1550000 0x0 0x10000>,
-			      <0x0 0x40000000 0x0 0x40000000>;
+			      <0x0 0x40000000 0x0 0x20000000>;
 			reg-names = "QuadSPI", "QuadSPI-memory";
 			interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
 			clock-names = "qspi_en", "qspi";

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:51 UTC #11 lore raw

PATCH 11/177 ARM: dts: imx7ulp: Correct gpio ranges

From: Anson Huang <[email protected]>

[ Upstream commit deb6323b739c54e1a1e83cd3a2bae4901e3eebf6 ]

Correct gpio ranges according to i.MX7ULP pinctrl driver:

gpio_ptc: ONLY pin 0~19 are available;
gpio_ptd: ONLY pin 0~11 are available;
gpio_pte: ONLY pin 0~15 are available;
gpio_ptf: ONLY pin 0~19 are available;

Fixes 20434dc92c05 ("ARM: dts: imx: add common imx7ulp dtsi support")

Signed-off-by Anson Huang <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/imx7ulp.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm/boot/dts/imx7ulp.dtsi +4 -4

index f7c4878534c8e..1bff3efe8aafe 100644
@@ -394,7 +394,7 @@
 			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
 				 <&pcc3 IMX7ULP_CLK_PCTLC>;
 			clock-names = "gpio", "port";
-			gpio-ranges = <&iomuxc1 0 0 32>;
+			gpio-ranges = <&iomuxc1 0 0 20>;
 		};
 
 		gpio_ptd: gpio@40af0000 {

@@ -408,7 +408,7 @@
 			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
 				 <&pcc3 IMX7ULP_CLK_PCTLD>;
 			clock-names = "gpio", "port";
-			gpio-ranges = <&iomuxc1 0 32 32>;
+			gpio-ranges = <&iomuxc1 0 32 12>;
 		};
 
 		gpio_pte: gpio@40b00000 {

@@ -422,7 +422,7 @@
 			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
 				 <&pcc3 IMX7ULP_CLK_PCTLE>;
 			clock-names = "gpio", "port";
-			gpio-ranges = <&iomuxc1 0 64 32>;
+			gpio-ranges = <&iomuxc1 0 64 16>;
 		};
 
 		gpio_ptf: gpio@40b10000 {

@@ -436,7 +436,7 @@
 			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
 				 <&pcc3 IMX7ULP_CLK_PCTLF>;
 			clock-names = "gpio", "port";
-			gpio-ranges = <&iomuxc1 0 96 32>;
+			gpio-ranges = <&iomuxc1 0 96 20>;
 		};
 	};

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:48 UTC #12 lore raw

PATCH 12/177 arm64: dts: imx: Add missing imx8mm-beacon-kit.dtb to build

From: Rob Herring <[email protected]>

[ Upstream commit 56e79dfd036b538940227fb31371c1cd67b2467f ]

The imx8mm-beacon-kit.dtb was never added to dtbs-y and wasn't getting built. Fix it.

Fixes 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit")

Cc Shawn Guo <[email protected]>

Cc Sascha Hauer <[email protected]>

Cc Pengutronix Kernel Team <[email protected]>

Cc Fabio Estevam <[email protected]>

Cc NXP Linux Team <[email protected]>

Signed-off-by Rob Herring <[email protected]>

Reviewed-by Fabio Estevam <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/boot/dts/freescale/Makefile | 1 +
 1 file changed, 1 insertion(+)

arch/arm64/boot/dts/freescale/Makefile +1 -0

index a39f0a1723e02..903c0eb61290d 100644
@@ -28,6 +28,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-honeycomb.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-qds.dtb
 dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
 
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #13 lore raw

PATCH 13/177 ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy

From: Chris Healy <[email protected]>

[ Upstream commit 5cbb80d5236b47b149da292b86d5fc99a680894b ]

Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") the networking is broken on the imx7d-zii-rmu2 board.

The end result is that network receive behaviour is marginal with lots of RX CRC errors experienced and NFS frequently failing.

Quoting the explanation from Andrew Lunn in commit 0672d22a19244 ("ARM: dts: imx: Fix the AR803X phy-mode"):

"The problem here is, all the DTs were broken since day 0. However, because the PHY driver was also broken, nobody noticed and it worked. Now that the PHY driver has been fixed, all the bugs in the DTs now become an issue"

Fix it by switching to phy-mode = "rgmii-id".

Fixes bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY")

Signed-off-by Chris Healy <[email protected]>

Reviewed-by Fabio Estevam <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/imx7d-zii-rmu2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/imx7d-zii-rmu2.dts +1 -1

index e5e20b07f184b..7cb6153fc650b 100644
@@ -58,7 +58,7 @@
 			  <&clks IMX7D_ENET1_TIME_ROOT_CLK>;
 	assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
 	assigned-clock-rates = <0>, <100000000>;
-	phy-mode = "rgmii";
+	phy-mode = "rgmii-id";
 	phy-handle = <&fec1_phy>;
 	status = "okay";

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #14 lore raw

PATCH 14/177 RDMA/rtrs-srv: Replace device_register with device_initialize and device_add

From: Md Haris Iqbal <[email protected]>

[ Upstream commit baa5b28b7a474f66a511ebf71a2ade510652a2f6 ]

There are error cases when we will call free_srv before device kobject is initialized; in such cases calling put_device generates the following warning:

kobject: '(null)' (000000009f5445ed): is not initialized, yet kobject_put() is being called.

So call device_initialize() only once when the server is allocated. If we end up calling put_srv() and subsequently free_srv(), our call to put_device() would result in deletion of the obj. Call device_add() later when we actually have a connection. Correspondingly, call device_del() instead of device_unregister() when srv->dev_ref falls to 0.

Fixes 9cb837480424 ("RDMA/rtrs: server: main functionality")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Md Haris Iqbal <[email protected]>

Reviewed-by Jack Wang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 8 ++++----
 drivers/infiniband/ulp/rtrs/rtrs-srv.c       | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c +4 -4

index 3d7877534bcc9..2f981ae970767 100644
@@ -182,16 +182,16 @@ static int rtrs_srv_create_once_sysfs_root_folders(struct rtrs_srv_sess *sess)
 	 * sysfs files are created
 	 */
 	dev_set_uevent_suppress(&srv->dev, true);
-	err = device_register(&srv->dev);
+	err = device_add(&srv->dev);
 	if (err) {
-		pr_err("device_register(): %d\n", err);
+		pr_err("device_add(): %d\n", err);
 		goto put;
 	}
 	srv->kobj_paths = kobject_create_and_add("paths", &srv->dev.kobj);
 	if (!srv->kobj_paths) {
 		err = -ENOMEM;
 		pr_err("kobject_create_and_add(): %d\n", err);
-		device_unregister(&srv->dev);
+		device_del(&srv->dev);
 		goto unlock;
 	}
 	dev_set_uevent_suppress(&srv->dev, false);

@@ -216,7 +216,7 @@ rtrs_srv_destroy_once_sysfs_root_folders(struct rtrs_srv_sess *sess)
 		kobject_del(srv->kobj_paths);
 		kobject_put(srv->kobj_paths);
 		mutex_unlock(&srv->paths_mutex);
-		device_unregister(&srv->dev);
+		device_del(&srv->dev);
 	} else {
 		mutex_unlock(&srv->paths_mutex);
 	}

drivers/infiniband/ulp/rtrs/rtrs-srv.c +1 -0

index a219bd1bdbc26..b61a18e57aeba 100644
@@ -1336,6 +1336,7 @@ static struct rtrs_srv *__alloc_srv(struct rtrs_srv_ctx *ctx,
 	uuid_copy(&srv->paths_uuid, paths_uuid);
 	srv->queue_depth = sess_queue_depth;
 	srv->ctx = ctx;
+	device_initialize(&srv->dev);
 
 	srv->chunks = kcalloc(srv->queue_depth, sizeof(*srv->chunks),
 			      GFP_KERNEL);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #15 lore raw

PATCH 15/177 RDMA/rxe: Fix memleak in rxe_mem_init_user

From: Dinghao Liu <[email protected]>

[ Upstream commit e3ddd6067ee62f6e76ebcf61ff08b2c729ae412b ]

When page_address() fails, umem should be freed just like when rxe_mem_alloc() fails.

Fixes 8700e3e7c485 ("Soft RoCE driver")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Dinghao Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/sw/rxe/rxe_mr.c | 1 +
 1 file changed, 1 insertion(+)

drivers/infiniband/sw/rxe/rxe_mr.c +1 -0

index e83c7b518bfa2..bfb96a0d071bb 100644
@@ -207,6 +207,7 @@ int rxe_mem_init_user(struct rxe_pd *pd, u64 start,
 			vaddr = page_address(sg_page_iter_page(&sg_iter));
 			if (!vaddr) {
 				pr_warn("null vaddr\n");
+				ib_umem_release(umem);
 				err = -ENOMEM;
 				goto err1;
 			}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:50 UTC #16 lore raw

PATCH 16/177 RDMA/rxe: Drop pointless checks in rxe_init_ports

From: Kamal Heib <[email protected]>

[ Upstream commit 6112ef62826e91afbae5446d5d47b38e25f47e3f ]

Both pkey_tbl_len and gid_tbl_len are set in rxe_init_port_param() - so no need to check if they aren't set.

Fixes 8700e3e7c485 ("Soft RoCE driver")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Kamal Heib <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/sw/rxe/rxe.c | 3 ---
 1 file changed, 3 deletions(-)

drivers/infiniband/sw/rxe/rxe.c +0 -3

index 5642eefb4ba1c..c7191b5e04a5a 100644
@@ -147,9 +147,6 @@ static int rxe_init_ports(struct rxe_dev *rxe)
 
 	rxe_init_port_param(port);
 
-	if (!port->attr.pkey_tbl_len || !port->attr.gid_tbl_len)
-		return -EINVAL;
-
 	port->pkey_tbl = kcalloc(port->attr.pkey_tbl_len,
 			sizeof(*port->pkey_tbl), GFP_KERNEL);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #17 lore raw

PATCH 17/177 RDMA/rxe: Fix panic when calling kmem_cache_create()

From: Kamal Heib <[email protected]>

[ Upstream commit d862060a4b43479887ae8e2c0b74a58c4e27e5f3 ]

To avoid the following kernel panic when calling kmem_cache_create() with a NULL pointer from pool_cache(), Block the rxe_param_set_add() from running if the rdma_rxe module is not initialized.

 BUG: unable to handle kernel NULL pointer dereference at 000000000000000b
 PGD 0 P4D 0
 Oops: 0000 [#1] SMP NOPTI
 CPU: 4 PID: 8512 Comm: modprobe Kdump: loaded Not tainted 4.18.0-231.el8.x86_64 #1
 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 10/02/2018
 RIP: 0010:kmem_cache_alloc+0xd1/0x1b0
 Code: 8b 57 18 45 8b 77 1c 48 8b 5c 24 30 0f 1f 44 00 00 5b 48 89 e8 5d 41 5c 41 5d 41 5e 41 5f c3 81 e3 00 00 10 00 75 0e 4d 89 fe <41> f6 47 0b 04 0f 84 6c ff ff ff 4c 89 ff e8 cc da 01 00 49 89 c6
 RSP: 0018:ffffa2b8c773f9d0 EFLAGS: 00010246
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000005
 RDX: 0000000000000004 RSI: 00000000006080c0 RDI: 0000000000000000
 RBP: ffff8ea0a8634fd0 R08: ffffa2b8c773f988 R09: 00000000006000c0
 R10: 0000000000000000 R11: 0000000000000230 R12: 00000000006080c0
 R13: ffffffffc0a97fc8 R14: 0000000000000000 R15: 0000000000000000
 FS:  00007f9138ed9740(0000) GS:ffff8ea4ae800000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000000b CR3: 000000046d59a000 CR4: 00000000003406e0
 Call Trace:
  rxe_alloc+0xc8/0x160 [rdma_rxe]
  rxe_get_dma_mr+0x25/0xb0 [rdma_rxe]
  __ib_alloc_pd+0xcb/0x160 [ib_core]
  ib_mad_init_device+0x296/0x8b0 [ib_core]
  add_client_context+0x11a/0x160 [ib_core]
  enable_device_and_get+0xdc/0x1d0 [ib_core]
  ib_register_device+0x572/0x6b0 [ib_core]
  ? crypto_create_tfm+0x32/0xe0
  ? crypto_create_tfm+0x7a/0xe0
  ? crypto_alloc_tfm+0x58/0xf0
  rxe_register_device+0x19d/0x1c0 [rdma_rxe]
  rxe_net_add+0x3d/0x70 [rdma_rxe]
  ? dev_get_by_name_rcu+0x73/0x90
  rxe_param_set_add+0xaf/0xc0 [rdma_rxe]
  parse_args+0x179/0x370
  ? ref_module+0x1b0/0x1b0
  load_module+0x135e/0x17e0
  ? ref_module+0x1b0/0x1b0
  ? __do_sys_init_module+0x13b/0x180
  __do_sys_init_module+0x13b/0x180
  do_syscall_64+0x5b/0x1a0
  entry_SYSCALL_64_after_hwframe+0x65/0xca
 RIP: 0033:0x7f9137ed296e

This can be triggered if a user tries to use the 'module option' which is not actually a real module option but some idiotic (and thankfully no obsolete) sysfs interface.

Fixes 8700e3e7c485 ("Soft RoCE driver")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Kamal Heib <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/sw/rxe/rxe.c       | 4 ++++
 drivers/infiniband/sw/rxe/rxe.h       | 2 ++
 drivers/infiniband/sw/rxe/rxe_sysfs.c | 5 +++++
 3 files changed, 11 insertions(+)

drivers/infiniband/sw/rxe/rxe.c +4 -0

index c7191b5e04a5a..d6b1236b114ab 100644
@@ -48,6 +48,8 @@ static void rxe_cleanup_ports(struct rxe_dev *rxe)
 
 }
 
+bool rxe_initialized;
+
 /* free resources for a rxe device all objects created for this device must
  * have been destroyed
  */

@@ -345,6 +347,7 @@ static int __init rxe_module_init(void)
 		return err;
 
 	rdma_link_register(&rxe_link_ops);
+	rxe_initialized = true;
 	pr_info("loaded\n");
 	return 0;
 }

@@ -356,6 +359,7 @@ static void __exit rxe_module_exit(void)
 	rxe_net_exit();
 	rxe_cache_exit();
 
+	rxe_initialized = false;
 	pr_info("unloaded\n");
 }

drivers/infiniband/sw/rxe/rxe.h +2 -0

index fb07eed9e4028..cae1b0a24c850 100644
@@ -67,6 +67,8 @@
 
 #define RXE_ROCE_V2_SPORT		(0xc000)
 
+extern bool rxe_initialized;
+
 static inline u32 rxe_crc32(struct rxe_dev *rxe,
 			    u32 crc, void *next, size_t len)
 {

drivers/infiniband/sw/rxe/rxe_sysfs.c +5 -0

index ccda5f5a3bc0a..2af31d421bfc3 100644
@@ -61,6 +61,11 @@ static int rxe_param_set_add(const char *val, const struct kernel_param *kp)
 	struct net_device *ndev;
 	struct rxe_dev *exists;
 
+	if (!rxe_initialized) {
+		pr_err("Module parameters are not supported, use rdma link add or rxe_cfg\n");
+		return -EAGAIN;
+	}
+
 	len = sanitize_arg(val, intf, sizeof(intf));
 	if (!len) {
 		pr_err("add: invalid interface name\n");

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:48 UTC #18 lore raw

PATCH 18/177 RDMA/bnxt_re: Do not report transparent vlan from QP1

From: Selvin Xavier <[email protected]>

[ Upstream commit 2d0e60ee322d512fa6bc62d23a6760b39a380847 ]

QP1 Rx CQE reports transparent VLAN ID in the completion and this is used while reporting the completion for received MAD packet. Check if the vlan id is configured before reporting it in the work completion.

Fixes 84511455ac5b ("RDMA/bnxt_re: report vlan_id and sl in qp1 recv completion")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/hw/bnxt_re/ib_verbs.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

drivers/infiniband/hw/bnxt_re/ib_verbs.c +18 -3

index 8b6ad5cddfce9..dad38aa06403d 100644
@@ -3178,6 +3178,19 @@ static void bnxt_re_process_res_rawqp1_wc(struct ib_wc *wc,
 	wc->wc_flags |= IB_WC_GRH;
 }
 
+static bool bnxt_re_check_if_vlan_valid(struct bnxt_re_dev *rdev,
+					u16 vlan_id)
+{
+	/*
+	 * Check if the vlan is configured in the host.  If not configured, it
+	 * can be a transparent VLAN. So dont report the vlan id.
+	 */
+	if (!__vlan_find_dev_deep_rcu(rdev->netdev,
+				      htons(ETH_P_8021Q), vlan_id))
+		return false;
+	return true;
+}
+
 static bool bnxt_re_is_vlan_pkt(struct bnxt_qplib_cqe *orig_cqe,
 				u16 *vid, u8 *sl)
 {

@@ -3246,9 +3259,11 @@ static void bnxt_re_process_res_shadow_qp_wc(struct bnxt_re_qp *gsi_sqp,
 	wc->src_qp = orig_cqe->src_qp;
 	memcpy(wc->smac, orig_cqe->smac, ETH_ALEN);
 	if (bnxt_re_is_vlan_pkt(orig_cqe, &vlan_id, &sl)) {
-		wc->vlan_id = vlan_id;
-		wc->sl = sl;
-		wc->wc_flags |= IB_WC_WITH_VLAN;
+		if (bnxt_re_check_if_vlan_valid(rdev, vlan_id)) {
+			wc->vlan_id = vlan_id;
+			wc->sl = sl;
+			wc->wc_flags |= IB_WC_WITH_VLAN;
+		}
 	}
 	wc->port_num = 1;
 	wc->vendor_err = orig_cqe->status;

Signature · 1 line

2.25.1

Shuah Khan

2020-09-15 21:06 UTC #19 lore raw

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271

Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:

Quoted 9 lines

	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h

Compiled and booted fine. wifi died:

ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)

This is regression from 5.8.9 and 5.9-rc5 works just fine.

I will try to bisect later this evening to see if I can isolate the commit.

thanks,
-- Shuah

Shuah Khan

2020-09-16 02:54 UTC #20 lore raw

Quoted 23 lines · Shuah Khan

Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 8 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.8.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:

Quoted 8 lines

ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.

The following commit is what caused ath10k_pci driver problem that killed wifi.

Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer

thanks,
-- Shuah

Greg Kroah-Hartman

author maintainer

2020-09-16 06:29 UTC #21 lore raw

Quoted 34 lines · Shuah Khan

Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.

Quoted 7 lines

The following commit is what caused ath10k_pci driver problem that killed wifi.
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271

Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.

And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...

odd,

greg k-h

Shuah Khan

2020-09-16 18:58 UTC #22 lore raw

Quoted 38 lines · Greg Kroah-Hartman

Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.

Quoted 9 lines

Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.

I am not seeing this on Linux 5.9-rc5 for sure.

Quoted 3 lines

And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...

I don't see this patch in 4.19.146-rc1

Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1

Couldn't find anything obvious.

thanks,
-- Shuah

Greg Kroah-Hartman

author maintainer

2020-09-16 15:42 UTC #23 lore raw

Quoted 49 lines · Shuah Khan

Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.
Quoted 9 lines
Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.

Quoted 7 lines

I am not seeing this on Linux 5.9-rc5 for sure.
Quoted 3 lines
And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...
I don't see this patch in 4.19.146-rc1

It's not there, it's in 5.4.66-rc1, which worked for you somehow, right?

Quoted 4 lines

Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1
Couldn't find anything obvious.

Again, really odd...

I don't have a problem dropping it, but I should drop it from both 5.4.y and 5.8.y, right?

thanks,

greg k-h

Shuah Khan

2020-09-16 18:08 UTC #24 lore raw

Quoted 63 lines · Greg Kroah-Hartman

Quoted 49 lines · Shuah Khan
Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.
Quoted 9 lines
Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.
Quoted 7 lines
I am not seeing this on Linux 5.9-rc5 for sure.
Quoted 3 lines
And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...
I don't see this patch in 4.19.146-rc1
It's not there, it's in 5.4.66-rc1, which worked for you somehow, right?
Quoted 3 lines
Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1

Quoted 7 lines

Quoted 1 line
Couldn't find anything obvious.
Again, really odd...
I don't have a problem dropping it, but I should drop it from both 5.4.y and 5.8.y, right?

Sorry. Yes. Dropping from 5.8 and 5.4 would be great until we figure out why this patch causes problems.

I will continue debugging and let you know what I find.

thanks,
-- Shuah

Greg Kroah-Hartman

author maintainer

2020-09-16 17:25 UTC #25 lore raw

Quoted 68 lines · Shuah Khan

Quoted 67 lines · Greg Kroah-Hartman
Quoted 49 lines · Shuah Khan
Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.
Quoted 9 lines
Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.
Quoted 7 lines
I am not seeing this on Linux 5.9-rc5 for sure.
Quoted 3 lines
And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...
I don't see this patch in 4.19.146-rc1
It's not there, it's in 5.4.66-rc1, which worked for you somehow, right?
Quoted 4 lines
Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1
Couldn't find anything obvious.
Again, really odd...

Quoted 8 lines

Quoted 3 lines
I don't have a problem dropping it, but I should drop it from both 5.4.y and 5.8.y, right?
Sorry. Yes. Dropping from 5.8 and 5.4 would be great until we figure out why this patch causes problems.
I will continue debugging and let you know what I find.

Thanks, now dropped from both trees.

greg k-h

Shuah Khan

Tested-by

2020-09-17 14:39 UTC #26 lore raw

Quoted 69 lines · Greg Kroah-Hartman

Quoted 68 lines · Shuah Khan
Quoted 67 lines · Greg Kroah-Hartman
Quoted 49 lines · Shuah Khan
Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
       https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.
Quoted 9 lines
Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.
Quoted 7 lines
I am not seeing this on Linux 5.9-rc5 for sure.
Quoted 3 lines
And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...
I don't see this patch in 4.19.146-rc1
It's not there, it's in 5.4.66-rc1, which worked for you somehow, right?
Quoted 4 lines
Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1
Couldn't find anything obvious.
Again, really odd...

Quoted 9 lines

Quoted 8 lines
Quoted 3 lines
I don't have a problem dropping it, but I should drop it from both 5.4.y and 5.8.y, right?
Sorry. Yes. Dropping from 5.8 and 5.4 would be great until we figure out why this patch causes problems.
I will continue debugging and let you know what I find.

With this it boots and wifi is good for me. I am very puzzled by why this made a difference to make sure I am not narrowing in on the wrong patch.

Compiled and booted on my test system. No dmesg regressions.

Tested-by Shuah Khan <[email protected]>

thanks,
-- Shuah

Greg Kroah-Hartman

author maintainer

2020-09-17 14:49 UTC #27 lore raw

Quoted 80 lines · Shuah Khan

Quoted 69 lines · Greg Kroah-Hartman
Quoted 68 lines · Shuah Khan
Quoted 67 lines · Greg Kroah-Hartman
Quoted 49 lines · Shuah Khan
Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
       https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.
Quoted 9 lines
Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.
Quoted 7 lines
I am not seeing this on Linux 5.9-rc5 for sure.
Quoted 3 lines
And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...
I don't see this patch in 4.19.146-rc1
It's not there, it's in 5.4.66-rc1, which worked for you somehow, right?
Quoted 4 lines
Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1
Couldn't find anything obvious.
Again, really odd...
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
I don't have a problem dropping it, but I should drop it from both 5.4.y and 5.8.y, right?
Sorry. Yes. Dropping from 5.8 and 5.4 would be great until we figure out why this patch causes problems.
I will continue debugging and let you know what I find.

Quoted 7 lines

With this it boots and wifi is good for me. I am very puzzled by why this made a difference to make sure I am not narrowing in on the wrong patch.
Compiled and booted on my test system. No dmesg regressions.
Tested-by Shuah Khan <[email protected]>

Great, thanks for testing them all and letting me know.

greg k-h

Shuah Khan

2020-09-17 17:06 UTC #28 lore raw

Quoted 78 lines · Greg Kroah-Hartman

Quoted 77 lines · Shuah Khan
Quoted 76 lines · Greg Kroah-Hartman
Quoted 75 lines · Shuah Khan
Quoted 63 lines · Greg Kroah-Hartman
Quoted 49 lines · Shuah Khan
Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.
Quoted 9 lines
Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.
Quoted 7 lines
I am not seeing this on Linux 5.9-rc5 for sure.
Quoted 3 lines
And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...
I don't see this patch in 4.19.146-rc1
It's not there, it's in 5.4.66-rc1, which worked for you somehow, right?
Quoted 3 lines
Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1
Quoted 7 lines
Quoted 1 line
Couldn't find anything obvious.
Again, really odd...
I don't have a problem dropping it, but I should drop it from both 5.4.y and 5.8.y, right?
Sorry. Yes. Dropping from 5.8 and 5.4 would be great until we figure out why this patch causes problems.

Quoted 7 lines

Quoted 7 lines
Quoted 2 lines
Quoted 1 line
I will continue debugging and let you know what I find.
With this it boots and wifi is good for me. I am very puzzled by why this made a difference to make sure I am not narrowing in on the wrong patch.

Update on this. I did a series of reboots and boots with the patch I asked you to drop and I am not seeing the wifi problem.

Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer

With my testing, I think it is an unrelated issue and the error messages from the fw load code path in the driver when wifi failed through me off.

Sorry for making you drop the patch from 5.8.y and 5.4.y. Please include them in the next rc.

thanks,
-- Shuah

Greg Kroah-Hartman

author maintainer

2020-09-17 17:40 UTC #29 lore raw

Quoted 93 lines · Shuah Khan

Quoted 78 lines · Greg Kroah-Hartman
Quoted 77 lines · Shuah Khan
Quoted 76 lines · Greg Kroah-Hartman
Quoted 75 lines · Shuah Khan
Quoted 63 lines · Greg Kroah-Hartman
Quoted 49 lines · Shuah Khan
Quoted 38 lines · Greg Kroah-Hartman
Quoted 37 lines · Shuah Khan
Quoted 24 lines · Shuah Khan
Quoted 11 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.8.10 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 17 Sep 2020 14:06:12 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
        https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.8.10-rc1.gz
Quoted 9 lines
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
linux-5.8.y
and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted fine. wifi died:
Quoted 8 lines
ath10k_pci 0000:02:00.0: could not init core (-110) ath10k_pci 0000:02:00.0: could not probe fw (-110)
This is regression from 5.8.9 and 5.9-rc5 works just fine.
I will try to bisect later this evening to see if I can isolate the commit.
The following commit is what caused ath10k_pci driver problem that killed wifi.
Quoted 9 lines
Quoted 4 lines
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=linux-5.8.y&id=ec0a59266c9c9f46037efd3dcc0323973e102271
Ugh, that's not good, is this also a problem in 5.9-rc5 as well? For reference, this is commit 4965b8cd1bc1 ("firmware_loader: fix memory leak for paged buffer") in Linus's tree.
Quoted 7 lines
I am not seeing this on Linux 5.9-rc5 for sure.
Quoted 3 lines
And it should be showing up in 5.4.y at the moment too, as this patch is in that tree right now...
I don't see this patch in 4.19.146-rc1
It's not there, it's in 5.4.66-rc1, which worked for you somehow, right?
Quoted 3 lines
Linus's tree works for with this patch in. I compared the two files for differences in commit between Linus's tree and 5.8.10-rc1
Quoted 7 lines
Quoted 1 line
Couldn't find anything obvious.
Again, really odd...
I don't have a problem dropping it, but I should drop it from both 5.4.y and 5.8.y, right?
Sorry. Yes. Dropping from 5.8 and 5.4 would be great until we figure out why this patch causes problems.
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
Quoted 1 line
I will continue debugging and let you know what I find.
With this it boots and wifi is good for me. I am very puzzled by why this made a difference to make sure I am not narrowing in on the wrong patch.
Update on this. I did a series of reboots and boots with the patch I asked you to drop and I am not seeing the wifi problem.
Prateek Sood <[email protected]>
firmware_loader: fix memory leak for paged buffer

Quoted 6 lines

With my testing, I think it is an unrelated issue and the error messages from the fw load code path in the driver when wifi failed through me off.
Sorry for making you drop the patch from 5.8.y and 5.4.y. Please include them in the next rc.

No worries, now added back, thanks for testing some more.

greg k-h

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #30 lore raw

PATCH 19/177 RDMA/bnxt_re: Fix the qp table indexing

From: Selvin Xavier <[email protected]>

[ Upstream commit 84cf229f4001c1216afc3e4c7f05e1620a0dd4bc ]

qp->id can be a value outside the max number of qp. Indexing the qp table with the id can cause out of bounds crash. So changing the qp table indexing by (qp->id % max_qp -1).

Allocating one extra entry for QP1. Some adapters create one more than the max_qp requested to accommodate QP1. If the qp->id is 1, store the inforamtion in the last entry of the qp table.

Fixes f218d67ef004 ("RDMA/bnxt_re: Allow posting when QPs are in error")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/hw/bnxt_re/qplib_fp.c   | 22 ++++++++++++++--------
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 10 ++++++----
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.h |  5 +++++
 3 files changed, 25 insertions(+), 12 deletions(-)

drivers/infiniband/hw/bnxt_re/qplib_fp.c +14 -8

index c5e29577cd434..b217208f6bcce 100644
@@ -796,6 +796,7 @@ int bnxt_qplib_create_qp1(struct bnxt_qplib_res *res, struct bnxt_qplib_qp *qp)
 	u16 cmd_flags = 0;
 	u32 qp_flags = 0;
 	u8 pg_sz_lvl;
+	u32 tbl_indx;
 	int rc;
 
 	RCFW_CMD_PREP(req, CREATE_QP1, cmd_flags);

@@ -891,8 +892,9 @@ int bnxt_qplib_create_qp1(struct bnxt_qplib_res *res, struct bnxt_qplib_qp *qp)
 		rq->dbinfo.xid = qp->id;
 		rq->dbinfo.db = qp->dpi->dbr;
 	}
-	rcfw->qp_tbl[qp->id].qp_id = qp->id;
-	rcfw->qp_tbl[qp->id].qp_handle = (void *)qp;
+	tbl_indx = map_qp_id_to_tbl_indx(qp->id, rcfw);
+	rcfw->qp_tbl[tbl_indx].qp_id = qp->id;
+	rcfw->qp_tbl[tbl_indx].qp_handle = (void *)qp;
 
 	return 0;

@@ -950,6 +952,7 @@ int bnxt_qplib_create_qp(struct bnxt_qplib_res *res, struct bnxt_qplib_qp *qp)
 	u32 qp_flags = 0;
 	u8 pg_sz_lvl;
 	u16 max_rsge;
+	u32 tbl_indx;
 
 	RCFW_CMD_PREP(req, CREATE_QP, cmd_flags);

@@ -1118,8 +1121,9 @@ int bnxt_qplib_create_qp(struct bnxt_qplib_res *res, struct bnxt_qplib_qp *qp)
 		rq->dbinfo.xid = qp->id;
 		rq->dbinfo.db = qp->dpi->dbr;
 	}
-	rcfw->qp_tbl[qp->id].qp_id = qp->id;
-	rcfw->qp_tbl[qp->id].qp_handle = (void *)qp;
+	tbl_indx = map_qp_id_to_tbl_indx(qp->id, rcfw);
+	rcfw->qp_tbl[tbl_indx].qp_id = qp->id;
+	rcfw->qp_tbl[tbl_indx].qp_handle = (void *)qp;
 
 	return 0;

@@ -1467,10 +1471,12 @@ int bnxt_qplib_destroy_qp(struct bnxt_qplib_res *res,
 	struct cmdq_destroy_qp req;
 	struct creq_destroy_qp_resp resp;
 	u16 cmd_flags = 0;
+	u32 tbl_indx;
 	int rc;
 
-	rcfw->qp_tbl[qp->id].qp_id = BNXT_QPLIB_QP_ID_INVALID;
-	rcfw->qp_tbl[qp->id].qp_handle = NULL;
+	tbl_indx = map_qp_id_to_tbl_indx(qp->id, rcfw);
+	rcfw->qp_tbl[tbl_indx].qp_id = BNXT_QPLIB_QP_ID_INVALID;
+	rcfw->qp_tbl[tbl_indx].qp_handle = NULL;
 
 	RCFW_CMD_PREP(req, DESTROY_QP, cmd_flags);

@@ -1478,8 +1484,8 @@ int bnxt_qplib_destroy_qp(struct bnxt_qplib_res *res,
 	rc = bnxt_qplib_rcfw_send_message(rcfw, (void *)&req,
 					  (void *)&resp, NULL, 0);
 	if (rc) {
-		rcfw->qp_tbl[qp->id].qp_id = qp->id;
-		rcfw->qp_tbl[qp->id].qp_handle = qp;
+		rcfw->qp_tbl[tbl_indx].qp_id = qp->id;
+		rcfw->qp_tbl[tbl_indx].qp_handle = qp;
 		return rc;
 	}

drivers/infiniband/hw/bnxt_re/qplib_rcfw.c +6 -4

index 4e211162acee2..f7736e34ac64c 100644
@@ -307,14 +307,15 @@ static int bnxt_qplib_process_qp_event(struct bnxt_qplib_rcfw *rcfw,
 	__le16  mcookie;
 	u16 cookie;
 	int rc = 0;
-	u32 qp_id;
+	u32 qp_id, tbl_indx;
 
 	pdev = rcfw->pdev;
 	switch (qp_event->event) {
 	case CREQ_QP_EVENT_EVENT_QP_ERROR_NOTIFICATION:
 		err_event = (struct creq_qp_error_notification *)qp_event;
 		qp_id = le32_to_cpu(err_event->xid);
-		qp = rcfw->qp_tbl[qp_id].qp_handle;
+		tbl_indx = map_qp_id_to_tbl_indx(qp_id, rcfw);
+		qp = rcfw->qp_tbl[tbl_indx].qp_handle;
 		dev_dbg(&pdev->dev, "Received QP error notification\n");
 		dev_dbg(&pdev->dev,
 			"qpid 0x%x, req_err=0x%x, resp_err=0x%x\n",

@@ -615,8 +616,9 @@ int bnxt_qplib_alloc_rcfw_channel(struct bnxt_qplib_res *res,
 
 	cmdq->bmap_size = bmap_size;
 
-	rcfw->qp_tbl_size = qp_tbl_sz;
-	rcfw->qp_tbl = kcalloc(qp_tbl_sz, sizeof(struct bnxt_qplib_qp_node),
+	/* Allocate one extra to hold the QP1 entries */
+	rcfw->qp_tbl_size = qp_tbl_sz + 1;
+	rcfw->qp_tbl = kcalloc(rcfw->qp_tbl_size, sizeof(struct bnxt_qplib_qp_node),
 			       GFP_KERNEL);
 	if (!rcfw->qp_tbl)
 		goto fail;

drivers/infiniband/hw/bnxt_re/qplib_rcfw.h +5 -0

index 157387636d004..5f2f0a5a3560f 100644
@@ -216,4 +216,9 @@ int bnxt_qplib_deinit_rcfw(struct bnxt_qplib_rcfw *rcfw);
 int bnxt_qplib_init_rcfw(struct bnxt_qplib_rcfw *rcfw,
 			 struct bnxt_qplib_ctx *ctx, int is_virtfn);
 void bnxt_qplib_mark_qp_error(void *qp_handle);
+static inline u32 map_qp_id_to_tbl_indx(u32 qid, struct bnxt_qplib_rcfw *rcfw)
+{
+	/* Last index of the qp_tbl is for QP1 ie. qp_tbl_size - 1*/
+	return (qid == 1) ? rcfw->qp_tbl_size - 1 : qid % rcfw->qp_tbl_size - 2;
+}
 #endif /* __BNXT_QPLIB_RCFW_H__ */

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:49 UTC #31 lore raw

PATCH 20/177 RDMA/bnxt_re: Static NQ depth allocation

From: Naresh Kumar PBS <[email protected]>

[ Upstream commit f86b31c6a28f06eed3f6d9dc958079853b0792f1 ]

At first, driver allocates memory for NQ based on qplib_ctx->cq_count and qplib_ctx->srqc_count. Later when creating ring, it uses a static value of 128K -1.

Fixing this with a static value for now.

Fixes b08fe048a69d ("RDMA/bnxt_re: Refactor net ring allocation function")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Naresh Kumar PBS <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/hw/bnxt_re/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/infiniband/hw/bnxt_re/main.c +1 -2

index 5c41e13496a02..882c4f49d3a87 100644
@@ -1027,8 +1027,7 @@ static int bnxt_re_alloc_res(struct bnxt_re_dev *rdev)
 		struct bnxt_qplib_nq *nq;
 
 		nq = &rdev->nq[i];
-		nq->hwq.max_elements = (qplib_ctx->cq_count +
-					qplib_ctx->srqc_count + 2);
+		nq->hwq.max_elements = BNXT_QPLIB_NQE_MAX_CNT;
 		rc = bnxt_qplib_alloc_nq(&rdev->qplib_res, &rdev->nq[i]);
 		if (rc) {
 			ibdev_err(&rdev->ibdev, "Alloc Failed NQ%d rc:%#x",

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:33 UTC #32 lore raw

PATCH 21/177 RDMA/bnxt_re: Fix driver crash on unaligned PSN entry address

From: Naresh Kumar PBS <[email protected]>

[ Upstream commit 934d0ac9a64d21523e3ad03ea4098da7826bc788 ]

When computing the first psn entry, driver checks for page alignment. If this address is not page aligned,it attempts to compute the offset in that page for later use by using ALIGN macro. ALIGN macro does not return offset bytes but the requested aligned address and hence cannot be used directly to store as offset. Since driver was using the address itself instead of offset, it resulted in invalid address when filling the psn buffer.

Fixed driver to use PAGE_MASK macro to calculate the offset.

Fixes fddcbbb02af4 ("RDMA/bnxt_re: Simplify obtaining queue entry from hw ring")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Naresh Kumar PBS <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/hw/bnxt_re/qplib_fp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/infiniband/hw/bnxt_re/qplib_fp.c +2 -2

index b217208f6bcce..4b53f79b91d1d 100644
@@ -922,10 +922,10 @@ static void bnxt_qplib_init_psn_ptr(struct bnxt_qplib_qp *qp, int size)
 	sq = &qp->sq;
 	hwq = &sq->hwq;
 
+	/* First psn entry */
 	fpsne = (u64)bnxt_qplib_get_qe(hwq, hwq->max_elements, &psn_pg);
 	if (!IS_ALIGNED(fpsne, PAGE_SIZE))
-		indx_pad = ALIGN(fpsne, PAGE_SIZE) / size;
-
+		indx_pad = (fpsne & ~PAGE_MASK) / size;
 	page = (u64 *)psn_pg;
 	for (indx = 0; indx < hwq->max_elements; indx++) {
 		pg_num = (indx + indx_pad) / (PAGE_SIZE / size);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:48 UTC #33 lore raw

PATCH 22/177 RDMA/bnxt_re: Remove the qp from list only if the qp destroy succeeds

From: Selvin Xavier <[email protected]>

[ Upstream commit 097a9d23b7250355b182c5fd47dd4c55b22b1c33 ]

Driver crashes when destroy_qp is re-tried because of an error returned. This is because the qp entry was removed from the qp list during the first call.

Remove qp from the list only if destroy_qp returns success.

The driver will still trigger a WARN_ON due to the memory leaking, but at least it isn't corrupting memory too.

Fixes 8dae419f9ec7 ("RDMA/bnxt_re: Refactor queue pair creation code")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/hw/bnxt_re/ib_verbs.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

drivers/infiniband/hw/bnxt_re/ib_verbs.c +11 ~~-11~~

index dad38aa06403d..cb6e873039df5 100644
@@ -752,12 +752,6 @@ static int bnxt_re_destroy_gsi_sqp(struct bnxt_re_qp *qp)
 	gsi_sqp = rdev->gsi_ctx.gsi_sqp;
 	gsi_sah = rdev->gsi_ctx.gsi_sah;
 
-	/* remove from active qp list */
-	mutex_lock(&rdev->qp_lock);
-	list_del(&gsi_sqp->list);
-	mutex_unlock(&rdev->qp_lock);
-	atomic_dec(&rdev->qp_count);
-
 	ibdev_dbg(&rdev->ibdev, "Destroy the shadow AH\n");
 	bnxt_qplib_destroy_ah(&rdev->qplib_res,
 			      &gsi_sah->qplib_ah,

@@ -772,6 +766,12 @@ static int bnxt_re_destroy_gsi_sqp(struct bnxt_re_qp *qp)
 	}
 	bnxt_qplib_free_qp_res(&rdev->qplib_res, &gsi_sqp->qplib_qp);
 
+	/* remove from active qp list */
+	mutex_lock(&rdev->qp_lock);
+	list_del(&gsi_sqp->list);
+	mutex_unlock(&rdev->qp_lock);
+	atomic_dec(&rdev->qp_count);
+
 	kfree(rdev->gsi_ctx.sqp_tbl);
 	kfree(gsi_sah);
 	kfree(gsi_sqp);

@@ -792,11 +792,6 @@ int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
 	unsigned int flags;
 	int rc;
 
-	mutex_lock(&rdev->qp_lock);
-	list_del(&qp->list);
-	mutex_unlock(&rdev->qp_lock);
-	atomic_dec(&rdev->qp_count);
-
 	bnxt_qplib_flush_cqn_wq(&qp->qplib_qp);
 
 	rc = bnxt_qplib_destroy_qp(&rdev->qplib_res, &qp->qplib_qp);

@@ -819,6 +814,11 @@ int bnxt_re_destroy_qp(struct ib_qp *ib_qp, struct ib_udata *udata)
 			goto sh_fail;
 	}
 
+	mutex_lock(&rdev->qp_lock);
+	list_del(&qp->list);
+	mutex_unlock(&rdev->qp_lock);
+	atomic_dec(&rdev->qp_count);
+
 	ib_umem_release(qp->rumem);
 	ib_umem_release(qp->sumem);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:43 UTC #34 lore raw

PATCH 23/177 drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux()

From: Yu Kuai <[email protected]>

[ Upstream commit 07b5b12d97dc9f47ff3dff46c4f944a15bd762e5 ]

If sun8i_r40_tcon_tv_set_mux() succeed, sun8i_r40_tcon_tv_set_mux() doesn't have a corresponding put_device(). Thus add put_device() to fix the exception handling for this function implementation.

Fixes 0305189afb32 ("drm/sun4i: tcon: Add support for R40 TCON")

Signed-off-by Yu Kuai <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/gpu/drm/sun4i/sun4i_tcon.c +6 -2

index 359b56e43b83c..24d95f058918c 100644
@@ -1433,14 +1433,18 @@ static int sun8i_r40_tcon_tv_set_mux(struct sun4i_tcon *tcon,
 	if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP) &&
 	    encoder->encoder_type == DRM_MODE_ENCODER_TMDS) {
 		ret = sun8i_tcon_top_set_hdmi_src(&pdev->dev, id);
-		if (ret)
+		if (ret) {
+			put_device(&pdev->dev);
 			return ret;
+		}
 	}
 
 	if (IS_ENABLED(CONFIG_DRM_SUN8I_TCON_TOP)) {
 		ret = sun8i_tcon_top_de_config(&pdev->dev, tcon->id, id);
-		if (ret)
+		if (ret) {
+			put_device(&pdev->dev);
 			return ret;
+		}
 	}
 
 	return 0;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #35 lore raw

PATCH 24/177 arm64: dts: imx8mq: Fix TMU interrupt property

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit 1f2f98f2703e8134678fe20982886085631eda23 ]

"interrupt" is not a valid property. Using proper name fixes dtbs_check warning:

arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-zest.dt.yaml: tmu@30260000: 'interrupts' is a required property

Fixes e464fd2ba4d4 ("arm64: dts: imx8mq: enable the multi sensor TMU")

Signed-off-by Krzysztof Kozlowski <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/boot/dts/freescale/imx8mq.dtsi +1 -1

index 978f8122c0d2c..66ac66856e7e8 100644
@@ -420,7 +420,7 @@
 			tmu: tmu@30260000 {
 				compatible = "fsl,imx8mq-tmu";
 				reg = <0x30260000 0x10000>;
-				interrupt = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+				interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
 				clocks = <&clk IMX8MQ_CLK_TMU_ROOT>;
 				little-endian;
 				fsl,tmu-range = <0xb0000 0xa0026 0x80048 0x70061>;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:37 UTC #36 lore raw

PATCH 25/177 drm/sun4i: Fix dsi dcs long write function

From: Ondrej Jirman <[email protected]>

[ Upstream commit fd90e3808fd2c207560270c39b86b71af2231aa1 ]

It's writing too much data. regmap_bulk_write expects number of register sized chunks to write, not a byte sized length of the bounce buffer. Bounce buffer needs to be padded too, so that regmap_bulk_write will not read past the end of the buffer.

Fixes 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")

Signed-off-by Ondrej Jirman <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Reviewed-by Jernej Skrabec <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c +2 -2

index aa67cb037e9d1..32d4c3f7fc4eb 100644
@@ -889,7 +889,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi *dsi,
 	regmap_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(0),
 		     sun6i_dsi_dcs_build_pkt_hdr(dsi, msg));
 
-	bounce = kzalloc(msg->tx_len + sizeof(crc), GFP_KERNEL);
+	bounce = kzalloc(ALIGN(msg->tx_len + sizeof(crc), 4), GFP_KERNEL);
 	if (!bounce)
 		return -ENOMEM;

@@ -900,7 +900,7 @@ static int sun6i_dsi_dcs_write_long(struct sun6i_dsi *dsi,
 	memcpy((u8 *)bounce + msg->tx_len, &crc, sizeof(crc));
 	len += sizeof(crc);
 
-	regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce, len);
+	regmap_bulk_write(dsi->regs, SUN6I_DSI_CMD_TX_REG(1), bounce, DIV_ROUND_UP(len, 4));
 	regmap_write(dsi->regs, SUN6I_DSI_CMD_CTL_REG, len + 4 - 1);
 	kfree(bounce);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:55 UTC #37 lore raw

PATCH 26/177 scsi: qla2xxx: Fix regression on sparc64

From: René Rebe <[email protected]>

[ Upstream commit 2a87d485c4cb4d1b34be6c278a1c6ce3e15c8b8a ]

Commit 98aee70d19a7 ("qla2xxx: Add endianizer to max_payload_size modifier.") in 2014 broke qla2xxx on sparc64, e.g. as in the Sun Blade 1000 / 2000. Unbreak by partial revert to fix endianness in nvram firmware default initialization. Also mark the second frame_payload_size in nvram_t __le16 to avoid new sparse warnings.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 98aee70d19a7 ("qla2xxx: Add endianizer to max_payload_size modifier.")

Reviewed-by Himanshu Madhani <[email protected]>

Reviewed-by Bart Van Assche <[email protected]>

Acked-by Arun Easi <[email protected]>

Signed-off-by René Rebe <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/qla2xxx/qla_def.h  | 2 +-
 drivers/scsi/qla2xxx/qla_init.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

drivers/scsi/qla2xxx/qla_def.h +1 -1

index 42dbf90d46510..392312333746f 100644
@@ -1605,7 +1605,7 @@ typedef struct {
 	 */
 	uint8_t	 firmware_options[2];
 
-	uint16_t frame_payload_size;
+	__le16	frame_payload_size;
 	__le16	max_iocb_allocation;
 	__le16	execution_throttle;
 	uint8_t	 retry_count;

drivers/scsi/qla2xxx/qla_init.c +3 -3

index 2436a17f5cd91..2861c636dd651 100644
@@ -4603,18 +4603,18 @@ qla2x00_nvram_config(scsi_qla_host_t *vha)
 			nv->firmware_options[1] = BIT_7 | BIT_5;
 			nv->add_firmware_options[0] = BIT_5;
 			nv->add_firmware_options[1] = BIT_5 | BIT_4;
-			nv->frame_payload_size = 2048;
+			nv->frame_payload_size = cpu_to_le16(2048);
 			nv->special_options[1] = BIT_7;
 		} else if (IS_QLA2200(ha)) {
 			nv->firmware_options[0] = BIT_2 | BIT_1;
 			nv->firmware_options[1] = BIT_7 | BIT_5;
 			nv->add_firmware_options[0] = BIT_5;
 			nv->add_firmware_options[1] = BIT_5 | BIT_4;
-			nv->frame_payload_size = 1024;
+			nv->frame_payload_size = cpu_to_le16(1024);
 		} else if (IS_QLA2100(ha)) {
 			nv->firmware_options[0] = BIT_3 | BIT_1;
 			nv->firmware_options[1] = BIT_5;
-			nv->frame_payload_size = 1024;
+			nv->frame_payload_size = cpu_to_le16(1024);
 		}
 
 		nv->max_iocb_allocation = cpu_to_le16(256);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #38 lore raw

PATCH 27/177 iio: adc: mcp3422: fix locking on error path

From: Angelo Compagnucci <[email protected]>

[ Upstream commit a139ffa40f0c24b753838b8ef3dcf6ad10eb7854 ]

Reading from the chip should be unlocked on error path else the lock could never being released.

Fixes 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC")

Fixes 3f1093d83d71 ("iio: adc: mcp3422: fix locking scope")

Acked-by Jonathan Cameron <[email protected]>

Signed-off-by Angelo Compagnucci <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/iio/adc/mcp3422.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/iio/adc/mcp3422.c +3 -1

index d86c0b5d80a3d..c717981c8fb03 100644
@@ -145,8 +145,10 @@ static int mcp3422_read_channel(struct mcp3422 *adc,
 		config &= ~MCP3422_PGA_MASK;
 		config |= MCP3422_PGA_VALUE(adc->pga[req_channel]);
 		ret = mcp3422_update_config(adc, config);
-		if (ret < 0)
+		if (ret < 0) {
+			mutex_unlock(&adc->lock);
 			return ret;
+		}
 		msleep(mcp3422_read_times[MCP3422_SAMPLE_RATE(adc->config)]);
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #39 lore raw

PATCH 28/177 scsi: libsas: Set data_dir as DMA_NONE if libata marks qc as NODATA

From: Luo Jiaxing <[email protected]>

[ Upstream commit 53de092f47ff40e8d4d78d590d95819d391bf2e0 ]

It was discovered that sdparm will fail when attempting to disable write cache on a SATA disk connected via libsas.

In the ATA command set the write cache state is controlled through the SET FEATURES operation. This is roughly corresponds to MODE SELECT in SCSI and the latter command is what is used in the SCSI-ATA translation layer. A subtle difference is that a MODE SELECT carries data whereas SET FEATURES is defined as a non-data command in ATA.

Set the DMA data direction to DMA_NONE if the requested ATA command is identified as non-data.

[mkp: commit desc]

Fixes fa1c1e8f1ece ("[SCSI] Add SATA support to libsas")

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by John Garry <[email protected]>

Reviewed-by Jason Yan <[email protected]>

Signed-off-by Luo Jiaxing <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/libsas/sas_ata.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/scsi/libsas/sas_ata.c +4 -1

index 5d716d3887071..6de4bc77fd55c 100644
@@ -209,7 +209,10 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd *qc)
 		task->num_scatter = si;
 	}
 
-	task->data_dir = qc->dma_dir;
+	if (qc->tf.protocol == ATA_PROT_NODATA)
+		task->data_dir = DMA_NONE;
+	else
+		task->data_dir = qc->dma_dir;
 	task->scatter = qc->sg;
 	task->ata_task.retry_count = 1;
 	task->task_state_flags = SAS_TASK_STATE_PENDING;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #40 lore raw

PATCH 29/177 drm/virtio: fix unblank

From: Gerd Hoffmann <[email protected]>

[ Upstream commit c6016c6e39c3ee8fd671532520be3cc13e439db2 ]

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that.

v2: use drm_atomic_crtc_needs_modeset() (Daniel).

Link http://patchwork.freedesktop.org/patch/msgid/[email protected]

Fixes 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change")

Signed-off-by Gerd Hoffmann <[email protected]>

Tested-by Jiri Slaby <[email protected]>

Tested-by Diego Viola <[email protected]>

Acked-by Daniel Vetter <[email protected]>

(cherry picked from commit 1bc371cd0ec907bab870cacb6e898105f9c41dc8)

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++++++++++
 drivers/gpu/drm/virtio/virtgpu_drv.h     |  1 +
 drivers/gpu/drm/virtio/virtgpu_plane.c   |  4 +++-
 3 files changed, 15 insertions(+), 1 deletion(-)

drivers/gpu/drm/virtio/virtgpu_display.c +11 -0

index cc7fd957a3072..2b8421a35ab94 100644
@@ -123,6 +123,17 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc *crtc,
 static void virtio_gpu_crtc_atomic_flush(struct drm_crtc *crtc,
 					 struct drm_crtc_state *old_state)
 {
+	struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
+
+	/*
+	 * virtio-gpu can't do modeset and plane update operations
+	 * independent from each other.  So the actual modeset happens
+	 * in the plane update callback, and here we just check
+	 * whenever we must force the modeset.
+	 */
+	if (drm_atomic_crtc_needs_modeset(crtc->state)) {
+		output->needs_modeset = true;
+	}
 }
 
 static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {

drivers/gpu/drm/virtio/virtgpu_drv.h +1 -0

index 9ff9f4ac0522a..4ab1b0ba29253 100644
@@ -138,6 +138,7 @@ struct virtio_gpu_output {
 	int cur_x;
 	int cur_y;
 	bool enabled;
+	bool needs_modeset;
 };
 #define drm_crtc_to_virtio_gpu_output(x) \
 	container_of(x, struct virtio_gpu_output, crtc)

drivers/gpu/drm/virtio/virtgpu_plane.c +3 -1

index 52d24179bcecc..65757409d9ed1 100644
@@ -163,7 +163,9 @@ static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
 	    plane->state->src_w != old_state->src_w ||
 	    plane->state->src_h != old_state->src_h ||
 	    plane->state->src_x != old_state->src_x ||
-	    plane->state->src_y != old_state->src_y) {
+	    plane->state->src_y != old_state->src_y ||
+	    output->needs_modeset) {
+		output->needs_modeset = false;
 		DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
 			  bo->hw_res_handle,
 			  plane->state->crtc_w, plane->state->crtc_h,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:34 UTC #41 lore raw

PATCH 30/177 RDMA/core: Fix unsafe linked list traversal after failing to allocate CQ

From: Xi Wang <[email protected]>

[ Upstream commit 8aa64be019567c4f90d45c5082a4b6f22e182d00 ]

It's not safe to access the next CQ in list_for_each_entry() after invoking ib_free_cq(), because the CQ has already been freed in current iteration. It should be replaced by list_for_each_entry_safe().

Fixes c7ff819aefea ("RDMA/core: Introduce shared CQ pool API")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Xi Wang <[email protected]>

Signed-off-by Weihang Li <[email protected]>

Reviewed-by Jason Gunthorpe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/core/cq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/infiniband/core/cq.c +2 -2

index 513825e424bff..a92fc3f90bb5b 100644
@@ -379,7 +379,7 @@ static int ib_alloc_cqs(struct ib_device *dev, unsigned int nr_cqes,
 {
 	LIST_HEAD(tmp_list);
 	unsigned int nr_cqs, i;
-	struct ib_cq *cq;
+	struct ib_cq *cq, *n;
 	int ret;
 
 	if (poll_ctx > IB_POLL_LAST_POOL_TYPE) {

@@ -412,7 +412,7 @@ static int ib_alloc_cqs(struct ib_device *dev, unsigned int nr_cqes,
 	return 0;
 
 out_free_cqs:
-	list_for_each_entry(cq, &tmp_list, pool_entry) {
+	list_for_each_entry_safe(cq, n, &tmp_list, pool_entry) {
 		cq->shared = false;
 		ib_free_cq(cq);
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:44 UTC #42 lore raw

PATCH 31/177 RDMA/core: Fix reported speed and width

From: Kamal Heib <[email protected]>

[ Upstream commit 28b0865714b315e318ac45c4fc9156f3d4649646 ]

When the returned speed from __ethtool_get_link_ksettings() is SPEED_UNKNOWN this will lead to reporting a wrong speed and width for providers that uses ib_get_eth_speed(), fix that by defaulting the netdev_speed to SPEED_1000 in case the returned value from __ethtool_get_link_ksettings() is SPEED_UNKNOWN.

Fixes d41861942fc5 ("IB/core: Add generic function to extract IB speed from netdev")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Kamal Heib <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/core/verbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/infiniband/core/verbs.c +1 -1

index f369f0a19e851..1b0ea945756f0 100644
@@ -1803,7 +1803,7 @@ int ib_get_eth_speed(struct ib_device *dev, u8 port_num, u8 *speed, u8 *width)
 
 	dev_put(netdev);
 
-	if (!rc) {
+	if (!rc && lksettings.base.speed != (u32)SPEED_UNKNOWN) {
 		netdev_speed = lksettings.base.speed;
 	} else {
 		netdev_speed = SPEED_1000;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:48 UTC #43 lore raw

PATCH 32/177 scsi: megaraid_sas: Dont call disable_irq from process IRQ poll

From: Tomas Henzl <[email protected]>

[ Upstream commit d2af39141eea34ef651961e885f49d96781a1016 ]

disable_irq() might sleep. Replace it with disable_irq_nosync() which is sufficient as irq_poll_scheduled protects against concurrently running complete_cmd_fusion() from megasas_irqpoll() and megasas_isr_fusion().

Link https://lore.kernel.org/r/[email protected] open here

Fixes a6ffd5bf681 scsi: megaraid_sas: Call disable_irq from process IRQ poll

Signed-off-by Tomas Henzl <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/megaraid/megaraid_sas_fusion.c +1 -1

index fcf03f733e417..1a0e2e4342ad8 100644
@@ -3690,7 +3690,7 @@ int megasas_irqpoll(struct irq_poll *irqpoll, int budget)
 	instance = irq_ctx->instance;
 
 	if (irq_ctx->irq_line_enable) {
-		disable_irq(irq_ctx->os_irq);
+		disable_irq_nosync(irq_ctx->os_irq);
 		irq_ctx->irq_line_enable = false;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:43 UTC #44 lore raw

PATCH 33/177 scsi: mpt3sas: Dont call disable_irq from IRQ poll handler

From: Tomas Henzl <[email protected]>

[ Upstream commit b614d55b970d08bcac5b0bc15a5526181b3e4459 ]

disable_irq() might sleep, replace it with disable_irq_nosync(). For synchronisation 'irq_poll_scheduled' is sufficient

Fixes 320e77acb3 scsi: mpt3sas: Irq poll to avoid CPU hard lockups

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Tomas Henzl <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/mpt3sas/mpt3sas_base.c +1 -1

index 96b78fdc6b8a9..a85c9672c6ea3 100644
@@ -1732,7 +1732,7 @@ _base_irqpoll(struct irq_poll *irqpoll, int budget)
 	reply_q = container_of(irqpoll, struct adapter_reply_queue,
 			irqpoll);
 	if (reply_q->irq_line_enable) {
-		disable_irq(reply_q->os_irq);
+		disable_irq_nosync(reply_q->os_irq);
 		reply_q->irq_line_enable = false;
 	}
 	num_entries = _base_process_reply_queue(reply_q);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:44 UTC #45 lore raw

PATCH 34/177 soundwire: fix double free of dangling pointer

From: Tom Rix <[email protected]>

[ Upstream commit 3fbbf2148a406b3e350fe91e6fdd78eb42ecad24 ]

clang static analysis flags this problem

stream.c:844:9: warning: Use of memory after
it is freed

        kfree(bus->defer_msg.msg->buf);
              ^~~~~~~~~~~~~~~~~~~~~~~

This happens in an error handler cleaning up memory allocated for elements in a list.

	list_for_each_entry(m_rt, &stream->master_list, stream_node) {
		bus = m_rt->bus;

		kfree(bus->defer_msg.msg->buf);
		kfree(bus->defer_msg.msg);
	}

And is triggered when the call to sdw_bank_switch() fails. There are a two problems.

First, when sdw_bank_switch() fails, though it frees memory it does not clear bus's reference 'defer_msg.msg' to that memory.

The second problem is the freeing msg->buf. In some cases msg will be NULL so this will dereference a null pointer. Need to check before freeing.

Fixes 99b8a5d608a6 ("soundwire: Add bank switch routine")

Signed-off-by Tom Rix <[email protected]>

Reviewed-by Nick Desaulniers <[email protected]>

Reviewed-by Pierre-Louis Bossart <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/soundwire/stream.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

drivers/soundwire/stream.c +5 -3

index a9a72574b34ab..684761e86d4fc 100644
@@ -716,6 +716,7 @@ error:
 	kfree(wbuf);
 error_1:
 	kfree(wr_msg);
+	bus->defer_msg.msg = NULL;
 	return ret;
 }

@@ -839,9 +840,10 @@ static int do_bank_switch(struct sdw_stream_runtime *stream)
 error:
 	list_for_each_entry(m_rt, &stream->master_list, stream_node) {
 		bus = m_rt->bus;
-
-		kfree(bus->defer_msg.msg->buf);
-		kfree(bus->defer_msg.msg);
+		if (bus->defer_msg.msg) {
+			kfree(bus->defer_msg.msg->buf);
+			kfree(bus->defer_msg.msg);
+		}
 	}
 
 msg_unlock:

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:42 UTC #46 lore raw

PATCH 35/177 Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled"

Link https://lore.kernel.org/r/696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoimboe@redhat.com open here

From: Josh Poimboeuf <[email protected]>

[ Upstream commit 318af7b80b6a6751520cf2b71edb8c45abb9d9d8 ]

Use of the new -flive-patching flag was introduced with the following commit:

43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")

This flag has several drawbacks:

- It disables some optimizations, so it can have a negative effect on performance.

- According to the GCC documentation it's not compatible with LTO, which will become a compatibility issue as LTO support gets upstreamed in the kernel.

- It was intended to be used for source-based patch generation tooling, as opposed to binary-based patch generation tooling (e.g., kpatch-build). It probably should have at least been behind a separate config option so as not to negatively affect other livepatch users.

- Clang doesn't have the flag, so as far as I can tell, this method of generating patches is incompatible with Clang, which like LTO is becoming more mainstream.

- It breaks GCC's implicit noreturn detection for local functions. This is the cause of several "unreachable instruction" objtool warnings.

- The broken noreturn detection is an obvious GCC regression, but we haven't yet gotten GCC developers to acknowledge that, which doesn't inspire confidence in their willingness to keep the feature working as optimizations are added or changed going forward.

- While there *is* a distro which relies on this flag for their distro livepatch module builds, there's not a publicly documented way to create safe livepatch modules with it. Its use seems to be based on tribal knowledge. It serves no benefit to those who don't know how to use it.

(In fact, I believe the current livepatch documentation and samples are misleading and dangerous, and should be corrected. Or at least amended with a disclaimer. But I don't feel qualified to make such changes.)

Also, we have an idea for using objtool to detect function changes, which could potentially obsolete the need for this flag anyway.

At this point the flag has no benefits for upstream which would counteract the above drawbacks. Revert it until it becomes more ready.

This reverts commit 43bd3a95c98e1a86b8b55d97f745c224ecff02b9.

Fixes 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")

Reported-by Randy Dunlap <[email protected]>

Signed-off-by Josh Poimboeuf <[email protected]>

Acked-by Miroslav Benes <[email protected]>

Signed-off-by Petr Mladek <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 Makefile | 4 ----
 1 file changed, 4 deletions(-)

Makefile +0 -4

index 36eab48d1d4a6..3299cc45c1dd0 100644
@@ -876,10 +876,6 @@ KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections
 LDFLAGS_vmlinux += --gc-sections
 endif
 
-ifdef CONFIG_LIVEPATCH
-KBUILD_CFLAGS += $(call cc-option, -flive-patching=inline-clone)
-endif
-
 ifdef CONFIG_SHADOW_CALL_STACK
 CC_FLAGS_SCS	:= -fsanitize=shadow-call-stack
 KBUILD_CFLAGS	+= $(CC_FLAGS_SCS)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:43 UTC #47 lore raw

PATCH 36/177 interconnect: qcom: Fix small BW votes being truncated to zero

From: Mike Tipton <[email protected]>

[ Upstream commit 91e045b93db79a2ef66e045ad0d1f8f9d348e1f4 ]

Small BW votes that translate to less than a single BCM unit are currently truncated to zero. Ensure that non-zero BW requests always result in at least a vote of 1 to BCM.

Fixes 976daac4a1c5 ("interconnect: qcom: Consolidate interconnect RPMh support")

Signed-off-by Mike Tipton <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Georgi Djakov <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/interconnect/qcom/bcm-voter.c | 27 +++++++++++++++++++--------
 1 file changed, 19 insertions(+), 8 deletions(-)

drivers/interconnect/qcom/bcm-voter.c +19 -8

index 2a11a63e7217a..b360dc34c90c7 100644
@@ -52,8 +52,20 @@ static int cmp_vcd(void *priv, struct list_head *a, struct list_head *b)
 		return 1;
 }
 
+static u64 bcm_div(u64 num, u32 base)
+{
+	/* Ensure that small votes aren't lost. */
+	if (num && num < base)
+		return 1;
+
+	do_div(num, base);
+
+	return num;
+}
+
 static void bcm_aggregate(struct qcom_icc_bcm *bcm)
 {
+	struct qcom_icc_node *node;
 	size_t i, bucket;
 	u64 agg_avg[QCOM_ICC_NUM_BUCKETS] = {0};
 	u64 agg_peak[QCOM_ICC_NUM_BUCKETS] = {0};

@@ -61,22 +73,21 @@ static void bcm_aggregate(struct qcom_icc_bcm *bcm)
 
 	for (bucket = 0; bucket < QCOM_ICC_NUM_BUCKETS; bucket++) {
 		for (i = 0; i < bcm->num_nodes; i++) {
-			temp = bcm->nodes[i]->sum_avg[bucket] * bcm->aux_data.width;
-			do_div(temp, bcm->nodes[i]->buswidth * bcm->nodes[i]->channels);
+			node = bcm->nodes[i];
+			temp = bcm_div(node->sum_avg[bucket] * bcm->aux_data.width,
+				       node->buswidth * node->channels);
 			agg_avg[bucket] = max(agg_avg[bucket], temp);
 
-			temp = bcm->nodes[i]->max_peak[bucket] * bcm->aux_data.width;
-			do_div(temp, bcm->nodes[i]->buswidth);
+			temp = bcm_div(node->max_peak[bucket] * bcm->aux_data.width,
+				       node->buswidth);
 			agg_peak[bucket] = max(agg_peak[bucket], temp);
 		}
 
 		temp = agg_avg[bucket] * 1000ULL;
-		do_div(temp, bcm->aux_data.unit);
-		bcm->vote_x[bucket] = temp;
+		bcm->vote_x[bucket] = bcm_div(temp, bcm->aux_data.unit);
 
 		temp = agg_peak[bucket] * 1000ULL;
-		do_div(temp, bcm->aux_data.unit);
-		bcm->vote_y[bucket] = temp;
+		bcm->vote_y[bucket] = bcm_div(temp, bcm->aux_data.unit);
 	}
 
 	if (bcm->keepalive && bcm->vote_x[QCOM_ICC_BUCKET_AMC] == 0 &&

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:43 UTC #48 lore raw

PATCH 37/177 padata: fix possible padata_works_lock deadlock

From: Daniel Jordan <[email protected]>

[ Upstream commit 1b0df11fde0f14a269a181b3b7f5122415bc5ed7 ]

syzbot reports,

WARNING: inconsistent lock state
5.9.0-rc2-syzkaller #0 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. syz-executor.0/26715 takes:
(padata_works_lock){+.?.}-{2:2}, at: padata_do_parallel kernel/padata.c:220 {IN-SOFTIRQ-W} state was registered at:

    spin_lock include/linux/spinlock.h:354 [inline]
    padata_do_parallel kernel/padata.c:220
    ...
    __do_softirq kernel/softirq.c:298
    ...
    sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1091
    asm_sysvec_apic_timer_interrupt arch/x86/include/asm/idtentry.h:581

   Possible unsafe locking scenario:

         CPU0
         ----
    lock(padata_works_lock);
    <Interrupt>
      lock(padata_works_lock);

padata_do_parallel() takes padata_works_lock with softirqs enabled, so a deadlock is possible if, on the same CPU, the lock is acquired in process context and then softirq handling done in an interrupt leads to the same path.

Fix by leaving softirqs disabled while do_parallel holds padata_works_lock.

Reported-by [email protected]

Fixes 4611ce2246889 ("padata: allocate work structures for parallel jobs from a pool")

Signed-off-by Daniel Jordan <[email protected]>

Cc Herbert Xu <[email protected]>

Cc Steffen Klassert <[email protected]>

Signed-off-by Herbert Xu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 kernel/padata.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

kernel/padata.c +3 -2

index 4373f7adaa40a..3bc90fec0904c 100644
@@ -215,12 +215,13 @@ int padata_do_parallel(struct padata_shell *ps,
 	padata->pd = pd;
 	padata->cb_cpu = *cb_cpu;
 
-	rcu_read_unlock_bh();
-
 	spin_lock(&padata_works_lock);
 	padata->seq_nr = ++pd->seq_nr;
 	pw = padata_work_alloc();
 	spin_unlock(&padata_works_lock);
+
+	rcu_read_unlock_bh();
+
 	if (pw) {
 		padata_work_init(pw, padata_parallel_worker, padata, 0);
 		queue_work(pinst->parallel_wq, &pw->pw_work);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:43 UTC #49 lore raw

PATCH 38/177 drm/sun4i: Fix DE2 YVU handling

From: Jernej Skrabec <[email protected]>

[ Upstream commit 0ee9f600e69d901d31469359287b90bbe8e54553 ]

Function sun8i_vi_layer_get_csc_mode() is supposed to return CSC mode but due to inproper return type (bool instead of u32) it returns just 0 or 1. Colors are wrong for YVU formats because of that.

Fixes daab3d0e8e2b ("drm/sun4i: de2: csc_mode in de2 format struct is mostly redundant")

Reported-by Roman Stratiienko <[email protected]>

Signed-off-by Jernej Skrabec <[email protected]>

Tested-by Roman Stratiienko <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/sun4i/sun8i_vi_layer.c +1 -1

index 22c8c5375d0db..c0147af6a8406 100644
@@ -211,7 +211,7 @@ static int sun8i_vi_layer_update_coord(struct sun8i_mixer *mixer, int channel,
 	return 0;
 }
 
-static bool sun8i_vi_layer_get_csc_mode(const struct drm_format_info *format)
+static u32 sun8i_vi_layer_get_csc_mode(const struct drm_format_info *format)
 {
 	if (!format->is_yuv)
 		return SUN8I_CSC_MODE_OFF;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:44 UTC #50 lore raw

PATCH 39/177 drm/sun4i: backend: Support alpha property on lowest plane

From: Maxime Ripard <[email protected]>

[ Upstream commit e359c70462d2a82aae80274d027351d38792dde6 ]

Unlike what we previously thought, only the per-pixel alpha is broken on the lowest plane and the per-plane alpha isn't. Remove the check on the alpha property being set on the lowest plane to reject a mode.

Fixes dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha support")

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Reviewed-by Chen-Yu Tsai <[email protected]>

Cc Paul Kocialkowski <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/gpu/drm/sun4i/sun4i_backend.c +1 -2

index 072ea113e6be5..30672c4c634da 100644
@@ -589,8 +589,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
 
 	/* We can't have an alpha plane at the lowest position */
 	if (!backend->quirks->supports_lowest_plane_alpha &&
-	    (plane_states[0]->fb->format->has_alpha ||
-	    (plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE)))
+	    (plane_states[0]->alpha != DRM_BLEND_ALPHA_OPAQUE))
 		return -EINVAL;
 
 	for (i = 1; i < num_planes; i++) {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:43 UTC #51 lore raw

PATCH 40/177 drm/sun4i: backend: Disable alpha on the lowest plane on the A20

From: Maxime Ripard <[email protected]>

[ Upstream commit 5e2e2600a3744491a8b49b92597c13b693692082 ]

Unlike we previously thought, the per-pixel alpha is just as broken on the A20 as it is on the A10. Remove the quirk that says we can use it.

Fixes dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane alpha support")

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Reviewed-by Chen-Yu Tsai <[email protected]>

Cc Paul Kocialkowski <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 1 -
 1 file changed, 1 deletion(-)

drivers/gpu/drm/sun4i/sun4i_backend.c +0 -1

index 30672c4c634da..ed5d866178028 100644
@@ -994,7 +994,6 @@ static const struct sun4i_backend_quirks sun6i_backend_quirks = {
 
 static const struct sun4i_backend_quirks sun7i_backend_quirks = {
 	.needs_output_muxing = true,
-	.supports_lowest_plane_alpha = true,
 };
 
 static const struct sun4i_backend_quirks sun8i_a33_backend_quirks = {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:37 UTC #52 lore raw

PATCH 41/177 KVM: arm64: Update page shift if stage 2 block mapping not supported

From: Alexandru Elisei <[email protected]>

[ Upstream commit 7b75cd5128421c673153efb1236705696a1a9812 ]

Commit 196f878a7ac2e (" KVM: arm/arm64: Signal SIGBUS when stage2 discovers hwpoison memory") modifies user_mem_abort() to send a SIGBUS signal when the fault IPA maps to a hwpoisoned page. Commit 1559b7583ff6 ("KVM:
arm/arm64: Re-check VMA on detecting a poisoned page") changed kvm_send_hwpoison_signal() to use the page shift instead of the VMA because at that point the code had already released the mmap lock, which means userspace could have modified the VMA.

If userspace uses hugetlbfs for the VM memory, user_mem_abort() tries to map the guest fault IPA using block mappings in stage 2. That is not always possible, if, for example, userspace uses dirty page logging for the VM. Update the page shift appropriately in those cases when we downgrade the stage 2 entry from a block mapping to a page.

Fixes 1559b7583ff6 ("KVM: arm/arm64: Re-check VMA on detecting a poisoned page")

Signed-off-by Alexandru Elisei <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Reviewed-by Gavin Shan <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/kvm/mmu.c | 1 +
 1 file changed, 1 insertion(+)

arch/arm64/kvm/mmu.c +1 -0

index bd47f06739d6c..d1320f3f2b137 100644
@@ -1873,6 +1873,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 	    !fault_supports_stage2_huge_mapping(memslot, hva, vma_pagesize)) {
 		force_pte = true;
 		vma_pagesize = PAGE_SIZE;
+		vma_shift = PAGE_SHIFT;
 	}
 
 	/*

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:39 UTC #53 lore raw

PATCH 42/177 ARM: dts: imx6sx: fix the pad QSPI1B_SCLK mux mode for uart3

From: Fugang Duan <[email protected]>

[ Upstream commit 3ee99f6a2379eca87ab11122b7e9abd68f3441e2 ]

The pad QSPI1B_SCLK mux mode 0x1 is for function UART3_DTE_TX, correct the mux mode.

Fixes 743636f25f1d ("ARM: dts: imx: add pin function header for imx6sx")

Signed-off-by Fugang Duan <[email protected]>

Signed-off-by Shawn Guo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/imx6sx-pinfunc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/imx6sx-pinfunc.h +1 -1

index 0b02c7e60c174..f4dc46207954c 100644
@@ -1026,7 +1026,7 @@
 #define MX6SX_PAD_QSPI1B_DQS__SIM_M_HADDR_15                      0x01B0 0x04F8 0x0000 0x7 0x0
 #define MX6SX_PAD_QSPI1B_SCLK__QSPI1_B_SCLK                       0x01B4 0x04FC 0x0000 0x0 0x0
 #define MX6SX_PAD_QSPI1B_SCLK__UART3_DCE_RX                       0x01B4 0x04FC 0x0840 0x1 0x4
-#define MX6SX_PAD_QSPI1B_SCLK__UART3_DTE_TX                       0x01B4 0x04FC 0x0000 0x0 0x0
+#define MX6SX_PAD_QSPI1B_SCLK__UART3_DTE_TX                       0x01B4 0x04FC 0x0000 0x1 0x0
 #define MX6SX_PAD_QSPI1B_SCLK__ECSPI3_SCLK                        0x01B4 0x04FC 0x0730 0x2 0x1
 #define MX6SX_PAD_QSPI1B_SCLK__ESAI_RX_HF_CLK                     0x01B4 0x04FC 0x0780 0x3 0x2
 #define MX6SX_PAD_QSPI1B_SCLK__CSI1_DATA_16                       0x01B4 0x04FC 0x06DC 0x4 0x1

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:37 UTC #54 lore raw

PATCH 43/177 mmc: sdhci-acpi: Clear amd_sdhci_host on reset

Link https://lore.kernel.org/r/20200831150517.1.I93c78bfc6575771bb653c9d3fca5eb018a08417d@changeid open here

From: Raul E Rangel <[email protected]>

[ Upstream commit 2cf9bfe9be75ed3656bbf882fb70c3e3047866e4 ]

The commit 61d7437ed1390 ("mmc: sdhci-acpi: Fix HS400 tuning for AMDI0040") broke resume for eMMC HS400. When the system suspends the eMMC controller is powered down. So, on resume we need to reinitialize the controller. Although, amd_sdhci_host was not getting cleared, so the DLL was never re-enabled on resume. This results in HS400 being non-functional.

To fix the problem, this change clears the tuned_clock flag, clears the dll_enabled flag and disables the DLL on reset.

Fixes 61d7437ed1390 ("mmc: sdhci-acpi: Fix HS400 tuning for AMDI0040")

Signed-off-by Raul E Rangel <[email protected]>

Acked-by Adrian Hunter <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/mmc/host/sdhci-acpi.c | 31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

drivers/mmc/host/sdhci-acpi.c +24 -7

index 2d9f79b50a7fa..841e34aa7caae 100644
@@ -550,12 +550,18 @@ static int amd_select_drive_strength(struct mmc_card *card,
 	return MMC_SET_DRIVER_TYPE_A;
 }
 
-static void sdhci_acpi_amd_hs400_dll(struct sdhci_host *host)
+static void sdhci_acpi_amd_hs400_dll(struct sdhci_host *host, bool enable)
 {
+	struct sdhci_acpi_host *acpi_host = sdhci_priv(host);
+	struct amd_sdhci_host *amd_host = sdhci_acpi_priv(acpi_host);
+
 	/* AMD Platform requires dll setting */
 	sdhci_writel(host, 0x40003210, SDHCI_AMD_RESET_DLL_REGISTER);
 	usleep_range(10, 20);
-	sdhci_writel(host, 0x40033210, SDHCI_AMD_RESET_DLL_REGISTER);
+	if (enable)
+		sdhci_writel(host, 0x40033210, SDHCI_AMD_RESET_DLL_REGISTER);
+
+	amd_host->dll_enabled = enable;
 }
 
 /*

@@ -595,10 +601,8 @@ static void amd_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 
 		/* DLL is only required for HS400 */
 		if (host->timing == MMC_TIMING_MMC_HS400 &&
-		    !amd_host->dll_enabled) {
-			sdhci_acpi_amd_hs400_dll(host);
-			amd_host->dll_enabled = true;
-		}
+		    !amd_host->dll_enabled)
+			sdhci_acpi_amd_hs400_dll(host, true);
 	}
 }

@@ -619,10 +623,23 @@ static int amd_sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
 	return err;
 }
 
+static void amd_sdhci_reset(struct sdhci_host *host, u8 mask)
+{
+	struct sdhci_acpi_host *acpi_host = sdhci_priv(host);
+	struct amd_sdhci_host *amd_host = sdhci_acpi_priv(acpi_host);
+
+	if (mask & SDHCI_RESET_ALL) {
+		amd_host->tuned_clock = false;
+		sdhci_acpi_amd_hs400_dll(host, false);
+	}
+
+	sdhci_reset(host, mask);
+}
+
 static const struct sdhci_ops sdhci_acpi_ops_amd = {
 	.set_clock	= sdhci_set_clock,
 	.set_bus_width	= sdhci_set_bus_width,
-	.reset		= sdhci_reset,
+	.reset		= amd_sdhci_reset,
 	.set_uhs_signaling = sdhci_set_uhs_signaling,
 };

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:37 UTC #55 lore raw

PATCH 44/177 mmc: sdhci-msm: Add retries when all tuning phases are found valid

Link https://lore.kernel.org/r/20200827075809.1.If179abf5ecb67c963494db79c3bc4247d987419b@changeid open here

From: Douglas Anderson <[email protected]>

[ Upstream commit 9d5dcefb7b114d610aeb2371f6a6f119af316e43 ]

As the comments in this patch say, if we tune and find all phases are valid it's _almost_ as bad as no phases being found valid. Probably all phases are not really reliable but we didn't detect where the unreliable place is. That means we'll essentially be guessing and hoping we get a good phase.

This is not just a problem in theory. It was causing real problems on a real board. On that board, most often phase 10 is found as the only invalid phase, though sometimes 10 and 11 are invalid and sometimes just 11. Some percentage of the time, however, all phases are found to be valid. When this happens, the current logic will decide to use phase 11. Since phase 11 is sometimes found to be invalid, this is a bad choice. Sure enough, when phase 11 is picked we often get mmc errors later in boot.

I have seen cases where all phases were found to be valid 3 times in a row, so increase the retry count to 10 just to be extra sure.

Fixes 415b5a75da43 ("mmc: sdhci-msm: Add platform_execute_tuning implementation")

Signed-off-by Douglas Anderson <[email protected]>

Reviewed-by Veerabhadrarao Badiganti <[email protected]>

Acked-by Adrian Hunter <[email protected]>

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/mmc/host/sdhci-msm.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

drivers/mmc/host/sdhci-msm.c +17 -1

index c0d58e9fcc333..0450f521c6f9a 100644
@@ -1158,7 +1158,7 @@ static void sdhci_msm_set_cdr(struct sdhci_host *host, bool enable)
 static int sdhci_msm_execute_tuning(struct mmc_host *mmc, u32 opcode)
 {
 	struct sdhci_host *host = mmc_priv(mmc);
-	int tuning_seq_cnt = 3;
+	int tuning_seq_cnt = 10;
 	u8 phase, tuned_phases[16], tuned_phase_cnt = 0;
 	int rc;
 	struct mmc_ios ios = host->mmc->ios;

@@ -1214,6 +1214,22 @@ retry:
 	} while (++phase < ARRAY_SIZE(tuned_phases));
 
 	if (tuned_phase_cnt) {
+		if (tuned_phase_cnt == ARRAY_SIZE(tuned_phases)) {
+			/*
+			 * All phases valid is _almost_ as bad as no phases
+			 * valid.  Probably all phases are not really reliable
+			 * but we didn't detect where the unreliable place is.
+			 * That means we'll essentially be guessing and hoping
+			 * we get a good phase.  Better to try a few times.
+			 */
+			dev_dbg(mmc_dev(mmc), "%s: All phases valid; try again\n",
+				mmc_hostname(mmc));
+			if (--tuning_seq_cnt) {
+				tuned_phase_cnt = 0;
+				goto retry;
+			}
+		}
+
 		rc = msm_find_most_appropriate_phase(host, tuned_phases,
 						     tuned_phase_cnt);
 		if (rc < 0)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #56 lore raw

PATCH 45/177 spi: stm32: Rate-limit the Communication suspended message

From: Marek Vasut <[email protected]>

[ Upstream commit ea8be08cc9358f811e4175ba7fa7fea23c5d393e ]

The 'spi_stm32 44004000.spi: Communication suspended' message means that when using PIO, the kernel did not read the FIFO fast enough and so the SPI controller paused the transfer. Currently, this is printed on every single such event, so if the kernel is busy and the controller is pausing the transfers often, the kernel will be all the more busy scrolling this message into the log buffer every few milliseconds. That is not helpful.

Instead, rate-limit the message and print it every once in a while. It is not possible to use the default dev_warn_ratelimited(), because that is still too verbose, as it prints 10 lines (DEFAULT_RATELIMIT_BURST) every 5 seconds (DEFAULT_RATELIMIT_INTERVAL). The policy here is to print 1 line every 50 seconds (DEFAULT_RATELIMIT_INTERVAL * 10), because 1 line is more than enough and the cycles saved on printing are better left to the CPU to handle the SPI. However, dev_warn_once() is also not useful, as the user should be aware that this condition is possibly recurring or ongoing. Thus the custom rate-limit policy.

Finally, turn the message from dev_warn() to dev_dbg(), since the system does not suffer any sort of malfunction if this message appears, it is just slowing down. This further reduces the printing into the log buffer and frees the CPU to do useful work.

Fixes dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller")

Signed-off-by Marek Vasut <[email protected]>

Cc Alexandre Torgue <[email protected]>

Cc Amelie Delaunay <[email protected]>

Cc Antonio Borneo <[email protected]>

Cc Mark Brown <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/spi/spi-stm32.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

drivers/spi/spi-stm32.c +5 -1

index d4b33b358a31e..a00f6b51ccbfc 100644
@@ -936,7 +936,11 @@ static irqreturn_t stm32h7_spi_irq_thread(int irq, void *dev_id)
 	}
 
 	if (sr & STM32H7_SPI_SR_SUSP) {
-		dev_warn(spi->dev, "Communication suspended\n");
+		static DEFINE_RATELIMIT_STATE(rs,
+					      DEFAULT_RATELIMIT_INTERVAL * 10,
+					      1);
+		if (__ratelimit(&rs))
+			dev_dbg_ratelimited(spi->dev, "Communication suspended\n");
 		if (!spi->cur_usedma && (spi->rx_buf && (spi->rx_len > 0)))
 			stm32h7_spi_read_rxfifo(spi, false);
 		/*

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #57 lore raw

PATCH 46/177 btrfs: fix NULL pointer dereference after failure to create snapshot

From: Filipe Manana <[email protected]>

[ Upstream commit 2d892ccdc163a3d2e08c5ed1cea8b61bf7e4f531 ]

When trying to get a new fs root for a snapshot during the transaction at transaction.c:create_pending_snapshot(), if btrfs_get_new_fs_root() fails we leave "pending->snap" pointing to an error pointer, and then later at ioctl.c:create_snapshot() we dereference that pointer, resulting in a crash:

  [12264.614689] BUG: kernel NULL pointer dereference, address: 00000000000007c4
  [12264.615650] #PF: supervisor write access in kernel mode
  [12264.616487] #PF: error_code(0x0002) - not-present page
  [12264.617436] PGD 0 P4D 0
  [12264.618328] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI
  [12264.619150] CPU: 0 PID: 2310635 Comm: fsstress Tainted: G        W         5.9.0-rc3-btrfs-next-67 #1
  [12264.619960] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
  [12264.621769] RIP: 0010:btrfs_mksubvol+0x438/0x4a0 [btrfs]
  [12264.622528] Code: bc ef ff ff (...)
  [12264.624092] RSP: 0018:ffffaa6fc7277cd8 EFLAGS: 00010282
  [12264.624669] RAX: 00000000fffffff4 RBX: ffff9d3e8f151a60 RCX: 0000000000000000
  [12264.625249] RDX: 0000000000000001 RSI: ffffffff9d56c9be RDI: fffffffffffffff4
  [12264.625830] RBP: ffff9d3e8f151b48 R08: 0000000000000000 R09: 0000000000000000
  [12264.626413] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffff4
  [12264.626994] R13: ffff9d3ede380538 R14: ffff9d3ede380500 R15: ffff9d3f61b2eeb8
  [12264.627582] FS:  00007f140d5d8200(0000) GS:ffff9d3fb5e00000(0000) knlGS:0000000000000000
  [12264.628176] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [12264.628773] CR2: 00000000000007c4 CR3: 000000020f8e8004 CR4: 00000000003706f0
  [12264.629379] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  [12264.629994] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  [12264.630594] Call Trace:
  [12264.631227]  btrfs_mksnapshot+0x7b/0xb0 [btrfs]
  [12264.631840]  __btrfs_ioctl_snap_create+0x16f/0x1a0 [btrfs]
  [12264.632458]  btrfs_ioctl_snap_create_v2+0xb0/0xf0 [btrfs]
  [12264.633078]  btrfs_ioctl+0x1864/0x3130 [btrfs]
  [12264.633689]  ? do_sys_openat2+0x1a7/0x2d0
  [12264.634295]  ? kmem_cache_free+0x147/0x3a0
  [12264.634899]  ? __x64_sys_ioctl+0x83/0xb0
  [12264.635488]  __x64_sys_ioctl+0x83/0xb0
  [12264.636058]  do_syscall_64+0x33/0x80
  [12264.636616]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

  (gdb) list *(btrfs_mksubvol+0x438)
  0x7c7b8 is in btrfs_mksubvol (fs/btrfs/ioctl.c:858).
  853		ret = 0;
  854		pending_snapshot->anon_dev = 0;
  855	fail:
  856		/* Prevent double freeing of anon_dev */
  857		if (ret && pending_snapshot->snap)
  858			pending_snapshot->snap->anon_dev = 0;
  859		btrfs_put_root(pending_snapshot->snap);
  860		btrfs_subvolume_release_metadata(root, &pending_snapshot->block_rsv);
  861	free_pending:
  862		if (pending_snapshot->anon_dev)

So fix this by setting "pending->snap" to NULL if we get an error from the call to btrfs_get_new_fs_root() at transaction.c:create_pending_snapshot().

Fixes 2dfb1e43f57dd3 ("btrfs: preallocate anon block device at first phase of snapshot creation")

Signed-off-by Filipe Manana <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/btrfs/transaction.c | 1 +
 1 file changed, 1 insertion(+)

fs/btrfs/transaction.c +1 -0

index 2710f8ddb95fb..b43ebf55b93e1 100644
@@ -1636,6 +1636,7 @@ static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans,
 	pending->snap = btrfs_get_new_fs_root(fs_info, objectid, pending->anon_dev);
 	if (IS_ERR(pending->snap)) {
 		ret = PTR_ERR(pending->snap);
+		pending->snap = NULL;
 		btrfs_abort_transaction(trans, ret);
 		goto fail;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:37 UTC #58 lore raw

PATCH 47/177 i2c: npcm7xx: Fix timeout calculation

From: Tali Perry <[email protected]>

[ Upstream commit 06be67266a0c9a6a1ffb330a4ab50c2f21612e2b ]

timeout_usec value calculation was wrong, the calculated value was in msec instead of usec.

Fixes 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver")

Signed-off-by Tali Perry <[email protected]>

Reviewed-by Avi Fishman <[email protected]>

Reviewed-by Joel Stanley <[email protected]>

Reviewed-by Alex Qiu <[email protected]>

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/i2c/busses/i2c-npcm7xx.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

drivers/i2c/busses/i2c-npcm7xx.c +6 -2

index 75f07138a6fa2..dfcf04e1967f1 100644
@@ -2093,8 +2093,12 @@ static int npcm_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
 		}
 	}
 
-	/* Adaptive TimeOut: astimated time in usec + 100% margin */
-	timeout_usec = (2 * 10000 / bus->bus_freq) * (2 + nread + nwrite);
+	/*
+	 * Adaptive TimeOut: estimated time in usec + 100% margin:
+	 * 2: double the timeout for clock stretching case
+	 * 9: bits per transaction (including the ack/nack)
+	 */
+	timeout_usec = (2 * 9 * USEC_PER_SEC / bus->bus_freq) * (2 + nread + nwrite);
 	timeout = max(msecs_to_jiffies(35), usecs_to_jiffies(timeout_usec));
 	if (nwrite >= 32 * 1024 || nread >= 32 * 1024) {
 		dev_err(bus->dev, "i2c%d buffer too big\n", bus->num);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #59 lore raw

PATCH 48/177 block: restore a specific error code in bdev_del_partition

From: Christoph Hellwig <[email protected]>

[ Upstream commit 88ce2a530cc9865a894454b2e40eba5957a60e1a ]

mdadm relies on the fact that deleting an invalid partition returns -ENXIO or -ENOTTY to detect if a block device is a partition or a whole device.

Fixes 08fc1ab6d748 ("block: fix locking in bdev_del_partition")

Reported-by kernel test robot <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 block/partitions/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

block/partitions/core.c +1 -1

index 534e11285a8d4..b45539764c994 100644
@@ -529,7 +529,7 @@ int bdev_del_partition(struct block_device *bdev, int partno)
 
 	bdevp = bdget_disk(bdev->bd_disk, partno);
 	if (!bdevp)
-		return -ENOMEM;
+		return -ENXIO;
 
 	mutex_lock(&bdevp->bd_mutex);
 	mutex_lock_nested(&bdev->bd_mutex, 1);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:37 UTC #60 lore raw

PATCH 49/177 seccomp: dont leak memory when filter install races

From: Tycho Andersen <[email protected]>

[ Upstream commit a566a9012acd7c9a4be7e30dc7acb7a811ec2260 ]

In seccomp_set_mode_filter() with TSYNC | NEW_LISTENER, we first initialize the listener fd, then check to see if we can actually use it later in seccomp_may_assign_mode(), which can fail if anyone else in our thread group has installed a filter and caused some divergence. If we can't, we partially clean up the newly allocated file: we put the fd, put the file, but don't actually clean up the *memory* that was allocated at filter->notif. Let's clean that up too.

To accomplish this, let's hoist the actual "detach a notifier from a filter" code to its own helper out of seccomp_notify_release(), so that in case anyone adds stuff to init_listener(), they only have to add the cleanup code in one spot. This does a bit of extra locking and such on the failure path when the filter is not attached, but it's a slow failure path anyway.

Fixes 51891498f2da ("seccomp: allow TSYNC and USER_NOTIF together")

Reported-by [email protected]

Signed-off-by Tycho Andersen <[email protected]>

Acked-by Christian Brauner <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Kees Cook <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 kernel/seccomp.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

kernel/seccomp.c +10 -3

index c461ba9925136..54cf84bac3c9b 100644
@@ -997,13 +997,12 @@ out:
 }
 
 #ifdef CONFIG_SECCOMP_FILTER
-static int seccomp_notify_release(struct inode *inode, struct file *file)
+static void seccomp_notify_detach(struct seccomp_filter *filter)
 {
-	struct seccomp_filter *filter = file->private_data;
 	struct seccomp_knotif *knotif;
 
 	if (!filter)
-		return 0;
+		return;
 
 	mutex_lock(&filter->notify_lock);

@@ -1025,6 +1024,13 @@ static int seccomp_notify_release(struct inode *inode, struct file *file)
 	kfree(filter->notif);
 	filter->notif = NULL;
 	mutex_unlock(&filter->notify_lock);
+}
+
+static int seccomp_notify_release(struct inode *inode, struct file *file)
+{
+	struct seccomp_filter *filter = file->private_data;
+
+	seccomp_notify_detach(filter);
 	__put_seccomp_filter(filter);
 	return 0;
 }

@@ -1358,6 +1364,7 @@ out_put_fd:
 			listener_f->private_data = NULL;
 			fput(listener_f);
 			put_unused_fd(listener);
+			seccomp_notify_detach(prepared);
 		} else {
 			fd_install(listener, listener_f);
 			ret = listener;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #61 lore raw

PATCH 50/177 nvme-fabrics: allow to queue requests for live queues

From: Sagi Grimberg <[email protected]>

[ Upstream commit 73a5379937ec89b91e907bb315e2434ee9696a2c ]

Right now we are failing requests based on the controller state (which is checked inline in nvmf_check_ready) however we should definitely accept requests if the queue is live.

When entering controller reset, we transition the controller into NVME_CTRL_RESETTING, and then return BLK_STS_RESOURCE for non-mpath requests (have blk_noretry_request set).

This is also the case for NVME_REQ_USER for the wrong reason. There shouldn't be any reason for us to reject this I/O in a controller reset. We do want to prevent passthru commands on the admin queue because we need the controller to fully initialize first before we let user passthru admin commands to be issued.

In a non-mpath setup, this means that the requests will simply be requeued over and over forever not allowing the q_usage_counter to drop its final reference, causing controller reset to hang if running concurrently with heavy I/O.

Fixes 35897b920c8a ("nvme-fabrics: fix and refine state checks in __nvmf_check_ready")

Reviewed-by James Smart <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/fabrics.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

drivers/nvme/host/fabrics.c +8 -4

index 4ec4829d62334..7799d032bf38b 100644
@@ -565,10 +565,14 @@ bool __nvmf_check_ready(struct nvme_ctrl *ctrl, struct request *rq,
 	struct nvme_request *req = nvme_req(rq);
 
 	/*
-	 * If we are in some state of setup or teardown only allow
-	 * internally generated commands.
+	 * currently we have a problem sending passthru commands
+	 * on the admin_q if the controller is not LIVE because we can't
+	 * make sure that they are going out after the admin connect,
+	 * controller enable and/or other commands in the initialization
+	 * sequence. until the controller will be LIVE, fail with
+	 * BLK_STS_RESOURCE so that they will be rescheduled.
 	 */
-	if (!blk_rq_is_passthrough(rq) || (req->flags & NVME_REQ_USERCMD))
+	if (rq->q == ctrl->admin_q && (req->flags & NVME_REQ_USERCMD))
 		return false;
 
 	/*

@@ -578,7 +582,7 @@ bool __nvmf_check_ready(struct nvme_ctrl *ctrl, struct request *rq,
 	switch (ctrl->state) {
 	case NVME_CTRL_NEW:
 	case NVME_CTRL_CONNECTING:
-		if (nvme_is_fabrics(req->cmd) &&
+		if (blk_rq_is_passthrough(rq) && nvme_is_fabrics(req->cmd) &&
 		    req->cmd->fabrics.fctype == nvme_fabrics_type_connect)
 			return true;
 		break;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:38 UTC #62 lore raw

PATCH 51/177 spi: stm32: fix pm_runtime_get_sync() error checking

Link https://lore.kernel.org/r/20200909094304.GA420136@mwanda open here

From: Dan Carpenter <[email protected]>

[ Upstream commit c170a5a3b6944ad8e76547c4a1d9fe81c8f23ac8 ]

The pm_runtime_get_sync() can return either 0 or 1 on success but this code treats 1 as a failure.

Fixes db96bf976a4f ("spi: stm32: fixes suspend/resume management")

Signed-off-by Dan Carpenter <[email protected]>

Reviewed-by Alain Volmat <[email protected]>

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/spi/spi-stm32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/spi/spi-stm32.c +1 -1

index a00f6b51ccbfc..3056428b09f31 100644
@@ -2064,7 +2064,7 @@ static int stm32_spi_resume(struct device *dev)
 	}
 
 	ret = pm_runtime_get_sync(dev);
-	if (ret) {
+	if (ret < 0) {
 		dev_err(dev, "Unable to power device:%d\n", ret);
 		return ret;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:37 UTC #63 lore raw

PATCH 52/177 block: Set same_page to false in __bio_try_merge_page if ret is false

From: Ritesh Harjani <[email protected]>

[ Upstream commit 2cd896a5e86fc326bda8614b96c0401dcc145868 ]

If we hit the UINT_MAX limit of bio->bi_iter.bi_size and so we are anyway not merging this page in this bio, then it make sense to make same_page also as false before returning.

Without this patch, we hit below WARNING in iomap.
This mostly happens with very large memory system and / or after tweaking vm dirty threshold params to delay writeback of dirty data.

WARNING: CPU: 18 PID: 5130 at fs/iomap/buffered-io.c:74 iomap_page_release+0x120/0x150
 CPU: 18 PID: 5130 Comm: fio Kdump: loaded Tainted: G        W         5.8.0-rc3 #6
 Call Trace:
  __remove_mapping+0x154/0x320 (unreliable)
  iomap_releasepage+0x80/0x180
  try_to_release_page+0x94/0xe0
  invalidate_inode_page+0xc8/0x110
  invalidate_mapping_pages+0x1dc/0x540
  generic_fadvise+0x3c8/0x450
  xfs_file_fadvise+0x2c/0xe0 [xfs]
  vfs_fadvise+0x3c/0x60
  ksys_fadvise64_64+0x68/0xe0
  sys_fadvise64+0x28/0x40
  system_call_exception+0xf8/0x1c0
  system_call_common+0xf0/0x278

Fixes cc90bc68422 ("block: fix "check bi_size overflow before merge"")

Reported-by Shivaprasad G Bhat <[email protected]>

Signed-off-by Anju T Sudhakar <[email protected]>

Signed-off-by Ritesh Harjani <[email protected]>

Reviewed-by Ming Lei <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 block/bio.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

block/bio.c +3 -1

index b1883adc8f154..eac129f21d2df 100644
@@ -877,8 +877,10 @@ bool __bio_try_merge_page(struct bio *bio, struct page *page,
 		struct bio_vec *bv = &bio->bi_io_vec[bio->bi_vcnt - 1];
 
 		if (page_is_mergeable(bv, page, len, off, same_page)) {
-			if (bio->bi_iter.bi_size > UINT_MAX - len)
+			if (bio->bi_iter.bi_size > UINT_MAX - len) {
+				*same_page = false;
 				return false;
+			}
 			bv->bv_len += len;
 			bio->bi_iter.bi_size += len;
 			return true;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:23 UTC #64 lore raw

PATCH 53/177 RDMA/rtrs-srv: Set .release function for rtrs srv device during device init

From: Md Haris Iqbal <[email protected]>

[ Upstream commit 39c2d639ca183a400ba3259fa0825714cbb09c53 ]

The device .release function was not being set during the device initialization. This was leading to the below warning, in error cases when put_srv was called before device_add was called.

Warning:

Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/kobject.txt.

So, set the device .release function during device initialization in the __alloc_srv() function.

Fixes baa5b28b7a47 ("RDMA/rtrs-srv: Replace device_register with device_initialize and device_add")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Md Haris Iqbal <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

Acked-by Jack Wang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c | 8 --------
 drivers/infiniband/ulp/rtrs/rtrs-srv.c       | 8 ++++++++
 2 files changed, 8 insertions(+), 8 deletions(-)

drivers/infiniband/ulp/rtrs/rtrs-srv-sysfs.c +0 -8

index 2f981ae970767..cf6a2be61695d 100644
@@ -152,13 +152,6 @@ static struct attribute_group rtrs_srv_stats_attr_group = {
 	.attrs = rtrs_srv_stats_attrs,
 };
 
-static void rtrs_srv_dev_release(struct device *dev)
-{
-	struct rtrs_srv *srv = container_of(dev, struct rtrs_srv, dev);
-
-	kfree(srv);
-}
-
 static int rtrs_srv_create_once_sysfs_root_folders(struct rtrs_srv_sess *sess)
 {
 	struct rtrs_srv *srv = sess->srv;

@@ -172,7 +165,6 @@ static int rtrs_srv_create_once_sysfs_root_folders(struct rtrs_srv_sess *sess)
 		goto unlock;
 	}
 	srv->dev.class = rtrs_dev_class;
-	srv->dev.release = rtrs_srv_dev_release;
 	err = dev_set_name(&srv->dev, "%s", sess->s.sessname);
 	if (err)
 		goto unlock;

drivers/infiniband/ulp/rtrs/rtrs-srv.c +8 -0

index b61a18e57aeba..28f6414dfa3dc 100644
@@ -1319,6 +1319,13 @@ static int rtrs_srv_get_next_cq_vector(struct rtrs_srv_sess *sess)
 	return sess->cur_cq_vector;
 }
 
+static void rtrs_srv_dev_release(struct device *dev)
+{
+	struct rtrs_srv *srv = container_of(dev, struct rtrs_srv, dev);
+
+	kfree(srv);
+}
+
 static struct rtrs_srv *__alloc_srv(struct rtrs_srv_ctx *ctx,
 				     const uuid_t *paths_uuid)
 {

@@ -1337,6 +1344,7 @@ static struct rtrs_srv *__alloc_srv(struct rtrs_srv_ctx *ctx,
 	srv->queue_depth = sess_queue_depth;
 	srv->ctx = ctx;
 	device_initialize(&srv->dev);
+	srv->dev.release = rtrs_srv_dev_release;
 
 	srv->chunks = kcalloc(srv->queue_depth, sizeof(*srv->chunks),
 			      GFP_KERNEL);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:33 UTC #65 lore raw

PATCH 54/177 IB/isert: Fix unaligned immediate-data handling

From: Sagi Grimberg <[email protected]>

[ Upstream commit 0b089c1ef7047652b13b4cdfdb1e0e7dbdb8c9ab ]

Currently we allocate rx buffers in a single contiguous buffers for headers (iser and iscsi) and data trailer. This means that most likely the data starting offset is aligned to 76 bytes (size of both headers).

This worked fine for years, but at some point this broke, resulting in data corruptions in isert when a command comes with immediate data and the underlying backend device assumes 512 bytes buffer alignment.

We assume a hard-requirement for all direct I/O buffers to be 512 bytes aligned. To fix this, we should avoid passing unaligned buffers for I/O.

Instead, we allocate our recv buffers with some extra space such that we can have the data portion align to 512 byte boundary. This also means that we cannot reference headers or data using structure but rather accessors (as they may move based on alignment). Also, get rid of the wrong __packed annotation from iser_rx_desc as this has only harmful effects (not aligned to anything).

This affects the rx descriptors for iscsi login and data plane.

Fixes 3d75ca0adef4 ("block: introduce multi-page bvec helpers")

Link https://lore.kernel.org/r/[email protected] open here

Reported-by Stephen Rust <[email protected]>

Tested-by Doug Dumitru <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/infiniband/ulp/isert/ib_isert.c | 93 +++++++++++++------------
 drivers/infiniband/ulp/isert/ib_isert.h | 41 ++++++++---
 2 files changed, 78 insertions(+), 56 deletions(-)

drivers/infiniband/ulp/isert/ib_isert.c +47 ~~-46~~

index b7df38ee8ae05..49ca8727e3fa3 100644
@@ -183,15 +183,15 @@ isert_alloc_rx_descriptors(struct isert_conn *isert_conn)
 	rx_desc = isert_conn->rx_descs;
 
 	for (i = 0; i < ISERT_QP_MAX_RECV_DTOS; i++, rx_desc++)  {
-		dma_addr = ib_dma_map_single(ib_dev, (void *)rx_desc,
-					ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
+		dma_addr = ib_dma_map_single(ib_dev, rx_desc->buf,
+					ISER_RX_SIZE, DMA_FROM_DEVICE);
 		if (ib_dma_mapping_error(ib_dev, dma_addr))
 			goto dma_map_fail;
 
 		rx_desc->dma_addr = dma_addr;
 
 		rx_sg = &rx_desc->rx_sg;
-		rx_sg->addr = rx_desc->dma_addr;
+		rx_sg->addr = rx_desc->dma_addr + isert_get_hdr_offset(rx_desc);
 		rx_sg->length = ISER_RX_PAYLOAD_SIZE;
 		rx_sg->lkey = device->pd->local_dma_lkey;
 		rx_desc->rx_cqe.done = isert_recv_done;

@@ -203,7 +203,7 @@ dma_map_fail:
 	rx_desc = isert_conn->rx_descs;
 	for (j = 0; j < i; j++, rx_desc++) {
 		ib_dma_unmap_single(ib_dev, rx_desc->dma_addr,
-				    ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
+				    ISER_RX_SIZE, DMA_FROM_DEVICE);
 	}
 	kfree(isert_conn->rx_descs);
 	isert_conn->rx_descs = NULL;

@@ -224,7 +224,7 @@ isert_free_rx_descriptors(struct isert_conn *isert_conn)
 	rx_desc = isert_conn->rx_descs;
 	for (i = 0; i < ISERT_QP_MAX_RECV_DTOS; i++, rx_desc++)  {
 		ib_dma_unmap_single(ib_dev, rx_desc->dma_addr,
-				    ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
+				    ISER_RX_SIZE, DMA_FROM_DEVICE);
 	}
 
 	kfree(isert_conn->rx_descs);

@@ -409,10 +409,9 @@ isert_free_login_buf(struct isert_conn *isert_conn)
 			    ISER_RX_PAYLOAD_SIZE, DMA_TO_DEVICE);
 	kfree(isert_conn->login_rsp_buf);
 
-	ib_dma_unmap_single(ib_dev, isert_conn->login_req_dma,
-			    ISER_RX_PAYLOAD_SIZE,
-			    DMA_FROM_DEVICE);
-	kfree(isert_conn->login_req_buf);
+	ib_dma_unmap_single(ib_dev, isert_conn->login_desc->dma_addr,
+			    ISER_RX_SIZE, DMA_FROM_DEVICE);
+	kfree(isert_conn->login_desc);
 }
 
 static int

@@ -421,25 +420,25 @@ isert_alloc_login_buf(struct isert_conn *isert_conn,
 {
 	int ret;
 
-	isert_conn->login_req_buf = kzalloc(sizeof(*isert_conn->login_req_buf),
+	isert_conn->login_desc = kzalloc(sizeof(*isert_conn->login_desc),
 			GFP_KERNEL);
-	if (!isert_conn->login_req_buf)
+	if (!isert_conn->login_desc)
 		return -ENOMEM;
 
-	isert_conn->login_req_dma = ib_dma_map_single(ib_dev,
-				isert_conn->login_req_buf,
-				ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
-	ret = ib_dma_mapping_error(ib_dev, isert_conn->login_req_dma);
+	isert_conn->login_desc->dma_addr = ib_dma_map_single(ib_dev,
+				isert_conn->login_desc->buf,
+				ISER_RX_SIZE, DMA_FROM_DEVICE);
+	ret = ib_dma_mapping_error(ib_dev, isert_conn->login_desc->dma_addr);
 	if (ret) {
-		isert_err("login_req_dma mapping error: %d\n", ret);
-		isert_conn->login_req_dma = 0;
-		goto out_free_login_req_buf;
+		isert_err("login_desc dma mapping error: %d\n", ret);
+		isert_conn->login_desc->dma_addr = 0;
+		goto out_free_login_desc;
 	}
 
 	isert_conn->login_rsp_buf = kzalloc(ISER_RX_PAYLOAD_SIZE, GFP_KERNEL);
 	if (!isert_conn->login_rsp_buf) {
 		ret = -ENOMEM;
-		goto out_unmap_login_req_buf;
+		goto out_unmap_login_desc;
 	}
 
 	isert_conn->login_rsp_dma = ib_dma_map_single(ib_dev,

@@ -456,11 +455,11 @@ isert_alloc_login_buf(struct isert_conn *isert_conn,
 
 out_free_login_rsp_buf:
 	kfree(isert_conn->login_rsp_buf);
-out_unmap_login_req_buf:
-	ib_dma_unmap_single(ib_dev, isert_conn->login_req_dma,
-			    ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
-out_free_login_req_buf:
-	kfree(isert_conn->login_req_buf);
+out_unmap_login_desc:
+	ib_dma_unmap_single(ib_dev, isert_conn->login_desc->dma_addr,
+			    ISER_RX_SIZE, DMA_FROM_DEVICE);
+out_free_login_desc:
+	kfree(isert_conn->login_desc);
 	return ret;
 }

@@ -579,7 +578,7 @@ isert_connect_release(struct isert_conn *isert_conn)
 		ib_destroy_qp(isert_conn->qp);
 	}
 
-	if (isert_conn->login_req_buf)
+	if (isert_conn->login_desc)
 		isert_free_login_buf(isert_conn);
 
 	isert_device_put(device);

@@ -965,17 +964,18 @@ isert_login_post_recv(struct isert_conn *isert_conn)
 	int ret;
 
 	memset(&sge, 0, sizeof(struct ib_sge));
-	sge.addr = isert_conn->login_req_dma;
+	sge.addr = isert_conn->login_desc->dma_addr +
+		isert_get_hdr_offset(isert_conn->login_desc);
 	sge.length = ISER_RX_PAYLOAD_SIZE;
 	sge.lkey = isert_conn->device->pd->local_dma_lkey;
 
 	isert_dbg("Setup sge: addr: %llx length: %d 0x%08x\n",
 		sge.addr, sge.length, sge.lkey);
 
-	isert_conn->login_req_buf->rx_cqe.done = isert_login_recv_done;
+	isert_conn->login_desc->rx_cqe.done = isert_login_recv_done;
 
 	memset(&rx_wr, 0, sizeof(struct ib_recv_wr));
-	rx_wr.wr_cqe = &isert_conn->login_req_buf->rx_cqe;
+	rx_wr.wr_cqe = &isert_conn->login_desc->rx_cqe;
 	rx_wr.sg_list = &sge;
 	rx_wr.num_sge = 1;

@@ -1052,7 +1052,7 @@ post_send:
 static void
 isert_rx_login_req(struct isert_conn *isert_conn)
 {
-	struct iser_rx_desc *rx_desc = isert_conn->login_req_buf;
+	struct iser_rx_desc *rx_desc = isert_conn->login_desc;
 	int rx_buflen = isert_conn->login_req_len;
 	struct iscsi_conn *conn = isert_conn->conn;
 	struct iscsi_login *login = conn->conn_login;

@@ -1064,7 +1064,7 @@ isert_rx_login_req(struct isert_conn *isert_conn)
 
 	if (login->first_request) {
 		struct iscsi_login_req *login_req =
-			(struct iscsi_login_req *)&rx_desc->iscsi_header;
+			(struct iscsi_login_req *)isert_get_iscsi_hdr(rx_desc);
 		/*
 		 * Setup the initial iscsi_login values from the leading
 		 * login request PDU.

@@ -1083,13 +1083,13 @@ isert_rx_login_req(struct isert_conn *isert_conn)
 		login->tsih		= be16_to_cpu(login_req->tsih);
 	}
 
-	memcpy(&login->req[0], (void *)&rx_desc->iscsi_header, ISCSI_HDR_LEN);
+	memcpy(&login->req[0], isert_get_iscsi_hdr(rx_desc), ISCSI_HDR_LEN);
 
 	size = min(rx_buflen, MAX_KEY_VALUE_PAIRS);
 	isert_dbg("Using login payload size: %d, rx_buflen: %d "
 		  "MAX_KEY_VALUE_PAIRS: %d\n", size, rx_buflen,
 		  MAX_KEY_VALUE_PAIRS);
-	memcpy(login->req_buf, &rx_desc->data[0], size);
+	memcpy(login->req_buf, isert_get_data(rx_desc), size);
 
 	if (login->first_request) {
 		complete(&isert_conn->login_comp);

@@ -1154,14 +1154,15 @@ isert_handle_scsi_cmd(struct isert_conn *isert_conn,
 	if (imm_data_len != data_len) {
 		sg_nents = max(1UL, DIV_ROUND_UP(imm_data_len, PAGE_SIZE));
 		sg_copy_from_buffer(cmd->se_cmd.t_data_sg, sg_nents,
-				    &rx_desc->data[0], imm_data_len);
+				    isert_get_data(rx_desc), imm_data_len);
 		isert_dbg("Copy Immediate sg_nents: %u imm_data_len: %d\n",
 			  sg_nents, imm_data_len);
 	} else {
 		sg_init_table(&isert_cmd->sg, 1);
 		cmd->se_cmd.t_data_sg = &isert_cmd->sg;
 		cmd->se_cmd.t_data_nents = 1;
-		sg_set_buf(&isert_cmd->sg, &rx_desc->data[0], imm_data_len);
+		sg_set_buf(&isert_cmd->sg, isert_get_data(rx_desc),
+				imm_data_len);
 		isert_dbg("Transfer Immediate imm_data_len: %d\n",
 			  imm_data_len);
 	}

@@ -1230,9 +1231,9 @@ isert_handle_iscsi_dataout(struct isert_conn *isert_conn,
 	}
 	isert_dbg("Copying DataOut: sg_start: %p, sg_off: %u "
 		  "sg_nents: %u from %p %u\n", sg_start, sg_off,
-		  sg_nents, &rx_desc->data[0], unsol_data_len);
+		  sg_nents, isert_get_data(rx_desc), unsol_data_len);
 
-	sg_copy_from_buffer(sg_start, sg_nents, &rx_desc->data[0],
+	sg_copy_from_buffer(sg_start, sg_nents, isert_get_data(rx_desc),
 			    unsol_data_len);
 
 	rc = iscsit_check_dataout_payload(cmd, hdr, false);

@@ -1291,7 +1292,7 @@ isert_handle_text_cmd(struct isert_conn *isert_conn, struct isert_cmd *isert_cmd
 	}
 	cmd->text_in_ptr = text_in;
 
-	memcpy(cmd->text_in_ptr, &rx_desc->data[0], payload_length);
+	memcpy(cmd->text_in_ptr, isert_get_data(rx_desc), payload_length);
 
 	return iscsit_process_text_cmd(conn, cmd, hdr);
 }

@@ -1301,7 +1302,7 @@ isert_rx_opcode(struct isert_conn *isert_conn, struct iser_rx_desc *rx_desc,
 		uint32_t read_stag, uint64_t read_va,
 		uint32_t write_stag, uint64_t write_va)
 {
-	struct iscsi_hdr *hdr = &rx_desc->iscsi_header;
+	struct iscsi_hdr *hdr = isert_get_iscsi_hdr(rx_desc);
 	struct iscsi_conn *conn = isert_conn->conn;
 	struct iscsi_cmd *cmd;
 	struct isert_cmd *isert_cmd;

@@ -1399,8 +1400,8 @@ isert_recv_done(struct ib_cq *cq, struct ib_wc *wc)
 	struct isert_conn *isert_conn = wc->qp->qp_context;
 	struct ib_device *ib_dev = isert_conn->cm_id->device;
 	struct iser_rx_desc *rx_desc = cqe_to_rx_desc(wc->wr_cqe);
-	struct iscsi_hdr *hdr = &rx_desc->iscsi_header;
-	struct iser_ctrl *iser_ctrl = &rx_desc->iser_header;
+	struct iscsi_hdr *hdr = isert_get_iscsi_hdr(rx_desc);
+	struct iser_ctrl *iser_ctrl = isert_get_iser_hdr(rx_desc);
 	uint64_t read_va = 0, write_va = 0;
 	uint32_t read_stag = 0, write_stag = 0;

@@ -1414,7 +1415,7 @@ isert_recv_done(struct ib_cq *cq, struct ib_wc *wc)
 	rx_desc->in_use = true;
 
 	ib_dma_sync_single_for_cpu(ib_dev, rx_desc->dma_addr,
-			ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
+			ISER_RX_SIZE, DMA_FROM_DEVICE);
 
 	isert_dbg("DMA: 0x%llx, iSCSI opcode: 0x%02x, ITT: 0x%08x, flags: 0x%02x dlen: %d\n",
 		 rx_desc->dma_addr, hdr->opcode, hdr->itt, hdr->flags,

@@ -1449,7 +1450,7 @@ isert_recv_done(struct ib_cq *cq, struct ib_wc *wc)
 			read_stag, read_va, write_stag, write_va);
 
 	ib_dma_sync_single_for_device(ib_dev, rx_desc->dma_addr,
-			ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
+			ISER_RX_SIZE, DMA_FROM_DEVICE);
 }
 
 static void

@@ -1463,8 +1464,8 @@ isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc)
 		return;
 	}
 
-	ib_dma_sync_single_for_cpu(ib_dev, isert_conn->login_req_dma,
-			ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
+	ib_dma_sync_single_for_cpu(ib_dev, isert_conn->login_desc->dma_addr,
+			ISER_RX_SIZE, DMA_FROM_DEVICE);
 
 	isert_conn->login_req_len = wc->byte_len - ISER_HEADERS_LEN;

@@ -1479,8 +1480,8 @@ isert_login_recv_done(struct ib_cq *cq, struct ib_wc *wc)
 	complete(&isert_conn->login_req_comp);
 	mutex_unlock(&isert_conn->mutex);
 
-	ib_dma_sync_single_for_device(ib_dev, isert_conn->login_req_dma,
-				ISER_RX_PAYLOAD_SIZE, DMA_FROM_DEVICE);
+	ib_dma_sync_single_for_device(ib_dev, isert_conn->login_desc->dma_addr,
+				ISER_RX_SIZE, DMA_FROM_DEVICE);
 }
 
 static void

drivers/infiniband/ulp/isert/ib_isert.h +31 ~~-10~~

70 lines not on this page · raw message

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:32 UTC #66 lore raw

PATCH 55/177 ARM: dts: bcm: HR2: Fixed QSPI compatible string

From: Florian Fainelli <[email protected]>

[ Upstream commit d663186293a818af97c648624bee6c7a59e8218b ]

The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly.

Fixes b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file")

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/bcm-hr2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/bcm-hr2.dtsi +1 -1

index 5e5f5ca3c86f1..bba0e8cd2acbd 100644
@@ -217,7 +217,7 @@
 		};
 
 		qspi: spi@27200 {
-			compatible = "brcm,spi-bcm-qspi", "brcm,spi-nsp-qspi";
+			compatible = "brcm,spi-nsp-qspi", "brcm,spi-bcm-qspi";
 			reg = <0x027200 0x184>,
 			      <0x027000 0x124>,
 			      <0x11c408 0x004>,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:26 UTC #67 lore raw

PATCH 56/177 ARM: dts: NSP: Fixed QSPI compatible string

From: Florian Fainelli <[email protected]>

[ Upstream commit d1ecc40a954fd0f5e3789b91fa80f15e82284e39 ]

The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly.

Fixes 329f98c1974e ("ARM: dts: NSP: Add QSPI nodes to NSPI and bcm958625k DTSes")

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/bcm-nsp.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/bcm-nsp.dtsi +1 -1

index 3175266ede646..465937b79c8e4 100644
@@ -284,7 +284,7 @@
 		};
 
 		qspi: spi@27200 {
-			compatible = "brcm,spi-bcm-qspi", "brcm,spi-nsp-qspi";
+			compatible = "brcm,spi-nsp-qspi", "brcm,spi-bcm-qspi";
 			reg = <0x027200 0x184>,
 			      <0x027000 0x124>,
 			      <0x11c408 0x004>,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:25 UTC #68 lore raw

PATCH 57/177 ARM: dts: BCM5301X: Fixed QSPI compatible string

From: Florian Fainelli <[email protected]>

[ Upstream commit b793dab8d811e103665d6bddaaea1c25db3776eb ]

The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly.

Fixes 1c8f40650723 ("ARM: dts: BCM5301X: convert to iProc QSPI")

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm/boot/dts/bcm5301x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/boot/dts/bcm5301x.dtsi +1 -1

index 2d9b4dd058307..0016720ce5300 100644
@@ -488,7 +488,7 @@
 	};
 
 	spi@18029200 {
-		compatible = "brcm,spi-bcm-qspi", "brcm,spi-nsp-qspi";
+		compatible = "brcm,spi-nsp-qspi", "brcm,spi-bcm-qspi";
 		reg = <0x18029200 0x184>,
 		      <0x18029000 0x124>,
 		      <0x1811b408 0x004>,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:26 UTC #69 lore raw

PATCH 58/177 arm64: dts: ns2: Fixed QSPI compatible string

From: Florian Fainelli <[email protected]>

[ Upstream commit 686e0a0c8c61e0e3f55321d0181fece3efd92777 ]

The string was incorrectly defined before from least to most specific, swap the compatible strings accordingly.

Fixes ff73917d38a6 ("ARM64: dts: Add QSPI Device Tree node for NS2")

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi +1 -1

index 15f7b0ed38369..39802066232e1 100644
@@ -745,7 +745,7 @@
 		};
 
 		qspi: spi@66470200 {
-			compatible = "brcm,spi-bcm-qspi", "brcm,spi-ns2-qspi";
+			compatible = "brcm,spi-ns2-qspi", "brcm,spi-bcm-qspi";
 			reg = <0x66470200 0x184>,
 				<0x66470000 0x124>,
 				<0x67017408 0x004>,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:25 UTC #70 lore raw

PATCH 59/177 KVM: nVMX: Fix the update value of nested load IA32_PERF_GLOBAL_CTRL control

From: Chenyi Qiang <[email protected]>

[ Upstream commit c6b177a3beb9140dc0ba05b61c5142fcec5f2bf7 ]

A minor fix for the update of VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL field in exit_ctls_high.

Fixes 03a8871add95 ("KVM: nVMX: Expose load IA32_PERF_GLOBAL_CTRL

VM-{Entry,Exit} control")

Signed-off-by Chenyi Qiang <[email protected]>

Reviewed-by Xiaoyao Li <[email protected]>

Message-Id: <[email protected]>

Reviewed-by Jim Mattson <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/kvm/vmx/nested.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kvm/vmx/nested.c +1 -1

index 11e4df5600183..a5810928b011f 100644
@@ -4620,7 +4620,7 @@ void nested_vmx_pmu_entry_exit_ctls_update(struct kvm_vcpu *vcpu)
 		vmx->nested.msrs.entry_ctls_high &=
 				~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
 		vmx->nested.msrs.exit_ctls_high &=
-				~VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL;
+				~VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL;
 	}
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:25 UTC #71 lore raw

PATCH 60/177 KVM: x86: always allow writing 0 to MSR_KVM_ASYNC_PF_EN

From: Vitaly Kuznetsov <[email protected]>

[ Upstream commit d831de177217cd494bfb99f2c849a0d40c2a7890 ]

Even without in-kernel LAPIC we should allow writing '0' to MSR_KVM_ASYNC_PF_EN as we're not enabling the mechanism. In particular, QEMU with 'kernel-irqchip=off' fails to start a guest with

qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0

Fixes 9d3c447c72fb2 ("KVM: X86: Fix async pf caused null-ptr-deref")

Reported-by Dr. David Alan Gilbert <[email protected]>

Signed-off-by Vitaly Kuznetsov <[email protected]>

Message-Id: <[email protected]>

[Actually commit the version proposed by Sean Christopherson. - Paolo]

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/x86/kvm/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/kvm/x86.c +1 -1

index f7304132d5907..f5481ae588aff 100644
@@ -2696,7 +2696,7 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
 		return 1;
 
 	if (!lapic_in_kernel(vcpu))
-		return 1;
+		return data ? 1 : 0;
 
 	vcpu->arch.apf.msr_en_val = data;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:26 UTC #72 lore raw

PATCH 61/177 ARC: HSDK: wireup perf irq

From: Vineet Gupta <[email protected]>

[ Upstream commit fe81d927b78c4f0557836661d32e41ebc957b024 ]

Newer version of HSDK aka HSDK-4xD (with dual issue HS48x4 CPU) wired up the perf interrupt, so enable that in DT.
This is OK for old HSDK where this irq is ignored because pct irq is not wired up in hardware.

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arc/boot/dts/hsdk.dts | 2 ++
 1 file changed, 2 insertions(+)

arch/arc/boot/dts/hsdk.dts +2 -0

index 9acbeba832c0b..5d64a5a940ee6 100644
@@ -88,6 +88,8 @@
 
 	arcpct: pct {
 		compatible = "snps,archs-pct";
+		interrupt-parent = <&cpu_intc>;
+		interrupts = <20>;
 	};
 
 	/* TIMER0 with interrupt for clockevent */

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:24 UTC #73 lore raw

PATCH 62/177 dmaengine: acpi: Put the CSRT table after using it

From: Hanjun Guo <[email protected]>

[ Upstream commit 7eb48dd094de5fe0e216b550e73aa85257903973 ]

The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used at runtime to release the table mapping, put the CSRT table buf after using it.

Signed-off-by Hanjun Guo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/dma/acpi-dma.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/dma/acpi-dma.c +3 -1

index 8a05db3343d39..dcbcb712de6e8 100644
@@ -135,11 +135,13 @@ static void acpi_dma_parse_csrt(struct acpi_device *adev, struct acpi_dma *adma)
 		if (ret < 0) {
 			dev_warn(&adev->dev,
 				 "error in parsing resource group\n");
-			return;
+			break;
 		}
 
 		grp = (struct acpi_csrt_group *)((void *)grp + grp->length);
 	}
+
+	acpi_put_table((struct acpi_table_header *)csrt);
 }
 
 /**

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:34 UTC #74 lore raw

PATCH 63/177 MIPS: Loongson64: Do not override watch and ejtag feature

From: Jiaxun Yang <[email protected]>

[ Upstream commit 433c1ca0d441ee0b88fdd83c84ee6d6d43080dcd ]

Do not override ejtag feature to 0 as Loongson 3A1000+ do have ejtag. For watch, as KVM emulated CPU doesn't have watch feature, we should not enable it unconditionally.

Signed-off-by Jiaxun Yang <[email protected]>

Reviewed-by Huacai Chen <[email protected]>

Signed-off-by Thomas Bogendoerfer <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h | 2 --
 1 file changed, 2 deletions(-)

arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h +0 -2

index b6e9c99b85a52..eb181224eb4c4 100644
@@ -26,7 +26,6 @@
 #define cpu_has_counter		1
 #define cpu_has_dc_aliases	(PAGE_SIZE < 0x4000)
 #define cpu_has_divec		0
-#define cpu_has_ejtag		0
 #define cpu_has_inclusive_pcaches	1
 #define cpu_has_llsc		1
 #define cpu_has_mcheck		0

@@ -42,7 +41,6 @@
 #define cpu_has_veic		0
 #define cpu_has_vint		0
 #define cpu_has_vtag_icache	0
-#define cpu_has_watch		1
 #define cpu_has_wsbh		1
 #define cpu_has_ic_fills_f_dc	1
 #define cpu_hwrena_impl_bits	0xc0000000

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:34 UTC #75 lore raw

PATCH 64/177 netfilter: conntrack: allow sctp hearbeat after connection re-use

From: Florian Westphal <[email protected]>

[ Upstream commit cc5453a5b7e90c39f713091a7ebc53c1f87d1700 ]

If an sctp connection gets re-used, heartbeats are flagged as invalid because their vtag doesn't match.

Handle this in a similar way as TCP conntrack when it suspects that the endpoints and conntrack are out-of-sync.

When a HEARTBEAT request fails its vtag validation, flag this in the conntrack state and accept the packet.

When a HEARTBEAT_ACK is received with an invalid vtag in the reverse direction after we allowed such a HEARTBEAT through, assume we are out-of-sync and re-set the vtag info.

v2: remove left-over snippet from an older incarnation that moved
new_state/old_state assignments, thats not needed so keep that as-is.

Signed-off-by Florian Westphal <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 include/linux/netfilter/nf_conntrack_sctp.h |  2 ++
 net/netfilter/nf_conntrack_proto_sctp.c     | 39 ++++++++++++++++++---
 2 files changed, 37 insertions(+), 4 deletions(-)

include/linux/netfilter/nf_conntrack_sctp.h +2 -0

index 9a33f171aa822..625f491b95de8 100644
@@ -9,6 +9,8 @@ struct ip_ct_sctp {
 	enum sctp_conntrack state;
 
 	__be32 vtag[IP_CT_DIR_MAX];
+	u8 last_dir;
+	u8 flags;
 };
 
 #endif /* _NF_CONNTRACK_SCTP_H */

net/netfilter/nf_conntrack_proto_sctp.c +35 -4

index 4f897b14b6069..810cca24b3990 100644
@@ -62,6 +62,8 @@ static const unsigned int sctp_timeouts[SCTP_CONNTRACK_MAX] = {
 	[SCTP_CONNTRACK_HEARTBEAT_ACKED]	= 210 SECS,
 };
 
+#define	SCTP_FLAG_HEARTBEAT_VTAG_FAILED	1
+
 #define sNO SCTP_CONNTRACK_NONE
 #define	sCL SCTP_CONNTRACK_CLOSED
 #define	sCW SCTP_CONNTRACK_COOKIE_WAIT

@@ -369,6 +371,7 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
 	u_int32_t offset, count;
 	unsigned int *timeouts;
 	unsigned long map[256 / sizeof(unsigned long)] = { 0 };
+	bool ignore = false;
 
 	if (sctp_error(skb, dataoff, state))
 		return -NF_ACCEPT;

@@ -427,15 +430,39 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
 			/* Sec 8.5.1 (D) */
 			if (sh->vtag != ct->proto.sctp.vtag[dir])
 				goto out_unlock;
-		} else if (sch->type == SCTP_CID_HEARTBEAT ||
-			   sch->type == SCTP_CID_HEARTBEAT_ACK) {
+		} else if (sch->type == SCTP_CID_HEARTBEAT) {
+			if (ct->proto.sctp.vtag[dir] == 0) {
+				pr_debug("Setting %d vtag %x for dir %d\n", sch->type, sh->vtag, dir);
+				ct->proto.sctp.vtag[dir] = sh->vtag;
+			} else if (sh->vtag != ct->proto.sctp.vtag[dir]) {
+				if (test_bit(SCTP_CID_DATA, map) || ignore)
+					goto out_unlock;
+
+				ct->proto.sctp.flags |= SCTP_FLAG_HEARTBEAT_VTAG_FAILED;
+				ct->proto.sctp.last_dir = dir;
+				ignore = true;
+				continue;
+			} else if (ct->proto.sctp.flags & SCTP_FLAG_HEARTBEAT_VTAG_FAILED) {
+				ct->proto.sctp.flags &= ~SCTP_FLAG_HEARTBEAT_VTAG_FAILED;
+			}
+		} else if (sch->type == SCTP_CID_HEARTBEAT_ACK) {
 			if (ct->proto.sctp.vtag[dir] == 0) {
 				pr_debug("Setting vtag %x for dir %d\n",
 					 sh->vtag, dir);
 				ct->proto.sctp.vtag[dir] = sh->vtag;
 			} else if (sh->vtag != ct->proto.sctp.vtag[dir]) {
-				pr_debug("Verification tag check failed\n");
-				goto out_unlock;
+				if (test_bit(SCTP_CID_DATA, map) || ignore)
+					goto out_unlock;
+
+				if ((ct->proto.sctp.flags & SCTP_FLAG_HEARTBEAT_VTAG_FAILED) == 0 ||
+				    ct->proto.sctp.last_dir == dir)
+					goto out_unlock;
+
+				ct->proto.sctp.flags &= ~SCTP_FLAG_HEARTBEAT_VTAG_FAILED;
+				ct->proto.sctp.vtag[dir] = sh->vtag;
+				ct->proto.sctp.vtag[!dir] = 0;
+			} else if (ct->proto.sctp.flags & SCTP_FLAG_HEARTBEAT_VTAG_FAILED) {
+				ct->proto.sctp.flags &= ~SCTP_FLAG_HEARTBEAT_VTAG_FAILED;
 			}
 		}

@@ -470,6 +497,10 @@ int nf_conntrack_sctp_packet(struct nf_conn *ct,
 	}
 	spin_unlock_bh(&ct->lock);
 
+	/* allow but do not refresh timeout */
+	if (ignore)
+		return NF_ACCEPT;
+
 	timeouts = nf_ct_timeout_lookup(ct);
 	if (!timeouts)
 		timeouts = nf_sctp_pernet(nf_ct_net(ct))->timeouts;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:33 UTC #76 lore raw

PATCH 65/177 netfilter: nft_set_rbtree: Detect partial overlap with start endpoint match

From: Stefano Brivio <[email protected]>

[ Upstream commit 0726763043dc10dd4c12481f050b1a5ef8f15410 ]

Getting creative with nft and omitting the interval_overlap() check from the set_overlap() function, without omitting set_overlap() altogether, led to the observation of a partial overlap that wasn't detected, and would actually result in replacement of the end element of an existing interval.

This is due to the fact that we'll return -EEXIST on a matching, pre-existing start element, instead of -ENOTEMPTY, and the error is cleared by API if NLM_F_EXCL is not given. At this point, we can insert a matching start, and duplicate the end element as long as we don't end up into other intervals.

For instance, inserting interval 0 - 2 with an existing 0 - 3 interval would result in a single 0 - 2 interval, and a dangling '3' end element. This is because nft will proceed after inserting the '0' start element as no error is reported, and no further conflicting intervals are detected on insertion of the end element.

This needs a different approach as it's a local condition that can be detected by looking for duplicate ends coming from left and right, separately. Track those and directly report -ENOTEMPTY on duplicated end elements for a matching start.

Signed-off-by Stefano Brivio <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/netfilter/nft_set_rbtree.c | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

net/netfilter/nft_set_rbtree.c +33 -1

index b85ce6f0c0a6f..f317ad80cd6bc 100644
@@ -218,11 +218,11 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
 			       struct nft_rbtree_elem *new,
 			       struct nft_set_ext **ext)
 {
+	bool overlap = false, dup_end_left = false, dup_end_right = false;
 	struct nft_rbtree *priv = nft_set_priv(set);
 	u8 genmask = nft_genmask_next(net);
 	struct nft_rbtree_elem *rbe;
 	struct rb_node *parent, **p;
-	bool overlap = false;
 	int d;
 
 	/* Detect overlaps as we descend the tree. Set the flag in these cases:

@@ -262,6 +262,20 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
 	 *
 	 * which always happen as last step and imply that no further
 	 * overlapping is possible.
+	 *
+	 * Another special case comes from the fact that start elements matching
+	 * an already existing start element are allowed: insertion is not
+	 * performed but we return -EEXIST in that case, and the error will be
+	 * cleared by the caller if NLM_F_EXCL is not present in the request.
+	 * This way, request for insertion of an exact overlap isn't reported as
+	 * error to userspace if not desired.
+	 *
+	 * However, if the existing start matches a pre-existing start, but the
+	 * end element doesn't match the corresponding pre-existing end element,
+	 * we need to report a partial overlap. This is a local condition that
+	 * can be noticed without need for a tracking flag, by checking for a
+	 * local duplicated end for a corresponding start, from left and right,
+	 * separately.
 	 */
 
 	parent = NULL;

@@ -281,19 +295,35 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
 				    !nft_set_elem_expired(&rbe->ext) && !*p)
 					overlap = false;
 			} else {
+				if (dup_end_left && !*p)
+					return -ENOTEMPTY;
+
 				overlap = nft_rbtree_interval_end(rbe) &&
 					  nft_set_elem_active(&rbe->ext,
 							      genmask) &&
 					  !nft_set_elem_expired(&rbe->ext);
+
+				if (overlap) {
+					dup_end_right = true;
+					continue;
+				}
 			}
 		} else if (d > 0) {
 			p = &parent->rb_right;
 
 			if (nft_rbtree_interval_end(new)) {
+				if (dup_end_right && !*p)
+					return -ENOTEMPTY;
+
 				overlap = nft_rbtree_interval_end(rbe) &&
 					  nft_set_elem_active(&rbe->ext,
 							      genmask) &&
 					  !nft_set_elem_expired(&rbe->ext);
+
+				if (overlap) {
+					dup_end_left = true;
+					continue;
+				}
 			} else if (nft_set_elem_active(&rbe->ext, genmask) &&
 				   !nft_set_elem_expired(&rbe->ext)) {
 				overlap = nft_rbtree_interval_end(rbe);

@@ -321,6 +351,8 @@ static int __nft_rbtree_insert(const struct net *net, const struct nft_set *set,
 				p = &parent->rb_left;
 			}
 		}
+
+		dup_end_left = dup_end_right = false;
 	}
 
 	if (overlap)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:34 UTC #77 lore raw

PATCH 66/177 drivers/net/wan/lapbether: Added needed_tailroom

From: Xie He <[email protected]>

[ Upstream commit 1ee39c1448c4e0d480c5b390e2db1987561fb5c2 ]

The underlying Ethernet device may request necessary tailroom to be allocated by setting needed_tailroom. This driver should also set needed_tailroom to request the tailroom needed by the underlying Ethernet device to be allocated.

Cc Willem de Bruijn <[email protected]>

Cc Martin Schiller <[email protected]>

Signed-off-by Xie He <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wan/lapbether.c | 1 +
 1 file changed, 1 insertion(+)

drivers/net/wan/lapbether.c +1 -0

index 1ea15f2123ed5..cc297ea9c6ece 100644
@@ -340,6 +340,7 @@ static int lapbeth_new_device(struct net_device *dev)
 	 */
 	ndev->needed_headroom = -1 + 3 + 2 + dev->hard_header_len
 					   + dev->needed_headroom;
+	ndev->needed_tailroom = dev->needed_tailroom;
 
 	lapbeth = netdev_priv(ndev);
 	lapbeth->axdev = ndev;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:35 UTC #78 lore raw

PATCH 67/177 NFC: st95hf: Fix memleak in st95hf_in_send_cmd

From: Dinghao Liu <[email protected]>

[ Upstream commit f97c04c316d8fea16dca449fdfbe101fbdfee6a2 ]

When down_killable() fails, skb_resp should be freed just like when st95hf_spi_send() fails.

Signed-off-by Dinghao Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nfc/st95hf/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/nfc/st95hf/core.c +1 -1

index 9642971e89cea..4578547659839 100644
@@ -966,7 +966,7 @@ static int st95hf_in_send_cmd(struct nfc_digital_dev *ddev,
 	rc = down_killable(&stcontext->exchange_lock);
 	if (rc) {
 		WARN(1, "Semaphore is not found up in st95hf_in_send_cmd\n");
-		return rc;
+		goto free_skb_resp;
 	}
 
 	rc = st95hf_spi_send(&stcontext->spicontext, skb->data,

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:34 UTC #79 lore raw

PATCH 68/177 firestream: Fix memleak in fs_open

From: Dinghao Liu <[email protected]>

[ Upstream commit 15ac5cdafb9202424206dc5bd376437a358963f9 ]

When make_rate() fails, vcc should be freed just like other error paths in fs_open().

Signed-off-by Dinghao Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/atm/firestream.c | 1 +
 1 file changed, 1 insertion(+)

drivers/atm/firestream.c +1 -0

index cc87004d5e2d6..5f22555933df1 100644
@@ -998,6 +998,7 @@ static int fs_open(struct atm_vcc *atm_vcc)
 				error = make_rate (pcr, r, &tmc0, NULL);
 				if (error) {
 					kfree(tc);
+					kfree(vcc);
 					return error;
 				}
 			}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:33 UTC #80 lore raw

PATCH 69/177 scsi: qedf: Fix null ptr reference in qedf_stag_change_work

From: Ye Bin <[email protected]>

[ Upstream commit f308a35f547cd7c1d8a901c12b3ac508e96df665 ]

Link https://lore.kernel.org/r/[email protected] open here

Acked-by Saurav Kashyap <[email protected]>

Signed-off-by Ye Bin <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/scsi/qedf/qedf_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/qedf/qedf_main.c +1 -1

index 36b1ca2dadbb5..51cfab9d1afdc 100644
@@ -3843,7 +3843,7 @@ void qedf_stag_change_work(struct work_struct *work)
 	    container_of(work, struct qedf_ctx, stag_work.work);
 
 	if (!qedf) {
-		QEDF_ERR(&qedf->dbg_ctx, "qedf is NULL");
+		QEDF_ERR(NULL, "qedf is NULL");
 		return;
 	}
 	QEDF_ERR(&qedf->dbg_ctx, "Performing software context reset.\n");

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:34 UTC #81 lore raw

PATCH 70/177 ALSA: hda: Fix 2 channel swapping for Tegra

From: Mohan Kumar <[email protected]>

[ Upstream commit 216116eae43963c662eb84729507bad95214ca6b ]

The Tegra HDA codec HW implementation has an issue related to not swapping the 2 channel Audio Sample Packet(ASP) channel mapping. Whatever the FL and FR mapping specified the left channel always comes out of left speaker and right channel on right speaker. So add condition to disallow the swapping of FL,FR during the playback.

Signed-off-by Mohan Kumar <[email protected]>

Acked-by Sameer Pujar <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/hda/patch_hdmi.c | 5 +++++
 1 file changed, 5 insertions(+)

sound/pci/hda/patch_hdmi.c +5 -0

index fc22bdc30da3e..bde3b3a169eb2 100644
@@ -3671,6 +3671,7 @@ static int tegra_hdmi_build_pcms(struct hda_codec *codec)
 
 static int patch_tegra_hdmi(struct hda_codec *codec)
 {
+	struct hdmi_spec *spec;
 	int err;
 
 	err = patch_generic_hdmi(codec);

@@ -3678,6 +3679,10 @@ static int patch_tegra_hdmi(struct hda_codec *codec)
 		return err;
 
 	codec->patch_ops.build_pcms = tegra_hdmi_build_pcms;
+	spec = codec->spec;
+	spec->chmap.ops.chmap_cea_alloc_validate_get_type =
+		nvhdmi_chmap_cea_alloc_validate_get_type;
+	spec->chmap.ops.chmap_validate = nvhdmi_chmap_validate;
 
 	return 0;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:33 UTC #82 lore raw

PATCH 71/177 ALSA: hda/tegra: Program WAKEEN register for Tegra

From: Mohan Kumar <[email protected]>

[ Upstream commit 23d63a31d9f44d7daeac0d1fb65c6a73c70e5216 ]

The WAKEEN bits are used to indicate which bits in the STATESTS register may cause wake event during the codec state change request. Configure the WAKEEN register for the Tegra to detect the wake events.

Signed-off-by Mohan Kumar <[email protected]>

Acked-by Sameer Pujar <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/hda/hda_tegra.c | 7 +++++++
 1 file changed, 7 insertions(+)

sound/pci/hda/hda_tegra.c +7 -0

index 0cc5fad1af8a9..ae40ca3f29837 100644
@@ -179,6 +179,10 @@ static int __maybe_unused hda_tegra_runtime_suspend(struct device *dev)
 	struct hda_tegra *hda = container_of(chip, struct hda_tegra, chip);
 
 	if (chip && chip->running) {
+		/* enable controller wake up event */
+		azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) |
+			   STATESTS_INT_MASK);
+
 		azx_stop_chip(chip);
 		azx_enter_link_reset(chip);
 	}

@@ -200,6 +204,9 @@ static int __maybe_unused hda_tegra_runtime_resume(struct device *dev)
 	if (chip && chip->running) {
 		hda_tegra_init(hda);
 		azx_init_chip(chip, 1);
+		/* disable controller wake up event*/
+		azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) &
+			   ~STATESTS_INT_MASK);
 	}
 
 	return 0;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:33 UTC #83 lore raw

PATCH 72/177 drivers/dma/dma-jz4780: Fix race condition between probe and irq handler

From: Madhuparna Bhowmik <[email protected]>

[ Upstream commit 6d6018fc30bee67290dbed2fa51123f7c6f3d691 ]

In probe, IRQ is requested before zchan->id is initialized which can be read in the irq handler. Hence, shift request irq after other initializations complete.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by Madhuparna Bhowmik <[email protected]>

Reviewed-by Paul Cercueil <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/dma/dma-jz4780.c | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

drivers/dma/dma-jz4780.c +19 ~~-19~~

index 448f663da89c6..8beed91428bd6 100644
@@ -879,24 +879,11 @@ static int jz4780_dma_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	ret = platform_get_irq(pdev, 0);
-	if (ret < 0)
-		return ret;
-
-	jzdma->irq = ret;
-
-	ret = request_irq(jzdma->irq, jz4780_dma_irq_handler, 0, dev_name(dev),
-			  jzdma);
-	if (ret) {
-		dev_err(dev, "failed to request IRQ %u!\n", jzdma->irq);
-		return ret;
-	}
-
 	jzdma->clk = devm_clk_get(dev, NULL);
 	if (IS_ERR(jzdma->clk)) {
 		dev_err(dev, "failed to get clock\n");
 		ret = PTR_ERR(jzdma->clk);
-		goto err_free_irq;
+		return ret;
 	}
 
 	clk_prepare_enable(jzdma->clk);

@@ -949,10 +936,23 @@ static int jz4780_dma_probe(struct platform_device *pdev)
 		jzchan->vchan.desc_free = jz4780_dma_desc_free;
 	}
 
+	ret = platform_get_irq(pdev, 0);
+	if (ret < 0)
+		goto err_disable_clk;
+
+	jzdma->irq = ret;
+
+	ret = request_irq(jzdma->irq, jz4780_dma_irq_handler, 0, dev_name(dev),
+			  jzdma);
+	if (ret) {
+		dev_err(dev, "failed to request IRQ %u!\n", jzdma->irq);
+		goto err_disable_clk;
+	}
+
 	ret = dmaenginem_async_device_register(dd);
 	if (ret) {
 		dev_err(dev, "failed to register device\n");
-		goto err_disable_clk;
+		goto err_free_irq;
 	}
 
 	/* Register with OF DMA helpers. */

@@ -960,17 +960,17 @@ static int jz4780_dma_probe(struct platform_device *pdev)
 					 jzdma);
 	if (ret) {
 		dev_err(dev, "failed to register OF DMA controller\n");
-		goto err_disable_clk;
+		goto err_free_irq;
 	}
 
 	dev_info(dev, "JZ4780 DMA controller initialised\n");
 	return 0;
 
-err_disable_clk:
-	clk_disable_unprepare(jzdma->clk);
-
 err_free_irq:
 	free_irq(jzdma->irq, jzdma);
+
+err_disable_clk:
+	clk_disable_unprepare(jzdma->clk);
 	return ret;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:32 UTC #84 lore raw

PATCH 73/177 net: hns3: Fix for geneve tx checksum bug

From: Yi Li <[email protected]>

[ Upstream commit a156998fc92d3859c8e820f1583f6d0541d643c3 ]

when skb->encapsulation is 0, skb->ip_summed is CHECKSUM_PARTIAL and it is udp packet, which has a dest port as the IANA assigned. the hardware is expected to do the checksum offload, but the hardware will not do the checksum offload when udp dest port is 6081.

This patch fixes it by doing the checksum in software.

Reported-by Li Bing <[email protected]>

Signed-off-by Yi Li <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +4 -2

index 71ed4c54f6d5d..eaadcc7043349 100644
@@ -20,6 +20,7 @@
 #include <net/pkt_cls.h>
 #include <net/tcp.h>
 #include <net/vxlan.h>
+#include <net/geneve.h>
 
 #include "hnae3.h"
 #include "hns3_enet.h"

@@ -780,7 +781,7 @@ static int hns3_get_l4_protocol(struct sk_buff *skb, u8 *ol4_proto,
  * and it is udp packet, which has a dest port as the IANA assigned.
  * the hardware is expected to do the checksum offload, but the
  * hardware will not do the checksum offload when udp dest port is
- * 4789.
+ * 4789 or 6081.
  */
 static bool hns3_tunnel_csum_bug(struct sk_buff *skb)
 {

@@ -789,7 +790,8 @@ static bool hns3_tunnel_csum_bug(struct sk_buff *skb)
 	l4.hdr = skb_transport_header(skb);
 
 	if (!(!skb->encapsulation &&
-	      l4.udp->dest == htons(IANA_VXLAN_UDP_PORT)))
+	      (l4.udp->dest == htons(IANA_VXLAN_UDP_PORT) ||
+	      l4.udp->dest == htons(GENEVE_UDP_PORT))))
 		return false;
 
 	skb_checksum_help(skb);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:38 UTC #85 lore raw

PATCH 74/177 xfs: fix off-by-one in inode alloc block reservation calculation

From: Brian Foster <[email protected]>

[ Upstream commit 657f101930bc6c5b41bd7d6c22565c4302a80d33 ]

The inode chunk allocation transaction reserves inobt_maxlevels-1 blocks to accommodate a full split of the inode btree. A full split requires an allocation for every existing level and a new root block, which means inobt_maxlevels is the worst case block requirement for a transaction that inserts to the inobt. This can lead to a transaction block reservation overrun when tmpfile creation allocates an inode chunk and expands the inobt to its maximum depth. This problem has been observed in conjunction with overlayfs, which makes frequent use of tmpfiles internally.

The existing reservation code goes back as far as the Linux git repo history (v2.6.12). It was likely never observed as a problem because the traditional file/directory creation transactions also include worst case block reservation for directory modifications, which most likely is able to make up for a single block deficiency in the inode allocation portion of the calculation. tmpfile support is relatively more recent (v3.15), less heavily used, and only includes the inode allocation block reservation as tmpfiles aren't linked into the directory tree on creation.

Fix up the inode alloc block reservation macro and a couple of the block allocator minleft parameters that enforce an allocation to leave enough free blocks in the AG for a full inobt split.

Signed-off-by Brian Foster <[email protected]>

Reviewed-by Darrick J. Wong <[email protected]>

Signed-off-by Darrick J. Wong <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/xfs/libxfs/xfs_ialloc.c      | 4 ++--
 fs/xfs/libxfs/xfs_trans_space.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

fs/xfs/libxfs/xfs_ialloc.c +2 -2

index 7fcf62b324b0d..8c1a7cc484b65 100644
@@ -688,7 +688,7 @@ xfs_ialloc_ag_alloc(
 		args.minalignslop = igeo->cluster_align - 1;
 
 		/* Allow space for the inode btree to split. */
-		args.minleft = igeo->inobt_maxlevels - 1;
+		args.minleft = igeo->inobt_maxlevels;
 		if ((error = xfs_alloc_vextent(&args)))
 			return error;

@@ -736,7 +736,7 @@ xfs_ialloc_ag_alloc(
 		/*
 		 * Allow space for the inode btree to split.
 		 */
-		args.minleft = igeo->inobt_maxlevels - 1;
+		args.minleft = igeo->inobt_maxlevels;
 		if ((error = xfs_alloc_vextent(&args)))
 			return error;
 	}

fs/xfs/libxfs/xfs_trans_space.h +1 -1

index c6df01a2a1585..7ad3659c5d2a9 100644
@@ -58,7 +58,7 @@
 #define	XFS_IALLOC_SPACE_RES(mp)	\
 	(M_IGEO(mp)->ialloc_blks + \
 	 ((xfs_sb_version_hasfinobt(&mp->m_sb) ? 2 : 1) * \
-	  (M_IGEO(mp)->inobt_maxlevels - 1)))
+	  M_IGEO(mp)->inobt_maxlevels))
 
 /*
  * Space reservation values for various transactions.

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:26 UTC #86 lore raw

PATCH 75/177 drivers/net/wan/lapbether: Set network_header before transmitting

From: Xie He <[email protected]>

[ Upstream commit 91244d108441013b7367b3b4dcc6869998676473 ]

Set the skb's network_header before it is passed to the underlying Ethernet device for transmission.

This patch fixes the following issue:

When we use this driver with AF_PACKET sockets, there would be error messages of:
protocol 0805 is buggy, dev (Ethernet interface name)
printed in the system "dmesg" log.

This is because skbs passed down to the Ethernet device for transmission don't have their network_header properly set, and the dev_queue_xmit_nit function in net/core/dev.c complains about this.

Reason of setting the network_header to this place (at the end of the Ethernet header, and at the beginning of the Ethernet payload):

Because when this driver receives an skb from the Ethernet device, the network_header is also set at this place.

Cc Martin Schiller <[email protected]>

Signed-off-by Xie He <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wan/lapbether.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/net/wan/lapbether.c +2 -0

index cc297ea9c6ece..e61616b0b91c7 100644
@@ -210,6 +210,8 @@ static void lapbeth_data_transmit(struct net_device *ndev, struct sk_buff *skb)
 
 	skb->dev = dev = lapbeth->ethdev;
 
+	skb_reset_network_header(skb);
+
 	dev_hard_header(skb, dev, ETH_P_DEC, bcast_addr, NULL, 0);
 
 	dev_queue_xmit(skb);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:32 UTC #87 lore raw

PATCH 76/177 wireless: fix wrong 160/80+80 MHz setting

From: Shay Bar <[email protected]>

[ Upstream commit 3579994476b65cb5e272ff0f720a1fd31322e53f ]

Fix cfg80211_chandef_usable():
consider IEEE80211_VHT_CAP_EXT_NSS_BW when verifying 160/80+80 MHz.

Based on:
"Table 9-272 — Setting of the Supported Channel Width Set subfield and Extended NSS BW Support subfield at a STA transmitting the VHT Capabilities Information field"

Quoted 1 line

From "Draft P802.11REVmd_D3.0.pdf"

Signed-off-by Aviad Brikman <[email protected]>

Signed-off-by Shay Bar <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

[reformat the code a bit and use u32_get_bits()]

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/wireless/chan.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

net/wireless/chan.c +11 -4

index cddf92c5d09ef..7a7cc4ade2b36 100644
@@ -10,6 +10,7 @@
  */
 
 #include <linux/export.h>
+#include <linux/bitfield.h>
 #include <net/cfg80211.h>
 #include "core.h"
 #include "rdev-ops.h"

@@ -892,6 +893,7 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
 	struct ieee80211_sta_vht_cap *vht_cap;
 	struct ieee80211_edmg *edmg_cap;
 	u32 width, control_freq, cap;
+	bool support_80_80 = false;
 
 	if (WARN_ON(!cfg80211_chandef_valid(chandef)))
 		return false;

@@ -944,9 +946,13 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
 			return false;
 		break;
 	case NL80211_CHAN_WIDTH_80P80:
-		cap = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
-		if (chandef->chan->band != NL80211_BAND_6GHZ &&
-		    cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)
+		cap = vht_cap->cap;
+		support_80_80 =
+			(cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ) ||
+			(cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ &&
+			 cap & IEEE80211_VHT_CAP_EXT_NSS_BW_MASK) ||
+			u32_get_bits(cap, IEEE80211_VHT_CAP_EXT_NSS_BW_MASK) > 1;
+		if (chandef->chan->band != NL80211_BAND_6GHZ && !support_80_80)
 			return false;
 		/* fall through */
 	case NL80211_CHAN_WIDTH_80:

@@ -966,7 +972,8 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
 			return false;
 		cap = vht_cap->cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK;
 		if (cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ &&
-		    cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ)
+		    cap != IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ &&
+		    !(vht_cap->cap & IEEE80211_VHT_CAP_EXT_NSS_BW_MASK))
 			return false;
 		break;
 	default:

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:32 UTC #88 lore raw

PATCH 77/177 mac80211: reduce packet loss event false positives

From: Felix Fietkau <[email protected]>

[ Upstream commit 47df8e059b49a80c179fae39256bcd7096810934 ]

When running a large number of packets per second with a high data rate and long A-MPDUs, the packet loss threshold can be reached very quickly when the link conditions change. This frequently shows up as spurious disconnects.
Mitigate false positives by using a similar logic for regular stations as the one being used for TDLS, though with a more aggressive timeout. Packet loss events are only reported if no ACK was received for a second.

Signed-off-by Felix Fietkau <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/mac80211/sta_info.h |  4 ++--
 net/mac80211/status.c   | 31 +++++++++++++++----------------
 2 files changed, 17 insertions(+), 18 deletions(-)

net/mac80211/sta_info.h +2 -2

index 49728047dfad6..f66fcce8e6a45 100644
@@ -522,7 +522,7 @@ struct ieee80211_sta_rx_stats {
  * @status_stats.retry_failed: # of frames that failed after retry
  * @status_stats.retry_count: # of retries attempted
  * @status_stats.lost_packets: # of lost packets
- * @status_stats.last_tdls_pkt_time: timestamp of last TDLS packet
+ * @status_stats.last_pkt_time: timestamp of last ACKed packet
  * @status_stats.msdu_retries: # of MSDU retries
  * @status_stats.msdu_failed: # of failed MSDUs
  * @status_stats.last_ack: last ack timestamp (jiffies)

@@ -595,7 +595,7 @@ struct sta_info {
 		unsigned long filtered;
 		unsigned long retry_failed, retry_count;
 		unsigned int lost_packets;
-		unsigned long last_tdls_pkt_time;
+		unsigned long last_pkt_time;
 		u64 msdu_retries[IEEE80211_NUM_TIDS + 1];
 		u64 msdu_failed[IEEE80211_NUM_TIDS + 1];
 		unsigned long last_ack;

net/mac80211/status.c +15 ~~-16~~

index cbc40b358ba26..819c4221c284e 100644
@@ -755,12 +755,16 @@ static void ieee80211_report_used_skb(struct ieee80211_local *local,
  *  - current throughput (higher value for higher tpt)?
  */
 #define STA_LOST_PKT_THRESHOLD	50
+#define STA_LOST_PKT_TIME	HZ		/* 1 sec since last ACK */
 #define STA_LOST_TDLS_PKT_THRESHOLD	10
 #define STA_LOST_TDLS_PKT_TIME		(10*HZ) /* 10secs since last ACK */
 
 static void ieee80211_lost_packet(struct sta_info *sta,
 				  struct ieee80211_tx_info *info)
 {
+	unsigned long pkt_time = STA_LOST_PKT_TIME;
+	unsigned int pkt_thr = STA_LOST_PKT_THRESHOLD;
+
 	/* If driver relies on its own algorithm for station kickout, skip
 	 * mac80211 packet loss mechanism.
 	 */

@@ -773,21 +777,20 @@ static void ieee80211_lost_packet(struct sta_info *sta,
 		return;
 
 	sta->status_stats.lost_packets++;
-	if (!sta->sta.tdls &&
-	    sta->status_stats.lost_packets < STA_LOST_PKT_THRESHOLD)
-		return;
+	if (sta->sta.tdls) {
+		pkt_time = STA_LOST_TDLS_PKT_TIME;
+		pkt_thr = STA_LOST_PKT_THRESHOLD;
+	}
 
 	/*
 	 * If we're in TDLS mode, make sure that all STA_LOST_TDLS_PKT_THRESHOLD
 	 * of the last packets were lost, and that no ACK was received in the
 	 * last STA_LOST_TDLS_PKT_TIME ms, before triggering the CQM packet-loss
 	 * mechanism.
+	 * For non-TDLS, use STA_LOST_PKT_THRESHOLD and STA_LOST_PKT_TIME
 	 */
-	if (sta->sta.tdls &&
-	    (sta->status_stats.lost_packets < STA_LOST_TDLS_PKT_THRESHOLD ||
-	     time_before(jiffies,
-			 sta->status_stats.last_tdls_pkt_time +
-			 STA_LOST_TDLS_PKT_TIME)))
+	if (sta->status_stats.lost_packets < pkt_thr ||
+	    !time_after(jiffies, sta->status_stats.last_pkt_time + pkt_time))
 		return;
 
 	cfg80211_cqm_pktloss_notify(sta->sdata->dev, sta->sta.addr,

@@ -1035,9 +1038,7 @@ static void __ieee80211_tx_status(struct ieee80211_hw *hw,
 					sta->status_stats.lost_packets = 0;
 
 				/* Track when last TDLS packet was ACKed */
-				if (test_sta_flag(sta, WLAN_STA_TDLS_PEER_AUTH))
-					sta->status_stats.last_tdls_pkt_time =
-						jiffies;
+				sta->status_stats.last_pkt_time = jiffies;
 			} else if (noack_success) {
 				/* nothing to do here, do not account as lost */
 			} else {

@@ -1170,9 +1171,8 @@ void ieee80211_tx_status_ext(struct ieee80211_hw *hw,
 			if (sta->status_stats.lost_packets)
 				sta->status_stats.lost_packets = 0;
 
-			/* Track when last TDLS packet was ACKed */
-			if (test_sta_flag(sta, WLAN_STA_TDLS_PEER_AUTH))
-				sta->status_stats.last_tdls_pkt_time = jiffies;
+			/* Track when last packet was ACKed */
+			sta->status_stats.last_pkt_time = jiffies;
 		} else if (test_sta_flag(sta, WLAN_STA_PS_STA)) {
 			return;
 		} else if (noack_success) {

@@ -1261,8 +1261,7 @@ void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
 			if (sta->status_stats.lost_packets)
 				sta->status_stats.lost_packets = 0;
 
-			if (test_sta_flag(sta, WLAN_STA_TDLS_PEER_AUTH))
-				sta->status_stats.last_tdls_pkt_time = jiffies;
+			sta->status_stats.last_pkt_time = jiffies;
 		} else {
 			ieee80211_lost_packet(sta, info);
 		}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:38 UTC #89 lore raw

PATCH 78/177 cfg80211: Adjust 6 GHz frequency to channel conversion

From: Amar Singhal <[email protected]>

[ Upstream commit 2d9b55508556ccee6410310fb9ea2482fd3328eb ]

Adjust the 6 GHz frequency to channel conversion function, the other way around was previously handled.

Signed-off-by Amar Singhal <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

[rewrite commit message, hard-code channel 2]

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 net/wireless/util.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

net/wireless/util.c +5 -3

index 4d3b76f94f55e..a72d2ad6ade8b 100644
@@ -121,11 +121,13 @@ int ieee80211_freq_khz_to_channel(u32 freq)
 		return (freq - 2407) / 5;
 	else if (freq >= 4910 && freq <= 4980)
 		return (freq - 4000) / 5;
-	else if (freq < 5945)
+	else if (freq < 5925)
 		return (freq - 5000) / 5;
+	else if (freq == 5935)
+		return 2;
 	else if (freq <= 45000) /* DMG band lower limit */
-		/* see 802.11ax D4.1 27.3.22.2 */
-		return (freq - 5940) / 5;
+		/* see 802.11ax D6.1 27.3.22.2 */
+		return (freq - 5950) / 5;
 	else if (freq >= 58320 && freq <= 70200)
 		return (freq - 56160) / 2160;
 	else

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:27 UTC #90 lore raw

PATCH 79/177 xfs: initialize the shortform attr header padding entry

From: Darrick J. Wong <[email protected]>

[ Upstream commit 125eac243806e021f33a1fdea3687eccbb9f7636 ]

Don't leak kernel memory contents into the shortform attr fork.

Signed-off-by Darrick J. Wong <[email protected]>

Reviewed-by Eric Sandeen <[email protected]>

Reviewed-by Dave Chinner <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 fs/xfs/libxfs/xfs_attr_leaf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

fs/xfs/libxfs/xfs_attr_leaf.c +2 -2

index 4eb2ecd31b0d2..9bafe50a21240 100644
@@ -653,8 +653,8 @@ xfs_attr_shortform_create(
 		ASSERT(ifp->if_flags & XFS_IFINLINE);
 	}
 	xfs_idata_realloc(dp, sizeof(*hdr), XFS_ATTR_FORK);
-	hdr = (xfs_attr_sf_hdr_t *)ifp->if_u1.if_data;
-	hdr->count = 0;
+	hdr = (struct xfs_attr_sf_hdr *)ifp->if_u1.if_data;
+	memset(hdr, 0, sizeof(*hdr));
 	hdr->totsize = cpu_to_be16(sizeof(*hdr));
 	xfs_trans_log_inode(args->trans, dp, XFS_ILOG_CORE | XFS_ILOG_ADATA);
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:38 UTC #91 lore raw

PATCH 80/177 ARC: show_regs: fix r12 printing and simplify

From: Vineet Gupta <[email protected]>

[ Upstream commit e5c388b4b967037a0e00b60194b0dbcf94881a9b ]

when working on ARC64, spotted an issue in ARCv2 reg file printing. print_reg_file() assumes contiguous reg-file whereas in ARCv2 they are
not: r12 comes before r0-r11 due to hardware auto-save. Apparently this issue has been present since v2 port submission.

To avoid bolting hacks for this discontinuity while looping through pt_regs, just ditching the loop and print pt_regs directly.

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arc/kernel/troubleshoot.c | 77 +++++++++++++---------------------
 1 file changed, 30 insertions(+), 47 deletions(-)

arch/arc/kernel/troubleshoot.c +30 ~~-47~~

index 28e8bf04b253f..a331bb5d8319f 100644
@@ -18,44 +18,37 @@
 
 #define ARC_PATH_MAX	256
 
-/*
- * Common routine to print scratch regs (r0-r12) or callee regs (r13-r25)
- *   -Prints 3 regs per line and a CR.
- *   -To continue, callee regs right after scratch, special handling of CR
- */
-static noinline void print_reg_file(long *reg_rev, int start_num)
+static noinline void print_regs_scratch(struct pt_regs *regs)
 {
-	unsigned int i;
-	char buf[512];
-	int n = 0, len = sizeof(buf);
-
-	for (i = start_num; i < start_num + 13; i++) {
-		n += scnprintf(buf + n, len - n, "r%02u: 0x%08lx\t",
-			       i, (unsigned long)*reg_rev);
-
-		if (((i + 1) % 3) == 0)
-			n += scnprintf(buf + n, len - n, "\n");
-
-		/* because pt_regs has regs reversed: r12..r0, r25..r13 */
-		if (is_isa_arcv2() && start_num == 0)
-			reg_rev++;
-		else
-			reg_rev--;
-	}
-
-	if (start_num != 0)
-		n += scnprintf(buf + n, len - n, "\n\n");
+	pr_cont("BTA: 0x%08lx\n SP: 0x%08lx  FP: 0x%08lx BLK: %pS\n",
+		regs->bta, regs->sp, regs->fp, (void *)regs->blink);
+	pr_cont("LPS: 0x%08lx\tLPE: 0x%08lx\tLPC: 0x%08lx\n",
+		regs->lp_start, regs->lp_end, regs->lp_count);
 
-	/* To continue printing callee regs on same line as scratch regs */
-	if (start_num == 0)
-		pr_info("%s", buf);
-	else
-		pr_cont("%s\n", buf);
+	pr_info("r00: 0x%08lx\tr01: 0x%08lx\tr02: 0x%08lx\n"	\
+		"r03: 0x%08lx\tr04: 0x%08lx\tr05: 0x%08lx\n"	\
+		"r06: 0x%08lx\tr07: 0x%08lx\tr08: 0x%08lx\n"	\
+		"r09: 0x%08lx\tr10: 0x%08lx\tr11: 0x%08lx\n"	\
+		"r12: 0x%08lx\t",
+		regs->r0, regs->r1, regs->r2,
+		regs->r3, regs->r4, regs->r5,
+		regs->r6, regs->r7, regs->r8,
+		regs->r9, regs->r10, regs->r11,
+		regs->r12);
 }
 
-static void show_callee_regs(struct callee_regs *cregs)
+static void print_regs_callee(struct callee_regs *regs)
 {
-	print_reg_file(&(cregs->r13), 13);
+	pr_cont("r13: 0x%08lx\tr14: 0x%08lx\n"			\
+		"r15: 0x%08lx\tr16: 0x%08lx\tr17: 0x%08lx\n"	\
+		"r18: 0x%08lx\tr19: 0x%08lx\tr20: 0x%08lx\n"	\
+		"r21: 0x%08lx\tr22: 0x%08lx\tr23: 0x%08lx\n"	\
+		"r24: 0x%08lx\tr25: 0x%08lx\n",
+		regs->r13, regs->r14,
+		regs->r15, regs->r16, regs->r17,
+		regs->r18, regs->r19, regs->r20,
+		regs->r21, regs->r22, regs->r23,
+		regs->r24, regs->r25);
 }
 
 static void print_task_path_n_nm(struct task_struct *tsk)

@@ -175,7 +168,7 @@ static void show_ecr_verbose(struct pt_regs *regs)
 void show_regs(struct pt_regs *regs)
 {
 	struct task_struct *tsk = current;
-	struct callee_regs *cregs;
+	struct callee_regs *cregs = (struct callee_regs *)tsk->thread.callee_reg;
 
 	/*
 	 * generic code calls us with preemption disabled, but some calls

@@ -204,25 +197,15 @@ void show_regs(struct pt_regs *regs)
 			STS_BIT(regs, A2), STS_BIT(regs, A1),
 			STS_BIT(regs, E2), STS_BIT(regs, E1));
 #else
-	pr_cont(" [%2s%2s%2s%2s]",
+	pr_cont(" [%2s%2s%2s%2s]   ",
 			STS_BIT(regs, IE),
 			(regs->status32 & STATUS_U_MASK) ? "U " : "K ",
 			STS_BIT(regs, DE), STS_BIT(regs, AE));
 #endif
-	pr_cont("  BTA: 0x%08lx\n  SP: 0x%08lx  FP: 0x%08lx BLK: %pS\n",
-		regs->bta, regs->sp, regs->fp, (void *)regs->blink);
-	pr_info("LPS: 0x%08lx\tLPE: 0x%08lx\tLPC: 0x%08lx\n",
-		regs->lp_start, regs->lp_end, regs->lp_count);
-
-	/* print regs->r0 thru regs->r12
-	 * Sequential printing was generating horrible code
-	 */
-	print_reg_file(&(regs->r0), 0);
 
-	/* If Callee regs were saved, display them too */
-	cregs = (struct callee_regs *)current->thread.callee_reg;
+	print_regs_scratch(regs);
 	if (cregs)
-		show_callee_regs(cregs);
+		print_regs_callee(cregs);
 
 	preempt_disable();
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:33 UTC #92 lore raw

PATCH 81/177 irqchip/eznps: Fix build error for !ARC700 builds

From: Vineet Gupta <[email protected]>

[ Upstream commit 89d29997f103d08264b0685796b420d911658b96 ]

eznps driver is supposed to be platform independent however it ends up including stuff from inside arch/arc headers leading to rand config build errors.

The quick hack to fix this (proper fix is too much chrun for non active user-base) is to add following to nps platform agnostic header.
- copy AUX_IENABLE from arch/arc header
- move CTOP_AUX_IACK from arch/arc/plat-eznps/*/**

Reported-by kernel test robot <[email protected]>

Reported-by Sebastian Andrzej Siewior <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arc/plat-eznps/include/plat/ctop.h | 1 -
 include/soc/nps/common.h                | 6 ++++++
 2 files changed, 6 insertions(+), 1 deletion(-)

arch/arc/plat-eznps/include/plat/ctop.h +0 -1

index a4a61531c7fb9..77712c5ffe848 100644
@@ -33,7 +33,6 @@
 #define CTOP_AUX_DPC				(CTOP_AUX_BASE + 0x02C)
 #define CTOP_AUX_LPC				(CTOP_AUX_BASE + 0x030)
 #define CTOP_AUX_EFLAGS				(CTOP_AUX_BASE + 0x080)
-#define CTOP_AUX_IACK				(CTOP_AUX_BASE + 0x088)
 #define CTOP_AUX_GPA1				(CTOP_AUX_BASE + 0x08C)
 #define CTOP_AUX_UDMC				(CTOP_AUX_BASE + 0x300)

include/soc/nps/common.h +6 -0

index 9b1d43d671a3f..8c18dc6d3fde5 100644
@@ -45,6 +45,12 @@
 #define CTOP_INST_MOV2B_FLIP_R3_B1_B2_INST	0x5B60
 #define CTOP_INST_MOV2B_FLIP_R3_B1_B2_LIMM	0x00010422
 
+#ifndef AUX_IENABLE
+#define AUX_IENABLE				0x40c
+#endif
+
+#define CTOP_AUX_IACK				(0xFFFFF800 + 0x088)
+
 #ifndef __ASSEMBLY__
 
 /* In order to increase compilation test coverage */

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:38 UTC #93 lore raw

PATCH 82/177 media: gpio-ir-tx: spinlock is not needed to disable interrupts

From: Sean Young <[email protected]>

[ Upstream commit 1451b93223bbe3b4e9c91fca6b451d00667c5bf0 ]

During bit-banging the IR on a gpio pin, we cannot be scheduled or have anything interrupt us, else the generated signal will be incorrect. Therefore, we need to disable interrupts on the local cpu. This also disables preemption.

local_irq_disable() does exactly what we need and does not require a spinlock.

Signed-off-by Sean Young <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/media/rc/gpio-ir-tx.c | 16 +++++-----------
 1 file changed, 5 insertions(+), 11 deletions(-)

drivers/media/rc/gpio-ir-tx.c +5 ~~-11~~

index f33b443bfa47b..c6cd2e6d8e654 100644
@@ -19,8 +19,6 @@ struct gpio_ir {
 	struct gpio_desc *gpio;
 	unsigned int carrier;
 	unsigned int duty_cycle;
-	/* we need a spinlock to hold the cpu while transmitting */
-	spinlock_t lock;
 };
 
 static const struct of_device_id gpio_ir_tx_of_match[] = {

@@ -53,12 +51,11 @@ static int gpio_ir_tx_set_carrier(struct rc_dev *dev, u32 carrier)
 static void gpio_ir_tx_unmodulated(struct gpio_ir *gpio_ir, uint *txbuf,
 				   uint count)
 {
-	unsigned long flags;
 	ktime_t edge;
 	s32 delta;
 	int i;
 
-	spin_lock_irqsave(&gpio_ir->lock, flags);
+	local_irq_disable();
 
 	edge = ktime_get();

@@ -72,14 +69,11 @@ static void gpio_ir_tx_unmodulated(struct gpio_ir *gpio_ir, uint *txbuf,
 	}
 
 	gpiod_set_value(gpio_ir->gpio, 0);
-
-	spin_unlock_irqrestore(&gpio_ir->lock, flags);
 }
 
 static void gpio_ir_tx_modulated(struct gpio_ir *gpio_ir, uint *txbuf,
 				 uint count)
 {
-	unsigned long flags;
 	ktime_t edge;
 	/*
 	 * delta should never exceed 0.5 seconds (IR_MAX_DURATION) and on

@@ -95,7 +89,7 @@ static void gpio_ir_tx_modulated(struct gpio_ir *gpio_ir, uint *txbuf,
 	space = DIV_ROUND_CLOSEST((100 - gpio_ir->duty_cycle) *
 				  (NSEC_PER_SEC / 100), gpio_ir->carrier);
 
-	spin_lock_irqsave(&gpio_ir->lock, flags);
+	local_irq_disable();
 
 	edge = ktime_get();

@@ -128,19 +122,20 @@ static void gpio_ir_tx_modulated(struct gpio_ir *gpio_ir, uint *txbuf,
 			edge = last;
 		}
 	}
-
-	spin_unlock_irqrestore(&gpio_ir->lock, flags);
 }
 
 static int gpio_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
 		      unsigned int count)
 {
 	struct gpio_ir *gpio_ir = dev->priv;
+	unsigned long flags;
 
+	local_irq_save(flags);
 	if (gpio_ir->carrier)
 		gpio_ir_tx_modulated(gpio_ir, txbuf, count);
 	else
 		gpio_ir_tx_unmodulated(gpio_ir, txbuf, count);
+	local_irq_restore(flags);
 
 	return count;
 }

@@ -176,7 +171,6 @@ static int gpio_ir_tx_probe(struct platform_device *pdev)
 
 	gpio_ir->carrier = 38000;
 	gpio_ir->duty_cycle = 50;
-	spin_lock_init(&gpio_ir->lock);
 
 	rc = devm_rc_register_device(&pdev->dev, rcdev);
 	if (rc < 0)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:25 UTC #94 lore raw

PATCH 83/177 nvmet-tcp: Fix NULL dereference when a connect data comes in h2cdata pdu

From: Ziye Yang <[email protected]>

[ Upstream commit a6ce7d7b4adaebc27ee7e78e5ecc378a1cfc221d ]

When handling commands without in-capsule data, we assign the ttag assuming we already have the queue commands array allocated (based on the queue size information in the connect data payload). However if the connect itself did not send the connect data in-capsule we have yet to allocate the queue commands,and we will assign a bogus ttag and suffer a NULL dereference when we receive the corresponding h2cdata pdu.

Fix this by checking if we already allocated commands before dereferencing it when handling h2cdata, if we didn't, its for sure a connect and we should use the preallocated connect command.

Signed-off-by Ziye Yang <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/target/tcp.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

drivers/nvme/target/tcp.c +9 -1

index de9217cfd22d7..3d29b773ced27 100644
@@ -160,6 +160,11 @@ static void nvmet_tcp_finish_cmd(struct nvmet_tcp_cmd *cmd);
 static inline u16 nvmet_tcp_cmd_tag(struct nvmet_tcp_queue *queue,
 		struct nvmet_tcp_cmd *cmd)
 {
+	if (unlikely(!queue->nr_cmds)) {
+		/* We didn't allocate cmds yet, send 0xffff */
+		return USHRT_MAX;
+	}
+
 	return cmd - queue->cmds;
 }

@@ -872,7 +877,10 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)
 	struct nvme_tcp_data_pdu *data = &queue->pdu.data;
 	struct nvmet_tcp_cmd *cmd;
 
-	cmd = &queue->cmds[data->ttag];
+	if (likely(queue->nr_cmds))
+		cmd = &queue->cmds[data->ttag];
+	else
+		cmd = &queue->connect;
 
 	if (le32_to_cpu(data->data_offset) != cmd->rbytes_done) {
 		pr_err("ttag %u unexpected data offset %u (expected %u)\n",

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:25 UTC #95 lore raw

PATCH 84/177 nvme-fabrics: dont check state NVME_CTRL_NEW for request acceptance

From: Sagi Grimberg <[email protected]>

[ Upstream commit d7144f5c4cf4de95fdc3422943cf51c06aeaf7a7 ]

NVME_CTRL_NEW should never see any I/O, because in order to start initialization it has to transition to NVME_CTRL_CONNECTING and from there it will never return to this state.

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/fabrics.c | 1 -
 1 file changed, 1 deletion(-)

drivers/nvme/host/fabrics.c +0 -1

index 7799d032bf38b..8575724734e02 100644
@@ -580,7 +580,6 @@ bool __nvmf_check_ready(struct nvme_ctrl *ctrl, struct request *rq,
 	 * which is require to set the queue live in the appropinquate states.
 	 */
 	switch (ctrl->state) {
-	case NVME_CTRL_NEW:
 	case NVME_CTRL_CONNECTING:
 		if (blk_rq_is_passthrough(rq) && nvme_is_fabrics(req->cmd) &&
 		    req->cmd->fabrics.fctype == nvme_fabrics_type_connect)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:39 UTC #96 lore raw

PATCH 85/177 nvme: have nvme_wait_freeze_timeout return if it timed out

From: Sagi Grimberg <[email protected]>

[ Upstream commit 7cf0d7c0f3c3b0203aaf81c1bc884924d8fdb9bd ]

Users can detect if the wait has completed or not and take appropriate actions based on this information (e.g. weather to continue initialization or rather fail and schedule another initialization attempt).

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/core.c | 3 ++-
 drivers/nvme/host/nvme.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

drivers/nvme/host/core.c +2 -1

index fa0039dcacc66..da82ba1896d8d 100644
@@ -4287,7 +4287,7 @@ void nvme_unfreeze(struct nvme_ctrl *ctrl)
 }
 EXPORT_SYMBOL_GPL(nvme_unfreeze);
 
-void nvme_wait_freeze_timeout(struct nvme_ctrl *ctrl, long timeout)
+int nvme_wait_freeze_timeout(struct nvme_ctrl *ctrl, long timeout)
 {
 	struct nvme_ns *ns;

@@ -4298,6 +4298,7 @@ void nvme_wait_freeze_timeout(struct nvme_ctrl *ctrl, long timeout)
 			break;
 	}
 	up_read(&ctrl->namespaces_rwsem);
+	return timeout;
 }
 EXPORT_SYMBOL_GPL(nvme_wait_freeze_timeout);

drivers/nvme/host/nvme.h +1 -1

index e268f1d7e1a0f..c053aedbc55db 100644
@@ -538,7 +538,7 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl);
 void nvme_sync_queues(struct nvme_ctrl *ctrl);
 void nvme_unfreeze(struct nvme_ctrl *ctrl);
 void nvme_wait_freeze(struct nvme_ctrl *ctrl);
-void nvme_wait_freeze_timeout(struct nvme_ctrl *ctrl, long timeout);
+int nvme_wait_freeze_timeout(struct nvme_ctrl *ctrl, long timeout);
 void nvme_start_freeze(struct nvme_ctrl *ctrl);
 
 #define NVME_QID_ANY -1

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:25 UTC #97 lore raw

PATCH 86/177 nvme-tcp: serialize controller teardown sequences

From: Sagi Grimberg <[email protected]>

[ Upstream commit d4d61470ae48838f49e668503e840e1520b97162 ]

In the timeout handler we may need to complete a request because the request that timed out may be an I/O that is a part of a serial sequence of controller teardown or initialization. In order to complete the request, we need to fence any other context that may compete with us and complete the request that is timing out.

In this case, we could have a potential double completion in case a hard-irq or a different competing context triggered error recovery and is running inflight request cancellation concurrently with the timeout handler.

Protect using a ctrl teardown_lock to serialize contexts that may complete a cancelled request due to error recovery or a reset.

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/tcp.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

drivers/nvme/host/tcp.c +9 -2

index a6d2e3330a584..d1e5b27675b1b 100644
@@ -122,6 +122,7 @@ struct nvme_tcp_ctrl {
 	struct sockaddr_storage src_addr;
 	struct nvme_ctrl	ctrl;
 
+	struct mutex		teardown_lock;
 	struct work_struct	err_work;
 	struct delayed_work	connect_work;
 	struct nvme_tcp_request async_req;

@@ -1497,7 +1498,6 @@ static void nvme_tcp_stop_queue(struct nvme_ctrl *nctrl, int qid)
 
 	if (!test_and_clear_bit(NVME_TCP_Q_LIVE, &queue->flags))
 		return;
-
 	__nvme_tcp_stop_queue(queue);
 }

@@ -1845,6 +1845,7 @@ out_free_queue:
 static void nvme_tcp_teardown_admin_queue(struct nvme_ctrl *ctrl,
 		bool remove)
 {
+	mutex_lock(&to_tcp_ctrl(ctrl)->teardown_lock);
 	blk_mq_quiesce_queue(ctrl->admin_q);
 	nvme_tcp_stop_queue(ctrl, 0);
 	if (ctrl->admin_tagset) {

@@ -1855,13 +1856,16 @@ static void nvme_tcp_teardown_admin_queue(struct nvme_ctrl *ctrl,
 	if (remove)
 		blk_mq_unquiesce_queue(ctrl->admin_q);
 	nvme_tcp_destroy_admin_queue(ctrl, remove);
+	mutex_unlock(&to_tcp_ctrl(ctrl)->teardown_lock);
 }
 
 static void nvme_tcp_teardown_io_queues(struct nvme_ctrl *ctrl,
 		bool remove)
 {
+	mutex_lock(&to_tcp_ctrl(ctrl)->teardown_lock);
 	if (ctrl->queue_count <= 1)
-		return;
+		goto out;
+	blk_mq_quiesce_queue(ctrl->admin_q);
 	nvme_start_freeze(ctrl);
 	nvme_stop_queues(ctrl);
 	nvme_tcp_stop_io_queues(ctrl);

@@ -1873,6 +1877,8 @@ static void nvme_tcp_teardown_io_queues(struct nvme_ctrl *ctrl,
 	if (remove)
 		nvme_start_queues(ctrl);
 	nvme_tcp_destroy_io_queues(ctrl, remove);
+out:
+	mutex_unlock(&to_tcp_ctrl(ctrl)->teardown_lock);
 }
 
 static void nvme_tcp_reconnect_or_remove(struct nvme_ctrl *ctrl)

@@ -2384,6 +2390,7 @@ static struct nvme_ctrl *nvme_tcp_create_ctrl(struct device *dev,
 			nvme_tcp_reconnect_ctrl_work);
 	INIT_WORK(&ctrl->err_work, nvme_tcp_error_recovery_work);
 	INIT_WORK(&ctrl->ctrl.reset_work, nvme_reset_ctrl_work);
+	mutex_init(&ctrl->teardown_lock);
 
 	if (!(opts->mask & NVMF_OPT_TRSVCID)) {
 		opts->trsvcid =

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:22 UTC #98 lore raw

PATCH 87/177 nvme-tcp: fix timeout handler

From: Sagi Grimberg <[email protected]>

[ Upstream commit 236187c4ed195161dfa4237c7beffbba0c5ae45b ]

When a request times out in a LIVE state, we simply trigger error recovery and let the error recovery handle the request cancellation, however when a request times out in a non LIVE state, we make sure to complete it immediately as it might block controller setup or teardown and prevent forward progress.

However tearing down the entire set of I/O and admin queues causes freeze/unfreeze imbalance (q->mq_freeze_depth) because and is really an overkill to what we actually need, which is to just fence controller teardown that may be running, stop the queue, and cancel the request if it is not already completed.

Now that we have the controller teardown_lock, we can safely serialize request cancellation. This addresses a hang caused by calling extra queue freeze on controller namespaces, causing unfreeze to not complete correctly.

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/tcp.c | 56 ++++++++++++++++++++++++++---------------
 1 file changed, 36 insertions(+), 20 deletions(-)

drivers/nvme/host/tcp.c +36 ~~-20~~

index d1e5b27675b1b..65a3bad778104 100644
@@ -448,6 +448,7 @@ static void nvme_tcp_error_recovery(struct nvme_ctrl *ctrl)
 	if (!nvme_change_ctrl_state(ctrl, NVME_CTRL_RESETTING))
 		return;
 
+	dev_warn(ctrl->device, "starting error recovery\n");
 	queue_work(nvme_reset_wq, &to_tcp_ctrl(ctrl)->err_work);
 }

@@ -2125,40 +2126,55 @@ static void nvme_tcp_submit_async_event(struct nvme_ctrl *arg)
 	nvme_tcp_queue_request(&ctrl->async_req, true);
 }
 
+static void nvme_tcp_complete_timed_out(struct request *rq)
+{
+	struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
+	struct nvme_ctrl *ctrl = &req->queue->ctrl->ctrl;
+
+	/* fence other contexts that may complete the command */
+	mutex_lock(&to_tcp_ctrl(ctrl)->teardown_lock);
+	nvme_tcp_stop_queue(ctrl, nvme_tcp_queue_id(req->queue));
+	if (!blk_mq_request_completed(rq)) {
+		nvme_req(rq)->status = NVME_SC_HOST_ABORTED_CMD;
+		blk_mq_complete_request(rq);
+	}
+	mutex_unlock(&to_tcp_ctrl(ctrl)->teardown_lock);
+}
+
 static enum blk_eh_timer_return
 nvme_tcp_timeout(struct request *rq, bool reserved)
 {
 	struct nvme_tcp_request *req = blk_mq_rq_to_pdu(rq);
-	struct nvme_tcp_ctrl *ctrl = req->queue->ctrl;
+	struct nvme_ctrl *ctrl = &req->queue->ctrl->ctrl;
 	struct nvme_tcp_cmd_pdu *pdu = req->pdu;
 
-	/*
-	 * Restart the timer if a controller reset is already scheduled. Any
-	 * timed out commands would be handled before entering the connecting
-	 * state.
-	 */
-	if (ctrl->ctrl.state == NVME_CTRL_RESETTING)
-		return BLK_EH_RESET_TIMER;
-
-	dev_warn(ctrl->ctrl.device,
+	dev_warn(ctrl->device,
 		"queue %d: timeout request %#x type %d\n",
 		nvme_tcp_queue_id(req->queue), rq->tag, pdu->hdr.type);
 
-	if (ctrl->ctrl.state != NVME_CTRL_LIVE) {
+	if (ctrl->state != NVME_CTRL_LIVE) {
 		/*
-		 * Teardown immediately if controller times out while starting
-		 * or we are already started error recovery. all outstanding
-		 * requests are completed on shutdown, so we return BLK_EH_DONE.
+		 * If we are resetting, connecting or deleting we should
+		 * complete immediately because we may block controller
+		 * teardown or setup sequence
+		 * - ctrl disable/shutdown fabrics requests
+		 * - connect requests
+		 * - initialization admin requests
+		 * - I/O requests that entered after unquiescing and
+		 *   the controller stopped responding
+		 *
+		 * All other requests should be cancelled by the error
+		 * recovery work, so it's fine that we fail it here.
 		 */
-		flush_work(&ctrl->err_work);
-		nvme_tcp_teardown_io_queues(&ctrl->ctrl, false);
-		nvme_tcp_teardown_admin_queue(&ctrl->ctrl, false);
+		nvme_tcp_complete_timed_out(rq);
 		return BLK_EH_DONE;
 	}
 
-	dev_warn(ctrl->ctrl.device, "starting error recovery\n");
-	nvme_tcp_error_recovery(&ctrl->ctrl);
-
+	/*
+	 * LIVE state should trigger the normal error recovery which will
+	 * handle completing this request.
+	 */
+	nvme_tcp_error_recovery(ctrl);
 	return BLK_EH_RESET_TIMER;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:21 UTC #99 lore raw

PATCH 88/177 nvme-tcp: fix reset hang if controller died in the middle of a reset

From: Sagi Grimberg <[email protected]>

[ Upstream commit e5c01f4f7f623e768e868bcc08d8e7ceb03b75d0 ]

If the controller becomes unresponsive in the middle of a reset, we will hang because we are waiting for the freeze to complete, but that cannot happen since we have commands that are inflight holding the q_usage_counter, and we can't blindly fail requests that times out.

So give a timeout and if we cannot wait for queue freeze before unfreezing, fail and have the error handling take care how to proceed (either schedule a reconnect of remove the controller).

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/tcp.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

drivers/nvme/host/tcp.c +12 -1

index 65a3bad778104..f1f66bf96cbb9 100644
@@ -1753,7 +1753,15 @@ static int nvme_tcp_configure_io_queues(struct nvme_ctrl *ctrl, bool new)
 
 	if (!new) {
 		nvme_start_queues(ctrl);
-		nvme_wait_freeze(ctrl);
+		if (!nvme_wait_freeze_timeout(ctrl, NVME_IO_TIMEOUT)) {
+			/*
+			 * If we timed out waiting for freeze we are likely to
+			 * be stuck.  Fail the controller initialization just
+			 * to be safe.
+			 */
+			ret = -ENODEV;
+			goto out_wait_freeze_timed_out;
+		}
 		blk_mq_update_nr_hw_queues(ctrl->tagset,
 			ctrl->queue_count - 1);
 		nvme_unfreeze(ctrl);

@@ -1761,6 +1769,9 @@ static int nvme_tcp_configure_io_queues(struct nvme_ctrl *ctrl, bool new)
 
 	return 0;
 
+out_wait_freeze_timed_out:
+	nvme_stop_queues(ctrl);
+	nvme_tcp_stop_io_queues(ctrl);
 out_cleanup_connect_q:
 	if (new)
 		blk_cleanup_queue(ctrl->connect_q);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:20 UTC #100 lore raw

PATCH 89/177 nvme-rdma: serialize controller teardown sequences

From: Sagi Grimberg <[email protected]>

[ Upstream commit 5110f40241d08334375eb0495f174b1d2c07657e ]

Protect using a ctrl teardown_lock to serialize contexts that may complete a cancelled request due to error recovery or a reset.

Reviewed-by James Smart <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/rdma.c | 6 ++++++
 1 file changed, 6 insertions(+)

drivers/nvme/host/rdma.c +6 -0

index 876859cd14e86..ffe83d1f576bf 100644
@@ -121,6 +121,7 @@ struct nvme_rdma_ctrl {
 	struct sockaddr_storage src_addr;
 
 	struct nvme_ctrl	ctrl;
+	struct mutex		teardown_lock;
 	bool			use_inline_data;
 	u32			io_queues[HCTX_MAX_TYPES];
 };

@@ -971,6 +972,7 @@ out_free_io_queues:
 static void nvme_rdma_teardown_admin_queue(struct nvme_rdma_ctrl *ctrl,
 		bool remove)
 {
+	mutex_lock(&ctrl->teardown_lock);
 	blk_mq_quiesce_queue(ctrl->ctrl.admin_q);
 	nvme_rdma_stop_queue(&ctrl->queues[0]);
 	if (ctrl->ctrl.admin_tagset) {

@@ -981,11 +983,13 @@ static void nvme_rdma_teardown_admin_queue(struct nvme_rdma_ctrl *ctrl,
 	if (remove)
 		blk_mq_unquiesce_queue(ctrl->ctrl.admin_q);
 	nvme_rdma_destroy_admin_queue(ctrl, remove);
+	mutex_unlock(&ctrl->teardown_lock);
 }
 
 static void nvme_rdma_teardown_io_queues(struct nvme_rdma_ctrl *ctrl,
 		bool remove)
 {
+	mutex_lock(&ctrl->teardown_lock);
 	if (ctrl->ctrl.queue_count > 1) {
 		nvme_start_freeze(&ctrl->ctrl);
 		nvme_stop_queues(&ctrl->ctrl);

@@ -999,6 +1003,7 @@ static void nvme_rdma_teardown_io_queues(struct nvme_rdma_ctrl *ctrl,
 			nvme_start_queues(&ctrl->ctrl);
 		nvme_rdma_destroy_io_queues(ctrl, remove);
 	}
+	mutex_unlock(&ctrl->teardown_lock);
 }
 
 static void nvme_rdma_free_ctrl(struct nvme_ctrl *nctrl)

@@ -2252,6 +2257,7 @@ static struct nvme_ctrl *nvme_rdma_create_ctrl(struct device *dev,
 		return ERR_PTR(-ENOMEM);
 	ctrl->ctrl.opts = opts;
 	INIT_LIST_HEAD(&ctrl->list);
+	mutex_init(&ctrl->teardown_lock);
 
 	if (!(opts->mask & NVMF_OPT_TRSVCID)) {
 		opts->trsvcid =

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:20 UTC #101 lore raw

PATCH 90/177 nvme-rdma: fix timeout handler

From: Sagi Grimberg <[email protected]>

[ Upstream commit 0475a8dcbcee92a5d22e40c9c6353829fc6294b8 ]

Reviewed-by James Smart <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/rdma.c | 49 +++++++++++++++++++++++++++-------------
 1 file changed, 33 insertions(+), 16 deletions(-)

drivers/nvme/host/rdma.c +33 ~~-16~~

index ffe83d1f576bf..99bf88eb812c5 100644
@@ -1159,6 +1159,7 @@ static void nvme_rdma_error_recovery(struct nvme_rdma_ctrl *ctrl)
 	if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_RESETTING))
 		return;
 
+	dev_warn(ctrl->ctrl.device, "starting error recovery\n");
 	queue_work(nvme_reset_wq, &ctrl->err_work);
 }

@@ -1925,6 +1926,22 @@ static int nvme_rdma_cm_handler(struct rdma_cm_id *cm_id,
 	return 0;
 }
 
+static void nvme_rdma_complete_timed_out(struct request *rq)
+{
+	struct nvme_rdma_request *req = blk_mq_rq_to_pdu(rq);
+	struct nvme_rdma_queue *queue = req->queue;
+	struct nvme_rdma_ctrl *ctrl = queue->ctrl;
+
+	/* fence other contexts that may complete the command */
+	mutex_lock(&ctrl->teardown_lock);
+	nvme_rdma_stop_queue(queue);
+	if (!blk_mq_request_completed(rq)) {
+		nvme_req(rq)->status = NVME_SC_HOST_ABORTED_CMD;
+		blk_mq_complete_request(rq);
+	}
+	mutex_unlock(&ctrl->teardown_lock);
+}
+
 static enum blk_eh_timer_return
 nvme_rdma_timeout(struct request *rq, bool reserved)
 {

@@ -1935,29 +1952,29 @@ nvme_rdma_timeout(struct request *rq, bool reserved)
 	dev_warn(ctrl->ctrl.device, "I/O %d QID %d timeout\n",
 		 rq->tag, nvme_rdma_queue_idx(queue));
 
-	/*
-	 * Restart the timer if a controller reset is already scheduled. Any
-	 * timed out commands would be handled before entering the connecting
-	 * state.
-	 */
-	if (ctrl->ctrl.state == NVME_CTRL_RESETTING)
-		return BLK_EH_RESET_TIMER;
-
 	if (ctrl->ctrl.state != NVME_CTRL_LIVE) {
 		/*
-		 * Teardown immediately if controller times out while starting
-		 * or we are already started error recovery. all outstanding
-		 * requests are completed on shutdown, so we return BLK_EH_DONE.
+		 * If we are resetting, connecting or deleting we should
+		 * complete immediately because we may block controller
+		 * teardown or setup sequence
+		 * - ctrl disable/shutdown fabrics requests
+		 * - connect requests
+		 * - initialization admin requests
+		 * - I/O requests that entered after unquiescing and
+		 *   the controller stopped responding
+		 *
+		 * All other requests should be cancelled by the error
+		 * recovery work, so it's fine that we fail it here.
 		 */
-		flush_work(&ctrl->err_work);
-		nvme_rdma_teardown_io_queues(ctrl, false);
-		nvme_rdma_teardown_admin_queue(ctrl, false);
+		nvme_rdma_complete_timed_out(rq);
 		return BLK_EH_DONE;
 	}
 
-	dev_warn(ctrl->ctrl.device, "starting error recovery\n");
+	/*
+	 * LIVE state should trigger the normal error recovery which will
+	 * handle completing this request.
+	 */
 	nvme_rdma_error_recovery(ctrl);
-
 	return BLK_EH_RESET_TIMER;
 }

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:19 UTC #102 lore raw

PATCH 91/177 nvme-rdma: fix reset hang if controller died in the middle of a reset

From: Sagi Grimberg <[email protected]>

[ Upstream commit 2362acb6785611eda795bfc12e1ea6b202ecf62c ]

So give a timeout and if we cannot wait for queue freeze before unfreezing, fail and have the error handling take care how to proceed (either schedule a reconnect of remove the controller).

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/rdma.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

drivers/nvme/host/rdma.c +12 -1

index 99bf88eb812c5..6c07bb55b0f83 100644
@@ -950,7 +950,15 @@ static int nvme_rdma_configure_io_queues(struct nvme_rdma_ctrl *ctrl, bool new)
 
 	if (!new) {
 		nvme_start_queues(&ctrl->ctrl);
-		nvme_wait_freeze(&ctrl->ctrl);
+		if (!nvme_wait_freeze_timeout(&ctrl->ctrl, NVME_IO_TIMEOUT)) {
+			/*
+			 * If we timed out waiting for freeze we are likely to
+			 * be stuck.  Fail the controller initialization just
+			 * to be safe.
+			 */
+			ret = -ENODEV;
+			goto out_wait_freeze_timed_out;
+		}
 		blk_mq_update_nr_hw_queues(ctrl->ctrl.tagset,
 			ctrl->ctrl.queue_count - 1);
 		nvme_unfreeze(&ctrl->ctrl);

@@ -958,6 +966,9 @@ static int nvme_rdma_configure_io_queues(struct nvme_rdma_ctrl *ctrl, bool new)
 
 	return 0;
 
+out_wait_freeze_timed_out:
+	nvme_stop_queues(&ctrl->ctrl);
+	nvme_rdma_stop_io_queues(ctrl);
 out_cleanup_connect_q:
 	if (new)
 		blk_cleanup_queue(ctrl->ctrl.connect_q);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:19 UTC #103 lore raw

PATCH 92/177 nvme-pci: cancel nvme device request before disabling

From: Tong Zhang <[email protected]>

[ Upstream commit 7ad92f656bddff4cf8f641e0e3b1acd4eb9644cb ]

This patch addresses an irq free warning and null pointer dereference error problem when nvme devices got timeout error during initialization. This problem happens when nvme_timeout() function is called while nvme_reset_work() is still in execution. This patch fixed the problem by setting flag of the problematic request to NVME_REQ_CANCELLED before calling nvme_dev_disable() to make sure __nvme_submit_sync_cmd() returns an error code and let nvme_submit_sync_cmd() fail gracefully. The following is console output.

[   62.472097] nvme nvme0: I/O 13 QID 0 timeout, disable controller
[   62.488796] nvme nvme0: could not set timestamp (881)
[   62.494888] ------------[ cut here ]------------
[   62.495142] Trying to free already-free IRQ 11
[   62.495366] WARNING: CPU: 0 PID: 7 at kernel/irq/manage.c:1751 free_irq+0x1f7/0x370
[   62.495742] Modules linked in:
[   62.495902] CPU: 0 PID: 7 Comm: kworker/u4:0 Not tainted 5.8.0+ #8
[   62.496206] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-p4
[   62.496772] Workqueue: nvme-reset-wq nvme_reset_work
[   62.497019] RIP: 0010:free_irq+0x1f7/0x370
[   62.497223] Code: e8 ce 49 11 00 48 83 c4 08 4c 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 44 89 f6 48 c70
[   62.498133] RSP: 0000:ffffa96800043d40 EFLAGS: 00010086
[   62.498391] RAX: 0000000000000000 RBX: ffff9b87fc458400 RCX: 0000000000000000
[   62.498741] RDX: 0000000000000001 RSI: 0000000000000096 RDI: ffffffff9693d72c
[   62.499091] RBP: ffff9b87fd4c8f60 R08: ffffa96800043bfd R09: 0000000000000163
[   62.499440] R10: ffffa96800043bf8 R11: ffffa96800043bfd R12: ffff9b87fd4c8e00
[   62.499790] R13: ffff9b87fd4c8ea4 R14: 000000000000000b R15: ffff9b87fd76b000
[   62.500140] FS:  0000000000000000(0000) GS:ffff9b87fdc00000(0000) knlGS:0000000000000000
[   62.500534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   62.500816] CR2: 0000000000000000 CR3: 000000003aa0a000 CR4: 00000000000006f0
[   62.501165] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   62.501515] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   62.501864] Call Trace:
[   62.501993]  pci_free_irq+0x13/0x20
[   62.502167]  nvme_reset_work+0x5d0/0x12a0
[   62.502369]  ? update_load_avg+0x59/0x580
[   62.502569]  ? ttwu_queue_wakelist+0xa8/0xc0
[   62.502780]  ? try_to_wake_up+0x1a2/0x450
[   62.502979]  process_one_work+0x1d2/0x390
[   62.503179]  worker_thread+0x45/0x3b0
[   62.503361]  ? process_one_work+0x390/0x390
[   62.503568]  kthread+0xf9/0x130
[   62.503726]  ? kthread_park+0x80/0x80
[   62.503911]  ret_from_fork+0x22/0x30
[   62.504090] ---[ end trace de9ed4a70f8d71e2 ]---
[  123.912275] nvme nvme0: I/O 12 QID 0 timeout, disable controller
[  123.914670] nvme nvme0: 1/0/0 default/read/poll queues
[  123.916310] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  123.917469] #PF: supervisor write access in kernel mode
[  123.917725] #PF: error_code(0x0002) - not-present page
[  123.917976] PGD 0 P4D 0
[  123.918109] Oops: 0002 [#1] SMP PTI
[  123.918283] CPU: 0 PID: 7 Comm: kworker/u4:0 Tainted: G        W         5.8.0+ #8
[  123.918650] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-p4
[  123.919219] Workqueue: nvme-reset-wq nvme_reset_work
[  123.919469] RIP: 0010:__blk_mq_alloc_map_and_request+0x21/0x80
[  123.919757] Code: 66 0f 1f 84 00 00 00 00 00 41 55 41 54 55 48 63 ee 53 48 8b 47 68 89 ee 48 89 fb 8b4
[  123.920657] RSP: 0000:ffffa96800043d40 EFLAGS: 00010286
[  123.920912] RAX: ffff9b87fc4fee40 RBX: ffff9b87fc8cb008 RCX: 0000000000000000
[  123.921258] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9b87fc618000
[  123.921602] RBP: 0000000000000000 R08: ffff9b87fdc2c4a0 R09: ffff9b87fc616000
[  123.921949] R10: 0000000000000000 R11: ffff9b87fffd1500 R12: 0000000000000000
[  123.922295] R13: 0000000000000000 R14: ffff9b87fc8cb200 R15: ffff9b87fc8cb000
[  123.922641] FS:  0000000000000000(0000) GS:ffff9b87fdc00000(0000) knlGS:0000000000000000
[  123.923032] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  123.923312] CR2: 0000000000000000 CR3: 000000003aa0a000 CR4: 00000000000006f0
[  123.923660] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  123.924007] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  123.924353] Call Trace:
[  123.924479]  blk_mq_alloc_tag_set+0x137/0x2a0
[  123.924694]  nvme_reset_work+0xed6/0x12a0
[  123.924898]  process_one_work+0x1d2/0x390
[  123.925099]  worker_thread+0x45/0x3b0
[  123.925280]  ? process_one_work+0x390/0x390
[  123.925486]  kthread+0xf9/0x130
[  123.925642]  ? kthread_park+0x80/0x80
[  123.925825]  ret_from_fork+0x22/0x30
[  123.926004] Modules linked in:
[  123.926158] CR2: 0000000000000000
[  123.926322] ---[ end trace de9ed4a70f8d71e3 ]---
[  123.926549] RIP: 0010:__blk_mq_alloc_map_and_request+0x21/0x80
[  123.926832] Code: 66 0f 1f 84 00 00 00 00 00 41 55 41 54 55 48 63 ee 53 48 8b 47 68 89 ee 48 89 fb 8b4
[  123.927734] RSP: 0000:ffffa96800043d40 EFLAGS: 00010286
[  123.927989] RAX: ffff9b87fc4fee40 RBX: ffff9b87fc8cb008 RCX: 0000000000000000
[  123.928336] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9b87fc618000
[  123.928679] RBP: 0000000000000000 R08: ffff9b87fdc2c4a0 R09: ffff9b87fc616000
[  123.929025] R10: 0000000000000000 R11: ffff9b87fffd1500 R12: 0000000000000000
[  123.929370] R13: 0000000000000000 R14: ffff9b87fc8cb200 R15: ffff9b87fc8cb000
[  123.929715] FS:  0000000000000000(0000) GS:ffff9b87fdc00000(0000) knlGS:0000000000000000
[  123.930106] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  123.930384] CR2: 0000000000000000 CR3: 000000003aa0a000 CR4: 00000000000006f0
[  123.930731] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  123.931077] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Co-developed-by Keith Busch <[email protected]>

Signed-off-by Tong Zhang <[email protected]>

Reviewed-by Keith Busch <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/nvme/host/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/nvme/host/pci.c +2 -2

index d4b1ff7471231..69a19fe241063 100644
@@ -1250,8 +1250,8 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
 		dev_warn_ratelimited(dev->ctrl.device,
 			 "I/O %d QID %d timeout, disable controller\n",
 			 req->tag, nvmeq->qid);
-		nvme_dev_disable(dev, true);
 		nvme_req(req)->flags |= NVME_REQ_CANCELLED;
+		nvme_dev_disable(dev, true);
 		return BLK_EH_DONE;
 	case NVME_CTRL_RESETTING:
 		return BLK_EH_RESET_TIMER;

@@ -1268,10 +1268,10 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)
 		dev_warn(dev->ctrl.device,
 			 "I/O %d QID %d timeout, reset controller\n",
 			 req->tag, nvmeq->qid);
+		nvme_req(req)->flags |= NVME_REQ_CANCELLED;
 		nvme_dev_disable(dev, false);
 		nvme_reset_ctrl(&dev->ctrl);
 
-		nvme_req(req)->flags |= NVME_REQ_CANCELLED;
 		return BLK_EH_DONE;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:40 UTC #104 lore raw

PATCH 93/177 HID: quirks: Set INCREMENT_USAGE_ON_DUPLICATE for all Saitek X52 devices

From: Nirenjan Krishnan <[email protected]>

[ Upstream commit 77df710ba633dfb6c65c65cf99ea9e084a1c9933 ]

The Saitek X52 family of joysticks has a pair of axes that were originally (by the Windows driver) used as mouse pointer controls. The corresponding usage page is the Game Controls page, which is not recognized by the generic HID driver, and therefore, both axes get mapped to ABS_MISC. The quirk makes the second axis get mapped to ABS_MISC+1, and therefore made available separately.

One Saitek X52 device is already fixed. This patch fixes the other two known devices with VID/PID 06a3:0255 and 06a3:0762.

Signed-off-by Nirenjan Krishnan <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hid/hid-ids.h    | 2 ++
 drivers/hid/hid-quirks.c | 2 ++
 2 files changed, 4 insertions(+)

drivers/hid/hid-ids.h +2 -0

index 6ea3619842d8d..8fa034b3b7073 100644
@@ -1014,6 +1014,8 @@
 #define USB_DEVICE_ID_SAITEK_RAT9	0x0cfa
 #define USB_DEVICE_ID_SAITEK_MMO7	0x0cd0
 #define USB_DEVICE_ID_SAITEK_X52	0x075c
+#define USB_DEVICE_ID_SAITEK_X52_2	0x0255
+#define USB_DEVICE_ID_SAITEK_X52_PRO	0x0762
 
 #define USB_VENDOR_ID_SAMSUNG		0x0419
 #define USB_DEVICE_ID_SAMSUNG_IR_REMOTE	0x0001

drivers/hid/hid-quirks.c +2 -0

index a65aef6a322fb..7a2be0205dfd1 100644
@@ -150,6 +150,8 @@ static const struct hid_device_id hid_quirks[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_RETROUSB, USB_DEVICE_ID_RETROUSB_SNES_RETROPORT), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD), HID_QUIRK_BADPAD },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52_2), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_X52_PRO), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD2), HID_QUIRK_NO_INIT_REPORTS },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SEMICO, USB_DEVICE_ID_SEMICO_USB_KEYKOARD), HID_QUIRK_NO_INIT_REPORTS },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_SENNHEISER, USB_DEVICE_ID_SENNHEISER_BTD500USB), HID_QUIRK_NOGET },

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:39 UTC #105 lore raw

PATCH 94/177 HID: microsoft: Add rumble support for the 8bitdo SN30 Pro+ controller

From: Nicholas Miell <[email protected]>

[ Upstream commit 724a419ea28f7514a391e80040230f69cf626707 ]

When operating in XInput mode, the 8bitdo SN30 Pro+ requires the same quirk as the official Xbox One Bluetooth controllers for rumble to function.

Other controllers like the N30 Pro 2, SF30 Pro, SN30 Pro, etc. probably also need this quirk, but I do not have the hardware to test.

Signed-off-by Nicholas Miell <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hid/hid-ids.h       | 1 +
 drivers/hid/hid-microsoft.c | 2 ++
 2 files changed, 3 insertions(+)

drivers/hid/hid-ids.h +1 -0

index 8fa034b3b7073..b49ec7dde6457 100644
@@ -849,6 +849,7 @@
 #define USB_DEVICE_ID_MS_POWER_COVER     0x07da
 #define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER	0x02fd
 #define USB_DEVICE_ID_MS_PIXART_MOUSE    0x00cb
+#define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS      0x02e0
 
 #define USB_VENDOR_ID_MOJO		0x8282
 #define USB_DEVICE_ID_RETRO_ADAPTER	0x3201

drivers/hid/hid-microsoft.c +2 -0

index 2d8b589201a4e..8cb1ca1936e42 100644
@@ -451,6 +451,8 @@ static const struct hid_device_id ms_devices[] = {
 		.driver_data = MS_SURFACE_DIAL },
 	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER),
 		.driver_data = MS_QUIRK_FF },
+	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS),
+		.driver_data = MS_QUIRK_FF },
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, ms_devices);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:24 UTC #106 lore raw

PATCH 95/177 drivers/net/wan/hdlc_cisco: Add hard_header_len

From: Xie He <[email protected]>

[ Upstream commit 1a545ebe380bf4c1433e3c136e35a77764fda5ad ]

This driver didn't set hard_header_len. This patch sets hard_header_len for it according to its header_ops->create function.

This driver's header_ops->create function (cisco_hard_header) creates a header of (struct hdlc_header), so hard_header_len should be set to sizeof(struct hdlc_header).

Cc Martin Schiller <[email protected]>

Signed-off-by Xie He <[email protected]>

Acked-by Krzysztof Halasa <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wan/hdlc_cisco.c | 1 +
 1 file changed, 1 insertion(+)

drivers/net/wan/hdlc_cisco.c +1 -0

index d8cba3625c185..444130655d8ea 100644
@@ -370,6 +370,7 @@ static int cisco_ioctl(struct net_device *dev, struct ifreq *ifr)
 		memcpy(&state(hdlc)->settings, &new_settings, size);
 		spin_lock_init(&state(hdlc)->lock);
 		dev->header_ops = &cisco_header_ops;
+		dev->hard_header_len = sizeof(struct hdlc_header);
 		dev->type = ARPHRD_CISCO;
 		call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev);
 		netif_dormant_on(dev);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:24 UTC #107 lore raw

PATCH 96/177 HID: elan: Fix memleak in elan_input_configured

From: Dinghao Liu <[email protected]>

[ Upstream commit b7429ea53d6c0936a0f10a5d64164f0aea440143 ]

When input_mt_init_slots() fails, input should be freed to prevent memleak. When input_register_device() fails, we should call input_mt_destroy_slots() to free memory allocated by input_mt_init_slots().

Signed-off-by Dinghao Liu <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/hid/hid-elan.c | 2 ++
 1 file changed, 2 insertions(+)

drivers/hid/hid-elan.c +2 -0

index 45c4f888b7c4e..dae193749d443 100644
@@ -188,6 +188,7 @@ static int elan_input_configured(struct hid_device *hdev, struct hid_input *hi)
 	ret = input_mt_init_slots(input, ELAN_MAX_FINGERS, INPUT_MT_POINTER);
 	if (ret) {
 		hid_err(hdev, "Failed to init elan MT slots: %d\n", ret);
+		input_free_device(input);
 		return ret;
 	}

@@ -198,6 +199,7 @@ static int elan_input_configured(struct hid_device *hdev, struct hid_input *hi)
 	if (ret) {
 		hid_err(hdev, "Failed to register elan input device: %d\n",
 			ret);
+		input_mt_destroy_slots(input);
 		input_free_device(input);
 		return ret;
 	}

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:24 UTC #108 lore raw

PATCH 97/177 ARC: [plat-hsdk]: Switch ethernet phy-mode to rgmii-id

From: Evgeniy Didin <[email protected]>

[ Upstream commit 26907eb605fbc3ba9dbf888f21d9d8d04471271d ]

HSDK board has Micrel KSZ9031, recent commit
bcf3440c6dd ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") caused a breakdown of Ethernet.
Using 'phy-mode = "rgmii"' is not correct because accodring RGMII specification it is necessary to have delay on RX (PHY to MAX) which is not generated in case of "rgmii".
Using "rgmii-id" adds necessary delay and solves the issue.

Also adding name of PHY placed on HSDK board.

Signed-off-by Evgeniy Didin <[email protected]>

Cc Eugeniy Paltsev <[email protected]>

Cc Alexey Brodkin <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arc/boot/dts/hsdk.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arc/boot/dts/hsdk.dts +2 -2

index 5d64a5a940ee6..dcaa44e408ace 100644
@@ -210,7 +210,7 @@
 			reg = <0x8000 0x2000>;
 			interrupts = <10>;
 			interrupt-names = "macirq";
-			phy-mode = "rgmii";
+			phy-mode = "rgmii-id";
 			snps,pbl = <32>;
 			snps,multicast-filter-bins = <256>;
 			clocks = <&gmacclk>;

@@ -228,7 +228,7 @@
 				#address-cells = <1>;
 				#size-cells = <0>;
 				compatible = "snps,dwmac-mdio";
-				phy0: ethernet-phy@0 {
+				phy0: ethernet-phy@0 { /* Micrel KSZ9031 */
 					reg = <0>;
 				};
 			};

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:23 UTC #109 lore raw

PATCH 98/177 cpufreq: intel_pstate: Refuse to turn off with HWP enabled

From: Rafael J. Wysocki <[email protected]>

[ Upstream commit 43298db3009f06fe5c69e1ca8b6cfc2565772fa1 ]

After commit f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") it is possible to change the driver status to "off" via sysfs with HWP enabled, which effectively causes the driver to unregister itself, but HWP remains active and it forces the minimum performance, so even if another cpufreq driver is loaded, it will not be able to control the CPU frequency.

For this reason, make the driver refuse to change the status to "off" with HWP enabled.

Signed-off-by Rafael J. Wysocki <[email protected]>

Acked-by Srinivas Pandruvada <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/cpufreq/intel_pstate.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

drivers/cpufreq/intel_pstate.c +9 -3

index 8c730a47e0537..97ed4fd0f1342 100644
@@ -2534,9 +2534,15 @@ static int intel_pstate_update_status(const char *buf, size_t size)
 {
 	int ret;
 
-	if (size == 3 && !strncmp(buf, "off", size))
-		return intel_pstate_driver ?
-			intel_pstate_unregister_driver() : -EINVAL;
+	if (size == 3 && !strncmp(buf, "off", size)) {
+		if (!intel_pstate_driver)
+			return -EINVAL;
+
+		if (hwp_active)
+			return -EBUSY;
+
+		return intel_pstate_unregister_driver();
+	}
 
 	if (size == 6 && !strncmp(buf, "active", size)) {
 		if (intel_pstate_driver) {

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:23 UTC #110 lore raw

PATCH 99/177 cpufreq: intel_pstate: Fix intel_pstate_get_hwp_max() for turbo disabled

From: Francisco Jerez <[email protected]>

[ Upstream commit eacc9c5a927e474c173a5d53dd7fb8e306511768 ]

This fixes the behavior of the scaling_max_freq and scaling_min_freq sysfs files in systems which had turbo disabled by the BIOS.

Caleb noticed that the HWP is programmed to operate in the wrong P-state range on his system when the CPUFREQ policy min/max frequency is set via sysfs. This seems to be because in his system intel_pstate_get_hwp_max() is returning the maximum turbo P-state even though turbo was disabled by the BIOS, which causes intel_pstate to scale kHz frequencies incorrectly e.g. setting the maximum turbo frequency whenever the maximum guaranteed frequency is requested via sysfs.

Tested-by Caleb Callaway <[email protected]>

Signed-off-by Francisco Jerez <[email protected]>

Acked-by Srinivas Pandruvada <[email protected]>

[ rjw: Minor subject edits ]

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/cpufreq/intel_pstate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/cpufreq/intel_pstate.c +1 -1

index 97ed4fd0f1342..36a469150ff9c 100644
@@ -762,7 +762,7 @@ static void intel_pstate_get_hwp_max(unsigned int cpu, int *phy_max,
 
 	rdmsrl_on_cpu(cpu, MSR_HWP_CAPABILITIES, &cap);
 	WRITE_ONCE(all_cpu_data[cpu]->hwp_cap_cached, cap);
-	if (global.no_turbo)
+	if (global.no_turbo || global.turbo_disabled)
 		*current_max = HWP_GUARANTEED_PERF(cap);
 	else
 		*current_max = HWP_HIGHEST_PERF(cap);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:39 UTC #111 lore raw

PATCH 100/177 arm64/module: set trampoline section flags regardless of CONFIG_DYNAMIC_FTRACE

Link http://lore.kernel.org/r/20200831094651.GA16385@linux-8ccs open here

From: Jessica Yu <[email protected]>

[ Upstream commit e0328feda79d9681b3e3245e6e180295550c8ee9 ]

In the arm64 module linker script, the section .text.ftrace_trampoline is specified unconditionally regardless of whether CONFIG_DYNAMIC_FTRACE is enabled (this is simply due to the limitation that module linker scripts are not preprocessed like the vmlinux one).

Normally, for .plt and .text.ftrace_trampoline, the section flags present in the module binary wouldn't matter since module_frob_arch_sections() would assign them manually anyway. However, the arm64 module loader only sets the section flags for .text.ftrace_trampoline when CONFIG_DYNAMIC_FTRACE=y. That's only become problematic recently due to a recent change in binutils-2.35, where the .text.ftrace_trampoline section (along with the .plt section) is now marked writable and executable (WAX).

We no longer allow writable and executable sections to be loaded due to commit 5c3a7db0c7ec ("module: Harden STRICT_MODULE_RWX"), so this is causing all modules linked with binutils-2.35 to be rejected under arm64. Drop the IS_ENABLED(CONFIG_DYNAMIC_FTRACE) check in module_frob_arch_sections() so that the section flags for .text.ftrace_trampoline get properly set to SHF_EXECINSTR|SHF_ALLOC, without SHF_WRITE.

Signed-off-by Jessica Yu <[email protected]>

Acked-by Will Deacon <[email protected]>

Acked-by Ard Biesheuvel <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Catalin Marinas <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 arch/arm64/kernel/module-plts.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

arch/arm64/kernel/module-plts.c +1 -2

index 65b08a74aec65..37c0b51a7b7b5 100644
@@ -271,8 +271,7 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
 			mod->arch.core.plt_shndx = i;
 		else if (!strcmp(secstrings + sechdrs[i].sh_name, ".init.plt"))
 			mod->arch.init.plt_shndx = i;
-		else if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE) &&
-			 !strcmp(secstrings + sechdrs[i].sh_name,
+		else if (!strcmp(secstrings + sechdrs[i].sh_name,
 				 ".text.ftrace_trampoline"))
 			tramp = sechdrs + i;
 		else if (sechdrs[i].sh_type == SHT_SYMTAB)

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 14:39 UTC #112 lore raw

PATCH 101/177 ALSA: hda: hdmi - add Rocketlake support

From: Rander Wang <[email protected]>

[ Upstream commit f804a324a41a880c1ab43cc5145d8b3e5790430d ]

Add Rocketlake HDMI codec support. Rocketlake shares the pin-to-port mapping table with Tigerlake.

Signed-off-by Rander Wang <[email protected]>

Reviewed-by Pierre-Louis Bossart <[email protected]>

Reviewed-by Ranjani Sridharan <[email protected]>

Signed-off-by Kai Vehmanen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 sound/pci/hda/patch_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

sound/pci/hda/patch_hdmi.c +1 -0

index bde3b3a169eb2..419f012b9853c 100644
@@ -4205,6 +4205,7 @@ HDA_CODEC_ENTRY(0x8086280c, "Cannonlake HDMI",	patch_i915_glk_hdmi),
 HDA_CODEC_ENTRY(0x8086280d, "Geminilake HDMI",	patch_i915_glk_hdmi),
 HDA_CODEC_ENTRY(0x8086280f, "Icelake HDMI",	patch_i915_icl_hdmi),
 HDA_CODEC_ENTRY(0x80862812, "Tigerlake HDMI",	patch_i915_tgl_hdmi),
+HDA_CODEC_ENTRY(0x80862816, "Rocketlake HDMI",	patch_i915_tgl_hdmi),
 HDA_CODEC_ENTRY(0x8086281a, "Jasperlake HDMI",	patch_i915_icl_hdmi),
 HDA_CODEC_ENTRY(0x8086281b, "Elkhartlake HDMI",	patch_i915_icl_hdmi),
 HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI",	patch_generic_hdmi),

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:22 UTC #113 lore raw

PATCH 102/177 ALSA: hda: fix a runtime pm issue in SOF when integrated GPU is disabled

From: Rander Wang <[email protected]>

[ Upstream commit 13774d81f38538c5fa2924bdcdfa509155480fa6 ]

In snd_hdac_device_init pm_runtime_set_active is called to increase child_count in parent device. But when it is failed to build connection with GPU for one case that integrated graphic gpu is disabled, snd_hdac_ext_bus_device_exit will be invoked to clean up a HD-audio extended codec base device. At this time the child_count of parent is not decreased, which makes parent device can't get suspended.

This patch calls pm_runtime_set_suspended to decrease child_count in parent device in snd_hdac_device_exit to match with snd_hdac_device_init. pm_runtime_set_suspended can make sure that it will not decrease child_count if the device is already suspended.

Signed-off-by Rander Wang <[email protected]>

Reviewed-by Ranjani Sridharan <[email protected]>

Reviewed-by Pierre-Louis Bossart <[email protected]>

Reviewed-by Bard Liao <[email protected]>

Reviewed-by Guennadi Liakhovetski <[email protected]>

Signed-off-by Kai Vehmanen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 sound/hda/hdac_device.c | 2 ++
 1 file changed, 2 insertions(+)

sound/hda/hdac_device.c +2 -0

index 333220f0f8afc..3e9e9ac804f62 100644
@@ -127,6 +127,8 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_init);
 void snd_hdac_device_exit(struct hdac_device *codec)
 {
 	pm_runtime_put_noidle(&codec->dev);
+	/* keep balance of runtime PM child_count in parent device */
+	pm_runtime_set_suspended(&codec->dev);
 	snd_hdac_bus_remove_device(codec->bus, codec);
 	kfree(codec->vendor_name);
 	kfree(codec->chip_name);

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:23 UTC #114 lore raw

PATCH 103/177 ALSA: hda: use consistent HDAudio spelling in comments/docs

From: Pierre-Louis Bossart <[email protected]>

[ Upstream commit b79de57b4378a93115307be6962d05b099eb0f37 ]

We use HDaudio and HDAudio, pick one to make searches easier. No functionality change

Also fix timestamping typo in documentation.

Reported-by Guennadi Liakhovetski <[email protected]>

Signed-off-by Pierre-Louis Bossart <[email protected]>

Reviewed-by Bard Liao <[email protected]>

Reviewed-by Guennadi Liakhovetski <[email protected]>

Signed-off-by Kai Vehmanen <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 Documentation/sound/designs/timestamping.rst |  2 +-
 sound/hda/intel-dsp-config.c                 | 10 +++++-----
 sound/x86/Kconfig                            |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

Documentation/sound/designs/timestamping.rst +1 -1

index 2b0fff5034151..7c7ecf5dbc4bd 100644
@@ -143,7 +143,7 @@ timestamp shows when the information is put together by the driver
 before returning from the ``STATUS`` and ``STATUS_EXT`` ioctl. in most cases
 this driver_timestamp will be identical to the regular system tstamp.
 
-Examples of typestamping with HDaudio:
+Examples of timestamping with HDAudio:
 
 1. DMA timestamp, no compensation for DMA+analog delay
 ::

sound/hda/intel-dsp-config.c +5 -5

index 99aec73491676..1c5114dedda92 100644
@@ -54,7 +54,7 @@ static const struct config_entry config_table[] = {
 #endif
 /*
  * Apollolake (Broxton-P)
- * the legacy HDaudio driver is used except on Up Squared (SOF) and
+ * the legacy HDAudio driver is used except on Up Squared (SOF) and
  * Chromebooks (SST)
  */
 #if IS_ENABLED(CONFIG_SND_SOC_SOF_APOLLOLAKE)

@@ -89,7 +89,7 @@ static const struct config_entry config_table[] = {
 	},
 #endif
 /*
- * Skylake and Kabylake use legacy HDaudio driver except for Google
+ * Skylake and Kabylake use legacy HDAudio driver except for Google
  * Chromebooks (SST)
  */

@@ -135,7 +135,7 @@ static const struct config_entry config_table[] = {
 #endif
 
 /*
- * Geminilake uses legacy HDaudio driver except for Google
+ * Geminilake uses legacy HDAudio driver except for Google
  * Chromebooks
  */
 /* Geminilake */

@@ -157,7 +157,7 @@ static const struct config_entry config_table[] = {
 
 /*
  * CoffeeLake, CannonLake, CometLake, IceLake, TigerLake use legacy
- * HDaudio driver except for Google Chromebooks and when DMICs are
+ * HDAudio driver except for Google Chromebooks and when DMICs are
  * present. Two cases are required since Coreboot does not expose NHLT
  * tables.
  *

@@ -391,7 +391,7 @@ int snd_intel_dsp_driver_probe(struct pci_dev *pci)
 	if (pci->class == 0x040300)
 		return SND_INTEL_DSP_DRIVER_LEGACY;
 	if (pci->class != 0x040100 && pci->class != 0x040380) {
-		dev_err(&pci->dev, "Unknown PCI class/subclass/prog-if information (0x%06x) found, selecting HDA legacy driver\n", pci->class);
+		dev_err(&pci->dev, "Unknown PCI class/subclass/prog-if information (0x%06x) found, selecting HDAudio legacy driver\n", pci->class);
 		return SND_INTEL_DSP_DRIVER_LEGACY;
 	}

sound/x86/Kconfig +1 -1

index 77777192f6508..4ffcc5e623c22 100644
@@ -9,7 +9,7 @@ menuconfig SND_X86
 if SND_X86
 
 config HDMI_LPE_AUDIO
-	tristate "HDMI audio without HDaudio on Intel Atom platforms"
+	tristate "HDMI audio without HDAudio on Intel Atom platforms"
 	depends on DRM_I915
 	select SND_PCM
 	help

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:22 UTC #115 lore raw

PATCH 104/177 drivers/net/wan/hdlc: Change the default of hard_header_len to 0

From: Xie He <[email protected]>

[ Upstream commit 2b7bcd967a0f5b7ac9bb0c37b92de36e073dd119 ]

Change the default value of hard_header_len in hdlc.c from 16 to 0.

Currently there are 6 HDLC protocol drivers, among them:

hdlc_raw_eth, hdlc_cisco, hdlc_ppp, hdlc_x25 set hard_header_len when attaching the protocol, overriding the default. So this patch does not affect them.

hdlc_raw and hdlc_fr don't set hard_header_len when attaching the protocol. So this patch will change the hard_header_len of the HDLC device for them from 16 to 0.

This is the correct change because both hdlc_raw and hdlc_fr don't have header_ops, and the code in net/packet/af_packet.c expects the value of hard_header_len to be consistent with header_ops.

In net/packet/af_packet.c, in the packet_snd function, for AF_PACKET/DGRAM sockets it would reserve a headroom of hard_header_len and call dev_hard_header to fill in that headroom, and for AF_PACKET/RAW sockets, it does not reserve the headroom and does not call dev_hard_header, but checks if the user has provided a header of length hard_header_len (in function dev_validate_header).

Cc Krzysztof Halasa <[email protected]>

Cc Martin Schiller <[email protected]>

Signed-off-by Xie He <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/net/wan/hdlc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/wan/hdlc.c +1 -1

index 386ed2aa31fd9..9b00708676cf7 100644
@@ -229,7 +229,7 @@ static void hdlc_setup_dev(struct net_device *dev)
 	dev->min_mtu		 = 68;
 	dev->max_mtu		 = HDLC_MAX_MTU;
 	dev->type		 = ARPHRD_RAWHDLC;
-	dev->hard_header_len	 = 16;
+	dev->hard_header_len	 = 0;
 	dev->needed_headroom	 = 0;
 	dev->addr_len		 = 0;
 	dev->header_ops		 = &hdlc_null_ops;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:22 UTC #116 lore raw

PATCH 105/177 drm/amdgpu: Fix bug in reporting voltage for CIK

From: Sandeep Raghuraman <[email protected]>

[ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ]

On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask.

This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting.

Signed-off-by Sandeep Raghuraman <[email protected]>

Signed-off-by Alex Deucher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +2 -1

index 753cb2cf6b77e..3adf9c1dfdbb0 100644
@@ -3587,7 +3587,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx,
 	case AMDGPU_PP_SENSOR_GPU_POWER:
 		return smu7_get_gpu_power(hwmgr, (uint32_t *)value);
 	case AMDGPU_PP_SENSOR_VDDGFX:
-		if ((data->vr_config & 0xff) == 0x2)
+		if ((data->vr_config & VRCONF_VDDGFX_MASK) ==
+		    (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT))
 			val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device,
 					CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID);
 		else

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:22 UTC #117 lore raw

PATCH 106/177 iommu/amd: Do not force direct mapping when SME is active

From: Joerg Roedel <[email protected]>

[ Upstream commit 7cad554887f1c5fd77e57e6bf4be38370c2160cb ]

Do not force devices supporting IOMMUv2 to be direct mapped when memory encryption is active. This might cause them to be unusable because their DMA mask does not include the encryption bit.

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/iommu/amd/iommu.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

drivers/iommu/amd/iommu.c +6 -1

index 200ee948f6ec1..37c74c842f3a3 100644
@@ -2650,7 +2650,12 @@ static int amd_iommu_def_domain_type(struct device *dev)
 	if (!dev_data)
 		return 0;
 
-	if (dev_data->iommu_v2)
+	/*
+	 * Do not identity map IOMMUv2 capable devices when memory encryption is
+	 * active, because some of those devices (AMD GPUs) don't have the
+	 * encryption bit in their DMA-mask and require remapping.
+	 */
+	if (!mem_encrypt_active() && dev_data->iommu_v2)
 		return IOMMU_DOMAIN_IDENTITY;
 
 	return 0;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:22 UTC #118 lore raw

PATCH 107/177 iommu/amd: Do not use IOMMUv2 functionality when SME is active

From: Joerg Roedel <[email protected]>

[ Upstream commit 2822e582501b65707089b097e773e6fd70774841 ]

When memory encryption is active the device is likely not in a direct mapped domain. Forbid using IOMMUv2 functionality for now until finer grained checks for this have been implemented.

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

---
 drivers/iommu/amd/iommu_v2.c | 7 +++++++
 1 file changed, 7 insertions(+)

drivers/iommu/amd/iommu_v2.c +7 -0

index e4b025c5637c4..5a188cac7a0f1 100644
@@ -737,6 +737,13 @@ int amd_iommu_init_device(struct pci_dev *pdev, int pasids)
 
 	might_sleep();
 
+	/*
+	 * When memory encryption is active the device is likely not in a
+	 * direct-mapped domain. Forbid using IOMMUv2 functionality for now.
+	 */
+	if (mem_encrypt_active())
+		return -ENODEV;
+
 	if (!amd_iommu_v2_supported())
 		return -ENODEV;

Signature · 1 line

2.25.1

Greg Kroah-Hartman

author maintainer

2020-09-15 23:21 UTC #119 lore raw

PATCH 108/177 gcov: Disable gcov build with GCC 10

Link https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891288

From: Leon Romanovsky <[email protected]>

[ Upstream commit cfc905f158eaa099d6258031614d11869e7ef71c ]

GCOV built with GCC 10 doesn't initialize n_function variable. This produces different kernel panics as was seen by Colin in Ubuntu and me in FC 32.

As a workaround, let's disable GCOV build for broken GCC 10 version.

Link https://lore.kernel.org/lkml/[email protected] open here

Link https://lore.kernel.org/lkml/CAHk-=whbijeSdSvx-Xcr0DPMj0BiwhJ+uiNnDSVZcr_h_kg7UA@mail.gmail.com/ open here

Cc Colin Ian King <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

Signed-off-by Linus Torvalds <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

---
 kernel/gcov/Kconfig | 1 +
 1 file changed, 1 insertion(+)

kernel/gcov/Kconfig +1 -0

index 3110c77230c7f..bb4b680e8455a 100644
@@ -4,6 +4,7 @@ menu "GCOV-based kernel profiling"
 config GCOV_KERNEL
 	bool "Enable gcov-based kernel profiling"
 	depends on DEBUG_FS
+	depends on !CC_IS_GCC || GCC_VERSION < 100000
 	select CONSTRUCTORS if !UML
 	default n
 	help

Signature · 1 line

2.25.1

Linus Torvalds

2020-09-15 17:27 UTC #120 lore raw

Re: [PATCH 5.8 108/177] gcov: Disable gcov build with GCC 10

Quoted 6 lines · Greg Kroah-Hartman

GCOV built with GCC 10 doesn't initialize n_function variable. This produces different kernel panics as was seen by Colin in Ubuntu and me in FC 32.
As a workaround, let's disable GCOV build for broken GCC 10 version.

Oh, Peter Oberparleiter actually figured out what was wrong, and we have commit 40249c696207 ("gcov: add support for GCC 10.1") upstream that enables it again with the fix for the changed semantics in gcc-10.

Linus

Sasha Levin

maintainer

2020-09-15 18:43 UTC #121 lore raw

Re: [PATCH 5.8 108/177] gcov: Disable gcov build with GCC 10

Quoted 7 lines · Linus Torvalds

Quoted 5 lines · Greg Kroah-Hartman
GCOV built with GCC 10 doesn't initialize n_function variable. This produces different kernel panics as was seen by Colin in Ubuntu and me in FC 32.

Quoted 6 lines

Quoted 1 line
As a workaround, let's disable GCOV build for broken GCC 10 version.
Oh, Peter Oberparleiter actually figured out what was wrong, and we have commit 40249c696207 ("gcov: add support for GCC 10.1") upstream that enables it again with the fix for the changed semantics in gcc-10.

AUTOSEL spotted it
(https://lore.kernel.org/stable/[email protected]/),
and I didn't want to rush it in given it doesn't have a fixes/stable tag.

I'll queue it up for this cycle as you've pointed it out.

Signature · 2 lines

Thanks,
Sasha

Greg Kroah-Hartman

author maintainer

2020-09-15 23:21 UTC #122 lore raw

PATCH 109/177 iio: adc: mcp3422: fix locking scope

From: Angelo Compagnucci <[email protected]>

commit 3f1093d83d7164e4705e4232ccf76da54adfda85 upstream.

Locking should be held for the entire reading sequence involving setting the channel, waiting for the channel switch and reading from the channel.
If not, reading from a channel can result mixing with the reading from another channel.

Fixes 07914c84ba30 ("iio: adc: Add driver for Microchip MCP3422/3/4 high resolution ADC")

Signed-off-by Angelo Compagnucci <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/mcp3422.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

drivers/iio/adc/mcp3422.c +7 -5

@@ -96,16 +96,12 @@ static int mcp3422_update_config(struct
 {
 	int ret;
 
-	mutex_lock(&adc->lock);
-
 	ret = i2c_master_send(adc->i2c, &newconfig, 1);
 	if (ret > 0) {
 		adc->config = newconfig;
 		ret = 0;
 	}
 
-	mutex_unlock(&adc->lock);
-
 	return ret;
 }

@@ -138,6 +134,8 @@ static int mcp3422_read_channel(struct m
 	u8 config;
 	u8 req_channel = channel->channel;
 
+	mutex_lock(&adc->lock);
+
 	if (req_channel != MCP3422_CHANNEL(adc->config)) {
 		config = adc->config;
 		config &= ~MCP3422_CHANNEL_MASK;

@@ -152,7 +150,11 @@ static int mcp3422_read_channel(struct m
 		msleep(mcp3422_read_times[MCP3422_SAMPLE_RATE(adc->config)]);
 	}
 
-	return mcp3422_read(adc, value, &config);
+	ret = mcp3422_read(adc, value, &config);
+
+	mutex_unlock(&adc->lock);
+
+	return ret;
 }
 
 static int mcp3422_read_raw(struct iio_dev *iio,

Greg Kroah-Hartman

author maintainer

2020-09-15 23:21 UTC #123 lore raw

PATCH 110/177 iio: adc: ti-ads1015: fix conversion when CONFIG_PM is not set

From: Maxim Kochetkov <[email protected]>

commit e71e6dbe96ac80ac2aebe71a6a942e7bd60e7596 upstream.

To stop conversion ads1015_set_power_state() function call unimplemented function __pm_runtime_suspend() from pm_runtime_put_autosuspend() if CONFIG_PM is not set.
In case of CONFIG_PM is not set: __pm_runtime_suspend() returns -ENOSYS, so ads1015_read_raw() failed because ads1015_set_power_state() returns an error.

If CONFIG_PM is disabled, there is no need to start/stop conversion. Fix it by adding return 0 function variant if CONFIG_PM is not set.

Signed-off-by Maxim Kochetkov <[email protected]>

Fixes ecc24e72f437 ("iio: adc: Add TI ADS1015 ADC driver support")

Tested-by Maxim Kiselev <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/ti-ads1015.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

drivers/iio/adc/ti-ads1015.c +10 -0

@@ -316,6 +316,7 @@ static const struct iio_chan_spec ads111
 	IIO_CHAN_SOFT_TIMESTAMP(ADS1015_TIMESTAMP),
 };
 
+#ifdef CONFIG_PM
 static int ads1015_set_power_state(struct ads1015_data *data, bool on)
 {
 	int ret;

@@ -333,6 +334,15 @@ static int ads1015_set_power_state(struc
 	return ret < 0 ? ret : 0;
 }
 
+#else /* !CONFIG_PM */
+
+static int ads1015_set_power_state(struct ads1015_data *data, bool on)
+{
+	return 0;
+}
+
+#endif /* !CONFIG_PM */
+
 static
 int ads1015_get_adc_result(struct ads1015_data *data, int chan, int *val)
 {

Greg Kroah-Hartman

author maintainer

2020-09-15 23:20 UTC #124 lore raw

PATCH 111/177 iio: cros_ec: Set Gyroscope default frequency to 25Hz

From: Gwendal Grignou <[email protected]>

commit 336306790b2bbf7ce837625fa3b24ba724d05838 upstream.

BMI160 Minimium gyroscope frequency in normal mode is 25Hz. When older EC firmware do not report their sensors frequencies, use 25Hz as the minimum for gyroscope to be sure it works on BMI160.

Fixes ae7b02ad2f32d ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")

Signed-off-by Gwendal Grignou <[email protected]>

Reviewed-by Enric Balletbo i Serra <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +4 -1

@@ -72,10 +72,13 @@ static void get_default_min_max_freq(enu
 
 	switch (type) {
 	case MOTIONSENSE_TYPE_ACCEL:
-	case MOTIONSENSE_TYPE_GYRO:
 		*min_freq = 12500;
 		*max_freq = 100000;
 		break;
+	case MOTIONSENSE_TYPE_GYRO:
+		*min_freq = 25000;
+		*max_freq = 100000;
+		break;
 	case MOTIONSENSE_TYPE_MAG:
 		*min_freq = 5000;
 		*max_freq = 25000;

Greg Kroah-Hartman

author maintainer

2020-09-15 23:20 UTC #125 lore raw

PATCH 112/177 iio:light:ltr501 Fix timestamp alignment issue.

From: Jonathan Cameron <[email protected]>

commit 2684d5003490df5398aeafe2592ba9d4a4653998 upstream.

Forced alignment of ts is not strictly necessary but probably makes the code slightly less fragile.

Note there has been some rework in this driver of the years, so no way this will apply cleanly all the way back.

Fixes 2690be905123 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/light/ltr501.c |   15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

drivers/iio/light/ltr501.c +9 -6

@@ -1243,13 +1243,16 @@ static irqreturn_t ltr501_trigger_handle
 	struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct ltr501_data *data = iio_priv(indio_dev);
-	u16 buf[8];
+	struct {
+		u16 channels[3];
+		s64 ts __aligned(8);
+	} scan;
 	__le16 als_buf[2];
 	u8 mask = 0;
 	int j = 0;
 	int ret, psdata;
 
-	memset(buf, 0, sizeof(buf));
+	memset(&scan, 0, sizeof(scan));
 
 	/* figure out which data needs to be ready */
 	if (test_bit(0, indio_dev->active_scan_mask) ||

@@ -1268,9 +1271,9 @@ static irqreturn_t ltr501_trigger_handle
 		if (ret < 0)
 			return ret;
 		if (test_bit(0, indio_dev->active_scan_mask))
-			buf[j++] = le16_to_cpu(als_buf[1]);
+			scan.channels[j++] = le16_to_cpu(als_buf[1]);
 		if (test_bit(1, indio_dev->active_scan_mask))
-			buf[j++] = le16_to_cpu(als_buf[0]);
+			scan.channels[j++] = le16_to_cpu(als_buf[0]);
 	}
 
 	if (mask & LTR501_STATUS_PS_RDY) {

@@ -1278,10 +1281,10 @@ static irqreturn_t ltr501_trigger_handle
 				       &psdata, 2);
 		if (ret < 0)
 			goto done;
-		buf[j++] = psdata & LTR501_PS_DATA_MASK;
+		scan.channels[j++] = psdata & LTR501_PS_DATA_MASK;
 	}
 
-	iio_push_to_buffers_with_timestamp(indio_dev, buf,
+	iio_push_to_buffers_with_timestamp(indio_dev, &scan,
 					   iio_get_time_ns(indio_dev));
 
 done:

Greg Kroah-Hartman

author maintainer

2020-09-15 23:21 UTC #126 lore raw

PATCH 113/177 iio:proximity:mb1232: Fix timestamp alignment and prevent data leak.

From: Jonathan Cameron <[email protected]>

commit f60e8bb84282b8e633956cfe74b4f0d64ca73cec upstream.

One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 16 byte s16 array on the stack As Lars also noted
this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings.

In this case the forced alignment of the ts is necessary to ensure correct padding on x86_32 where the s64 would only be 4 byte aligned.

Fixes 16b05261537e ("mb1232.c: add distance iio sensor with i2c")

Cc Andreas Klinger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/proximity/mb1232.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

drivers/iio/proximity/mb1232.c +9 -8

@@ -40,6 +40,11 @@ struct mb1232_data {
 	 */
 	struct completion	ranging;
 	int			irqnr;
+	/* Ensure correct alignment of data to push to IIO buffer */
+	struct {
+		s16 distance;
+		s64 ts __aligned(8);
+	} scan;
 };
 
 static irqreturn_t mb1232_handle_irq(int irq, void *dev_id)

@@ -113,17 +118,13 @@ static irqreturn_t mb1232_trigger_handle
 	struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct mb1232_data *data = iio_priv(indio_dev);
-	/*
-	 * triggered buffer
-	 * 16-bit channel + 48-bit padding + 64-bit timestamp
-	 */
-	s16 buffer[8] = { 0 };
 
-	buffer[0] = mb1232_read_distance(data);
-	if (buffer[0] < 0)
+	data->scan.distance = mb1232_read_distance(data);
+	if (data->scan.distance < 0)
 		goto err;
 
-	iio_push_to_buffers_with_timestamp(indio_dev, buffer, pf->timestamp);
+	iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
+					   pf->timestamp);
 
 err:
 	iio_trigger_notify_done(indio_dev->trig);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:21 UTC #127 lore raw

PATCH 114/177 iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak.

From: Jonathan Cameron <[email protected]>

commit a6f86f724394de3629da63fe5e1b7a4ab3396efe upstream.

One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings.

Fixes tag is beyond some major refactoring so likely manual backporting would be needed to get that far back.

Whilst the force alignment of the ts is not strictly necessary, it does make the code less fragile.

Fixes 3bbec9773389 ("iio: bmc150_accel: add support for hardware fifo")

Acked-by Srinivas Pandruvada <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/accel/bmc150-accel-core.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

drivers/iio/accel/bmc150-accel-core.c +12 -3

@@ -189,6 +189,14 @@ struct bmc150_accel_data {
 	struct mutex mutex;
 	u8 fifo_mode, watermark;
 	s16 buffer[8];
+	/*
+	 * Ensure there is sufficient space and correct alignment for
+	 * the timestamp if enabled
+	 */
+	struct {
+		__le16 channels[3];
+		s64 ts __aligned(8);
+	} scan;
 	u8 bw_bits;
 	u32 slope_dur;
 	u32 slope_thres;

@@ -922,15 +930,16 @@ static int __bmc150_accel_fifo_flush(str
 	 * now.
 	 */
 	for (i = 0; i < count; i++) {
-		u16 sample[8];
 		int j, bit;
 
 		j = 0;
 		for_each_set_bit(bit, indio_dev->active_scan_mask,
 				 indio_dev->masklength)
-			memcpy(&sample[j++], &buffer[i * 3 + bit], 2);
+			memcpy(&data->scan.channels[j++], &buffer[i * 3 + bit],
+			       sizeof(data->scan.channels[0]));
 
-		iio_push_to_buffers_with_timestamp(indio_dev, sample, tstamp);
+		iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
+						   tstamp);
 
 		tstamp += sample_period;
 	}

Greg Kroah-Hartman

author maintainer

2020-09-15 23:21 UTC #128 lore raw

PATCH 115/177 iio:adc:ti-adc084s021 Fix alignment and data leak issues.

From: Jonathan Cameron <[email protected]>

commit a661b571e3682705cb402a5cd1e970586a3ec00f upstream.

This data is allocated with kzalloc so no data can leak apart from previous readings.

The force alignment of ts is not strictly necessary in this case but reduces the fragility of the code.

Fixes 3691e5a69449 ("iio: adc: add driver for the ti-adc084s021 chip")

Cc Mårten Lindahl <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/ti-adc084s021.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/iio/adc/ti-adc084s021.c +7 -3

@@ -25,6 +25,11 @@ struct adc084s021 {
 	struct spi_transfer spi_trans;
 	struct regulator *reg;
 	struct mutex lock;
+	/* Buffer used to align data */
+	struct {
+		__be16 channels[4];
+		s64 ts __aligned(8);
+	} scan;
 	/*
 	 * DMA (thus cache coherency maintenance) requires the
 	 * transfer buffers to live in their own cache line.

@@ -140,14 +145,13 @@ static irqreturn_t adc084s021_buffer_tri
 	struct iio_poll_func *pf = pollfunc;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct adc084s021 *adc = iio_priv(indio_dev);
-	__be16 data[8] = {0}; /* 4 * 16-bit words of data + 8 bytes timestamp */
 
 	mutex_lock(&adc->lock);
 
-	if (adc084s021_adc_conversion(adc, &data) < 0)
+	if (adc084s021_adc_conversion(adc, adc->scan.channels) < 0)
 		dev_err(&adc->spi->dev, "Failed to read data\n");
 
-	iio_push_to_buffers_with_timestamp(indio_dev, data,
+	iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan,
 					   iio_get_time_ns(indio_dev));
 	mutex_unlock(&adc->lock);
 	iio_trigger_notify_done(indio_dev->trig);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:20 UTC #129 lore raw

PATCH 116/177 iio:adc:ina2xx Fix timestamp alignment issue.

From: Jonathan Cameron <[email protected]>

commit f8cd222feb82ecd82dcf610fcc15186f55f9c2b5 upstream.

One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 32 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc so no data can leak apart from previous readings. The explicit alignment isn't technically needed here, but it reduced fragility and avoids cut and paste into drivers where it will be needed.

If we want this in older stables will need manual backport due to driver reworks.

Fixes c43a102e67db ("iio: ina2xx: add support for TI INA2xx Power Monitors")

Cc Stefan Brüns <[email protected]>

Cc Marc Titinger <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/ina2xx-adc.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

drivers/iio/adc/ina2xx-adc.c +7 -4

@@ -146,6 +146,11 @@ struct ina2xx_chip_info {
 	int range_vbus; /* Bus voltage maximum in V */
 	int pga_gain_vshunt; /* Shunt voltage PGA gain */
 	bool allow_async_readout;
+	/* data buffer needs space for channel data and timestamp */
+	struct {
+		u16 chan[4];
+		u64 ts __aligned(8);
+	} scan;
 };
 
 static const struct ina2xx_config ina2xx_config[] = {

@@ -738,8 +743,6 @@ static int ina2xx_conversion_ready(struc
 static int ina2xx_work_buffer(struct iio_dev *indio_dev)
 {
 	struct ina2xx_chip_info *chip = iio_priv(indio_dev);
-	/* data buffer needs space for channel data and timestap */
-	unsigned short data[4 + sizeof(s64)/sizeof(short)];
 	int bit, ret, i = 0;
 	s64 time;

@@ -758,10 +761,10 @@ static int ina2xx_work_buffer(struct iio
 		if (ret < 0)
 			return ret;
 
-		data[i++] = val;
+		chip->scan.chan[i++] = val;
 	}
 
-	iio_push_to_buffers_with_timestamp(indio_dev, data, time);
+	iio_push_to_buffers_with_timestamp(indio_dev, &chip->scan, time);
 
 	return 0;
 };

Greg Kroah-Hartman

author maintainer

2020-09-15 23:13 UTC #130 lore raw

PATCH 117/177 iio:adc:max1118 Fix alignment of timestamp and data leak issues

From: Jonathan Cameron <[email protected]>

commit db8f06d97ec284dc018e2e4890d2e5035fde8630 upstream.

This data is allocated with kzalloc so no data can leak apart from previous readings.

The explicit alignment of ts is necessary to ensure correct padding on architectures where s64 is only 4 bytes aligned such as x86_32.

Fixes a9e9c7153e96 ("iio: adc: add max1117/max1118/max1119 ADC driver")

Cc Akinobu Mita <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/max1118.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/iio/adc/max1118.c +7 -3

@@ -35,6 +35,11 @@ struct max1118 {
 	struct spi_device *spi;
 	struct mutex lock;
 	struct regulator *reg;
+	/* Ensure natural alignment of buffer elements */
+	struct {
+		u8 channels[2];
+		s64 ts __aligned(8);
+	} scan;
 
 	u8 data ____cacheline_aligned;
 };

@@ -165,7 +170,6 @@ static irqreturn_t max1118_trigger_handl
 	struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct max1118 *adc = iio_priv(indio_dev);
-	u8 data[16] = { }; /* 2x 8-bit ADC data + padding + 8 bytes timestamp */
 	int scan_index;
 	int i = 0;

@@ -183,10 +187,10 @@ static irqreturn_t max1118_trigger_handl
 			goto out;
 		}
 
-		data[i] = ret;
+		adc->scan.channels[i] = ret;
 		i++;
 	}
-	iio_push_to_buffers_with_timestamp(indio_dev, data,
+	iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan,
 					   iio_get_time_ns(indio_dev));
 out:
 	mutex_unlock(&adc->lock);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:16 UTC #131 lore raw

PATCH 118/177 iio:adc:ti-adc081c Fix alignment and data leak issues

From: Jonathan Cameron <[email protected]>

commit 54f82df2ba86e2a8e9cbf4036d192366e3905c89 upstream.

This data is allocated with kzalloc so no data can leak apart from previous readings.

The eplicit alignment of ts is necessary to ensure correct padding on x86_32 where s64 is only aligned to 4 bytes.

Fixes 08e05d1fce5c ("ti-adc081c: Initial triggered buffer support")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/adc/ti-adc081c.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

drivers/iio/adc/ti-adc081c.c +8 -3

@@ -33,6 +33,12 @@ struct adc081c {
 
 	/* 8, 10 or 12 */
 	int bits;
+
+	/* Ensure natural alignment of buffer elements */
+	struct {
+		u16 channel;
+		s64 ts __aligned(8);
+	} scan;
 };
 
 #define REG_CONV_RES 0x00

@@ -128,14 +134,13 @@ static irqreturn_t adc081c_trigger_handl
 	struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct adc081c *data = iio_priv(indio_dev);
-	u16 buf[8]; /* 2 bytes data + 6 bytes padding + 8 bytes timestamp */
 	int ret;
 
 	ret = i2c_smbus_read_word_swapped(data->i2c, REG_CONV_RES);
 	if (ret < 0)
 		goto out;
-	buf[0] = ret;
-	iio_push_to_buffers_with_timestamp(indio_dev, buf,
+	data->scan.channel = ret;
+	iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
 					   iio_get_time_ns(indio_dev));
 out:
 	iio_trigger_notify_done(indio_dev->trig);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:15 UTC #132 lore raw

PATCH 119/177 iio:magnetometer:ak8975 Fix alignment and data leak issues.

From: Jonathan Cameron <[email protected]>

commit 02ad21cefbac4d89ac443866f25b90449527737b upstream.

This data is allocated with kzalloc so no data can leak apart from previous readings.

The explicit alignment of ts is not necessary in this case as by coincidence the padding will end up the same, however I consider it to make the code less fragile and have included it.

Fixes bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")

Cc Gregor Boirie <[email protected]>

Cc Linus Walleij <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/magnetometer/ak8975.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

drivers/iio/magnetometer/ak8975.c +11 -5

@@ -365,6 +365,12 @@ struct ak8975_data {
 	struct iio_mount_matrix orientation;
 	struct regulator	*vdd;
 	struct regulator	*vid;
+
+	/* Ensure natural alignment of timestamp */
+	struct {
+		s16 channels[3];
+		s64 ts __aligned(8);
+	} scan;
 };
 
 /* Enable attached power regulator if any. */

@@ -787,7 +793,6 @@ static void ak8975_fill_buffer(struct ii
 	const struct i2c_client *client = data->client;
 	const struct ak_def *def = data->def;
 	int ret;
-	s16 buff[8]; /* 3 x 16 bits axis values + 1 aligned 64 bits timestamp */
 	__le16 fval[3];
 
 	mutex_lock(&data->lock);

@@ -810,12 +815,13 @@ static void ak8975_fill_buffer(struct ii
 	mutex_unlock(&data->lock);
 
 	/* Clamp to valid range. */
-	buff[0] = clamp_t(s16, le16_to_cpu(fval[0]), -def->range, def->range);
-	buff[1] = clamp_t(s16, le16_to_cpu(fval[1]), -def->range, def->range);
-	buff[2] = clamp_t(s16, le16_to_cpu(fval[2]), -def->range, def->range);
+	data->scan.channels[0] = clamp_t(s16, le16_to_cpu(fval[0]), -def->range, def->range);
+	data->scan.channels[1] = clamp_t(s16, le16_to_cpu(fval[1]), -def->range, def->range);
+	data->scan.channels[2] = clamp_t(s16, le16_to_cpu(fval[2]), -def->range, def->range);
 
-	iio_push_to_buffers_with_timestamp(indio_dev, buff,
+	iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
 					   iio_get_time_ns(indio_dev));
+
 	return;
 
 unlock:

Greg Kroah-Hartman

author maintainer

2020-09-15 23:13 UTC #133 lore raw

PATCH 120/177 iio:light:max44000 Fix timestamp alignment and prevent data leak.

From: Jonathan Cameron <[email protected]>

commit 523628852a5f5f34a15252b2634d0498d3cfb347 upstream.

One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv().
This data is allocated with kzalloc so no data can leak appart from previous readings.

It is necessary to force the alignment of ts to avoid the padding on x86_32 being different from 64 bit platorms (it alows for 4 bytes aligned 8 byte types.

Fixes 06ad7ea10e2b ("max44000: Initial triggered buffer support")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/light/max44000.c |   12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

drivers/iio/light/max44000.c +8 -4

@@ -75,6 +75,11 @@
 struct max44000_data {
 	struct mutex lock;
 	struct regmap *regmap;
+	/* Ensure naturally aligned timestamp */
+	struct {
+		u16 channels[2];
+		s64 ts __aligned(8);
+	} scan;
 };
 
 /* Default scale is set to the minimum of 0.03125 or 1 / (1 << 5) lux */

@@ -488,7 +493,6 @@ static irqreturn_t max44000_trigger_hand
 	struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct max44000_data *data = iio_priv(indio_dev);
-	u16 buf[8]; /* 2x u16 + padding + 8 bytes timestamp */
 	int index = 0;
 	unsigned int regval;
 	int ret;

@@ -498,17 +502,17 @@ static irqreturn_t max44000_trigger_hand
 		ret = max44000_read_alsval(data);
 		if (ret < 0)
 			goto out_unlock;
-		buf[index++] = ret;
+		data->scan.channels[index++] = ret;
 	}
 	if (test_bit(MAX44000_SCAN_INDEX_PRX, indio_dev->active_scan_mask)) {
 		ret = regmap_read(data->regmap, MAX44000_REG_PRX_DATA, &regval);
 		if (ret < 0)
 			goto out_unlock;
-		buf[index] = regval;
+		data->scan.channels[index] = regval;
 	}
 	mutex_unlock(&data->lock);
 
-	iio_push_to_buffers_with_timestamp(indio_dev, buf,
+	iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
 					   iio_get_time_ns(indio_dev));
 	iio_trigger_notify_done(indio_dev->trig);
 	return IRQ_HANDLED;

Greg Kroah-Hartman

author maintainer

2020-09-15 23:13 UTC #134 lore raw

PATCH 121/177 iio:chemical:ccs811: Fix timestamp alignment and prevent data leak.

From: Jonathan Cameron <[email protected]>

commit eb1a148ef41d8ae8d9201efc3f1b145976290331 upstream.

One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc so no data can leak appart from previous readings.

The explicit alignment of ts is necessary to ensure consistent padding for x86_32 in which the ts would otherwise be 4 byte aligned.

Fixes 283d26917ad6 ("iio: chemical: ccs811: Add triggered buffer support")

Cc Narcisa Ana Maria Vasile <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/chemical/ccs811.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

drivers/iio/chemical/ccs811.c +9 -4

@@ -78,6 +78,11 @@ struct ccs811_data {
 	struct iio_trigger *drdy_trig;
 	struct gpio_desc *wakeup_gpio;
 	bool drdy_trig_on;
+	/* Ensures correct alignment of timestamp if present */
+	struct {
+		s16 channels[2];
+		s64 ts __aligned(8);
+	} scan;
 };
 
 static const struct iio_chan_spec ccs811_channels[] = {

@@ -327,17 +332,17 @@ static irqreturn_t ccs811_trigger_handle
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct ccs811_data *data = iio_priv(indio_dev);
 	struct i2c_client *client = data->client;
-	s16 buf[8]; /* s16 eCO2 + s16 TVOC + padding + 8 byte timestamp */
 	int ret;
 
-	ret = i2c_smbus_read_i2c_block_data(client, CCS811_ALG_RESULT_DATA, 4,
-					    (u8 *)&buf);
+	ret = i2c_smbus_read_i2c_block_data(client, CCS811_ALG_RESULT_DATA,
+					    sizeof(data->scan.channels),
+					    (u8 *)data->scan.channels);
 	if (ret != 4) {
 		dev_err(&client->dev, "cannot read sensor data\n");
 		goto err;
 	}
 
-	iio_push_to_buffers_with_timestamp(indio_dev, buf,
+	iio_push_to_buffers_with_timestamp(indio_dev, &data->scan,
 					   iio_get_time_ns(indio_dev));
 
 err:

Greg Kroah-Hartman

author maintainer

2020-09-15 23:13 UTC #135 lore raw

PATCH 122/177 iio: accel: kxsd9: Fix alignment of local buffer.

From: Jonathan Cameron <[email protected]>

commit 95ad67577de4ea08eb8e441394e698aa4addcc0b upstream.

iio_push_to_buffers_with_timestamp assumes 8 byte alignment which is not guaranteed by an array of smaller elements.

Note that whilst in this particular case the alignment forcing of the ts element is not strictly necessary it acts as good documentation. Doing this where not necessary should cut down on the number of cut and paste introduced errors elsewhere.

Fixes 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/accel/kxsd9.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

drivers/iio/accel/kxsd9.c +11 -5

@@ -209,14 +209,20 @@ static irqreturn_t kxsd9_trigger_handler
 	const struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct kxsd9_state *st = iio_priv(indio_dev);
+	/*
+	 * Ensure correct positioning and alignment of timestamp.
+	 * No need to zero initialize as all elements written.
+	 */
+	struct {
+		__be16 chan[4];
+		s64 ts __aligned(8);
+	} hw_values;
 	int ret;
-	/* 4 * 16bit values AND timestamp */
-	__be16 hw_values[8];
 
 	ret = regmap_bulk_read(st->map,
 			       KXSD9_REG_X,
-			       &hw_values,
-			       8);
+			       hw_values.chan,
+			       sizeof(hw_values.chan));
 	if (ret) {
 		dev_err(st->dev,
 			"error reading data\n");

@@ -224,7 +230,7 @@ static irqreturn_t kxsd9_trigger_handler
 	}
 
 	iio_push_to_buffers_with_timestamp(indio_dev,
-					   hw_values,
+					   &hw_values,
 					   iio_get_time_ns(indio_dev));
 	iio_trigger_notify_done(indio_dev->trig);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:12 UTC #136 lore raw

PATCH 123/177 iio:accel:mma7455: Fix timestamp alignment and prevent data leak.

From: Jonathan Cameron <[email protected]>

commit 7e5ac1f2206eda414f90c698fe1820dee873394d upstream.

One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses a 16 byte u8 array on the stack As Lars also noted
this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings.

The force alignment of ts is not strictly necessary in this particularly case but does make the code less fragile.

Fixes a84ef0d181d9 ("iio: accel: add Freescale MMA7455L/MMA7456L 3-axis accelerometer driver")

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/accel/mma7455_core.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

drivers/iio/accel/mma7455_core.c +12 -4

@@ -52,6 +52,14 @@
 
 struct mma7455_data {
 	struct regmap *regmap;
+	/*
+	 * Used to reorganize data.  Will ensure correct alignment of
+	 * the timestamp if present
+	 */
+	struct {
+		__le16 channels[3];
+		s64 ts __aligned(8);
+	} scan;
 };
 
 static int mma7455_drdy(struct mma7455_data *mma7455)

@@ -82,19 +90,19 @@ static irqreturn_t mma7455_trigger_handl
 	struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct mma7455_data *mma7455 = iio_priv(indio_dev);
-	u8 buf[16]; /* 3 x 16-bit channels + padding + ts */
 	int ret;
 
 	ret = mma7455_drdy(mma7455);
 	if (ret)
 		goto done;
 
-	ret = regmap_bulk_read(mma7455->regmap, MMA7455_REG_XOUTL, buf,
-			       sizeof(__le16) * 3);
+	ret = regmap_bulk_read(mma7455->regmap, MMA7455_REG_XOUTL,
+			       mma7455->scan.channels,
+			       sizeof(mma7455->scan.channels));
 	if (ret)
 		goto done;
 
-	iio_push_to_buffers_with_timestamp(indio_dev, buf,
+	iio_push_to_buffers_with_timestamp(indio_dev, &mma7455->scan,
 					   iio_get_time_ns(indio_dev));
 
 done:

Greg Kroah-Hartman

author maintainer

2020-09-15 23:11 UTC #137 lore raw

PATCH 124/177 iio:accel:mma8452: Fix timestamp alignment and prevent data leak.

From: Jonathan Cameron <[email protected]>

commit 89226a296d816727405d3fea684ef69e7d388bd8 upstream.

One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses a 16 byte u8 array on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to
a suitable structure in the iio_priv() data with alignment ensured by use of an explicit c structure. This data is allocated with kzalloc so no data can leak appart from previous readings.

The additional forcing of the 8 byte alignment of the timestamp is not strictly necessary but makes the code less fragile by making this explicit.

Fixes c7eeea93ac60 ("iio: Add Freescale MMA8452Q 3-axis accelerometer driver")

Cc Peter Meerwald <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/iio/accel/mma8452.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

drivers/iio/accel/mma8452.c +8 -3

@@ -110,6 +110,12 @@ struct mma8452_data {
 	int sleep_val;
 	struct regulator *vdd_reg;
 	struct regulator *vddio_reg;
+
+	/* Ensure correct alignment of time stamp when present */
+	struct {
+		__be16 channels[3];
+		s64 ts __aligned(8);
+	} buffer;
 };
 
  /**

@@ -1091,14 +1097,13 @@ static irqreturn_t mma8452_trigger_handl
 	struct iio_poll_func *pf = p;
 	struct iio_dev *indio_dev = pf->indio_dev;
 	struct mma8452_data *data = iio_priv(indio_dev);
-	u8 buffer[16]; /* 3 16-bit channels + padding + ts */
 	int ret;
 
-	ret = mma8452_read(data, (__be16 *)buffer);
+	ret = mma8452_read(data, data->buffer.channels);
 	if (ret < 0)
 		goto done;
 
-	iio_push_to_buffers_with_timestamp(indio_dev, buffer,
+	iio_push_to_buffers_with_timestamp(indio_dev, &data->buffer,
 					   iio_get_time_ns(indio_dev));
 
 done:

Greg Kroah-Hartman

author maintainer

2020-09-15 23:11 UTC #138 lore raw

PATCH 125/177 staging: wlan-ng: fix out of bounds read in prism2sta_probe_usb()

Link https://syzkaller.appspot.com/bug?extid=22794221ab96b0bab53a

From: Rustam Kovhaev <[email protected]>

commit fea22e159d51c766ba70473f473a0ec914cc7e92 upstream.

let's use usb_find_common_endpoints() to discover endpoints, it does all necessary checks for type and xfer direction

remove memset() in hfa384x_create(), because we now assign endpoints in prism2sta_probe_usb() and because create_wlan() uses kzalloc() to allocate hfa384x struct before calling hfa384x_create()

Fixes faaff9765664 ("staging: wlan-ng: properly check endpoint types")

Reported-and-tested-by [email protected]

Signed-off-by Rustam Kovhaev <[email protected]>

Cc stable <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/staging/wlan-ng/hfa384x_usb.c |    5 -----
 drivers/staging/wlan-ng/prism2usb.c   |   19 ++++++-------------
 2 files changed, 6 insertions(+), 18 deletions(-)

drivers/staging/wlan-ng/hfa384x_usb.c +0 -5

@@ -524,13 +524,8 @@ static void hfa384x_usb_defer(struct wor
  */
 void hfa384x_create(struct hfa384x *hw, struct usb_device *usb)
 {
-	memset(hw, 0, sizeof(*hw));
 	hw->usb = usb;
 
-	/* set up the endpoints */
-	hw->endp_in = usb_rcvbulkpipe(usb, 1);
-	hw->endp_out = usb_sndbulkpipe(usb, 2);
-
 	/* Set up the waitq */
 	init_waitqueue_head(&hw->cmdq);

drivers/staging/wlan-ng/prism2usb.c +6 ~~-13~~

@@ -61,23 +61,14 @@ static int prism2sta_probe_usb(struct us
 			       const struct usb_device_id *id)
 {
 	struct usb_device *dev;
-	const struct usb_endpoint_descriptor *epd;
-	const struct usb_host_interface *iface_desc = interface->cur_altsetting;
+	struct usb_endpoint_descriptor *bulk_in, *bulk_out;
+	struct usb_host_interface *iface_desc = interface->cur_altsetting;
 	struct wlandevice *wlandev = NULL;
 	struct hfa384x *hw = NULL;
 	int result = 0;
 
-	if (iface_desc->desc.bNumEndpoints != 2) {
-		result = -ENODEV;
-		goto failed;
-	}
-
-	result = -EINVAL;
-	epd = &iface_desc->endpoint[1].desc;
-	if (!usb_endpoint_is_bulk_in(epd))
-		goto failed;
-	epd = &iface_desc->endpoint[2].desc;
-	if (!usb_endpoint_is_bulk_out(epd))
+	result = usb_find_common_endpoints(iface_desc, &bulk_in, &bulk_out, NULL, NULL);
+	if (result)
 		goto failed;
 
 	dev = interface_to_usbdev(interface);

@@ -96,6 +87,8 @@ static int prism2sta_probe_usb(struct us
 	}
 
 	/* Initialize the hw data */
+	hw->endp_in = usb_rcvbulkpipe(dev, bulk_in->bEndpointAddress);
+	hw->endp_out = usb_sndbulkpipe(dev, bulk_out->bEndpointAddress);
 	hfa384x_create(hw, dev);
 	hw->wlandev = wlandev;

Greg Kroah-Hartman

author maintainer

2020-09-15 23:12 UTC #139 lore raw

PATCH 126/177 btrfs: require only sector size alignment for parent eb bytenr

From: Qu Wenruo <[email protected]>

commit ea57788eb76dc81f6003245427356a1dcd0ac524 upstream.

[BUG]
A completely sane converted fs will cause kernel warning at balance time:

  [ 1557.188633] BTRFS info (device sda7): relocating block group 8162107392 flags data
  [ 1563.358078] BTRFS info (device sda7): found 11722 extents
  [ 1563.358277] BTRFS info (device sda7): leaf 7989321728 gen 95 total ptrs 213 free space 3458 owner 2
  [ 1563.358280] 	item 0 key (7984947200 169 0) itemoff 16250 itemsize 33
  [ 1563.358281] 		extent refs 1 gen 90 flags 2
  [ 1563.358282] 		ref#0: tree block backref root 4
  [ 1563.358285] 	item 1 key (7985602560 169 0) itemoff 16217 itemsize 33
  [ 1563.358286] 		extent refs 1 gen 93 flags 258
  [ 1563.358287] 		ref#0: shared block backref parent 7985602560
  [ 1563.358288] 			(parent 7985602560 is NOT ALIGNED to nodesize 16384)
  [ 1563.358290] 	item 2 key (7985635328 169 0) itemoff 16184 itemsize 33
  ...
  [ 1563.358995] BTRFS error (device sda7): eb 7989321728 invalid extent inline ref type 182
  [ 1563.358996] ------------[ cut here ]------------
  [ 1563.359005] WARNING: CPU: 14 PID: 2930 at 0xffffffff9f231766

Then with transaction abort, and obviously failed to balance the fs.

[CAUSE]
That mentioned inline ref type 182 is completely sane, it's BTRFS_SHARED_BLOCK_REF_KEY, it's some extra check making kernel to believe it's invalid.

Commit 64ecdb647ddb ("Btrfs: add one more sanity check for shared ref type") introduced extra checks for backref type.

One of the requirement is, parent bytenr must be aligned to node size, which is not correct.

One example is like this:

0 1G 1G+4K 2G 2G+4K

	|   |///////////////////|//|  <- A chunk starts at 1G+4K
            |   |	<- A tree block get reserved at bytenr 1G+4K

Then we have a valid tree block at bytenr 1G+4K, but not aligned to nodesize (16K).

Such chunk is not ideal, but current kernel can handle it pretty well. We may warn about such tree block in the future, but should not reject them.

[FIX]
Change the alignment requirement from node size alignment to sector size alignment.

Also, to make our lives a little easier, also output @iref when btrfs_get_extent_inline_ref_type() failed, so we can locate the item easier.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205475

Fixes 64ecdb647ddb ("Btrfs: add one more sanity check for shared ref type")

CC [email protected] # 4.14+

Reviewed-by Josef Bacik <[email protected]>

Signed-off-by Qu Wenruo <[email protected]>

[ update comments and messages ]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/extent-tree.c |   19 +++++++++----------
 fs/btrfs/print-tree.c  |   12 +++++++-----
 2 files changed, 16 insertions(+), 15 deletions(-)

fs/btrfs/extent-tree.c +9 ~~-10~~

@@ -400,12 +400,11 @@ int btrfs_get_extent_inline_ref_type(con
 			if (type == BTRFS_SHARED_BLOCK_REF_KEY) {
 				ASSERT(eb->fs_info);
 				/*
-				 * Every shared one has parent tree
-				 * block, which must be aligned to
-				 * nodesize.
+				 * Every shared one has parent tree block,
+				 * which must be aligned to sector size.
 				 */
 				if (offset &&
-				    IS_ALIGNED(offset, eb->fs_info->nodesize))
+				    IS_ALIGNED(offset, eb->fs_info->sectorsize))
 					return type;
 			}
 		} else if (is_data == BTRFS_REF_TYPE_DATA) {

@@ -414,12 +413,11 @@ int btrfs_get_extent_inline_ref_type(con
 			if (type == BTRFS_SHARED_DATA_REF_KEY) {
 				ASSERT(eb->fs_info);
 				/*
-				 * Every shared one has parent tree
-				 * block, which must be aligned to
-				 * nodesize.
+				 * Every shared one has parent tree block,
+				 * which must be aligned to sector size.
 				 */
 				if (offset &&
-				    IS_ALIGNED(offset, eb->fs_info->nodesize))
+				    IS_ALIGNED(offset, eb->fs_info->sectorsize))
 					return type;
 			}
 		} else {

@@ -429,8 +427,9 @@ int btrfs_get_extent_inline_ref_type(con
 	}
 
 	btrfs_print_leaf((struct extent_buffer *)eb);
-	btrfs_err(eb->fs_info, "eb %llu invalid extent inline ref type %d",
-		  eb->start, type);
+	btrfs_err(eb->fs_info,
+		  "eb %llu iref 0x%lx invalid extent inline ref type %d",
+		  eb->start, (unsigned long)iref, type);
 	WARN_ON(1);
 
 	return BTRFS_REF_TYPE_INVALID;

fs/btrfs/print-tree.c +7 -5

@@ -95,9 +95,10 @@ static void print_extent_item(struct ext
 			 * offset is supposed to be a tree block which
 			 * must be aligned to nodesize.
 			 */
-			if (!IS_ALIGNED(offset, eb->fs_info->nodesize))
-				pr_info("\t\t\t(parent %llu is NOT ALIGNED to nodesize %llu)\n",
-					offset, (unsigned long long)eb->fs_info->nodesize);
+			if (!IS_ALIGNED(offset, eb->fs_info->sectorsize))
+				pr_info(
+			"\t\t\t(parent %llu not aligned to sectorsize %u)\n",
+					offset, eb->fs_info->sectorsize);
 			break;
 		case BTRFS_EXTENT_DATA_REF_KEY:
 			dref = (struct btrfs_extent_data_ref *)(&iref->offset);

@@ -112,8 +113,9 @@ static void print_extent_item(struct ext
 			 * must be aligned to nodesize.
 			 */
 			if (!IS_ALIGNED(offset, eb->fs_info->nodesize))
-				pr_info("\t\t\t(parent %llu is NOT ALIGNED to nodesize %llu)\n",
-				     offset, (unsigned long long)eb->fs_info->nodesize);
+				pr_info(
+			"\t\t\t(parent %llu not aligned to sectorsize %u)\n",
+				     offset, eb->fs_info->sectorsize);
 			break;
 		default:
 			pr_cont("(extent %llu has INVALID ref type %d)\n",

Greg Kroah-Hartman

author maintainer

2020-09-15 23:18 UTC #140 lore raw

PATCH 127/177 btrfs: fix lockdep splat in add_missing_dev

From: Josef Bacik <[email protected]>

commit fccc0007b8dc952c6bc0805cdf842eb8ea06a639 upstream.

Nikolay reported a lockdep splat in generic/476 that I could reproduce with btrfs/187.

======================================================
WARNING: possible circular locking dependency detected
5.9.0-rc2+ #1 Tainted: G W
------------------------------------------------------
kswapd0/100 is trying to acquire lock:
ffff9e8ef38b6268 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x3f/0x330

but task is already holding lock:
ffffffffa9d74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (fs_reclaim){+.+.}-{0:0}:

	 fs_reclaim_acquire+0x65/0x80
	 slab_pre_alloc_hook.constprop.0+0x20/0x200
	 kmem_cache_alloc_trace+0x3a/0x1a0
	 btrfs_alloc_device+0x43/0x210
	 add_missing_dev+0x20/0x90
	 read_one_chunk+0x301/0x430
	 btrfs_read_sys_array+0x17b/0x1b0
	 open_ctree+0xa62/0x1896
	 btrfs_mount_root.cold+0x12/0xea
	 legacy_get_tree+0x30/0x50
	 vfs_get_tree+0x28/0xc0
	 vfs_kern_mount.part.0+0x71/0xb0
	 btrfs_mount+0x10d/0x379
	 legacy_get_tree+0x30/0x50
	 vfs_get_tree+0x28/0xc0
	 path_mount+0x434/0xc00
	 __x64_sys_mount+0xe3/0x120
	 do_syscall_64+0x33/0x40
	 entry_SYSCALL_64_after_hwframe+0x44/0xa9

-> #1 (&fs_info->chunk_mutex){+.+.}-{3:3}:

	 __mutex_lock+0x7e/0x7e0
	 btrfs_chunk_alloc+0x125/0x3a0
	 find_free_extent+0xdf6/0x1210
	 btrfs_reserve_extent+0xb3/0x1b0
	 btrfs_alloc_tree_block+0xb0/0x310
	 alloc_tree_block_no_bg_flush+0x4a/0x60
	 __btrfs_cow_block+0x11a/0x530
	 btrfs_cow_block+0x104/0x220
	 btrfs_search_slot+0x52e/0x9d0
	 btrfs_lookup_inode+0x2a/0x8f
	 __btrfs_update_delayed_inode+0x80/0x240
	 btrfs_commit_inode_delayed_inode+0x119/0x120
	 btrfs_evict_inode+0x357/0x500
	 evict+0xcf/0x1f0
	 vfs_rmdir.part.0+0x149/0x160
	 do_rmdir+0x136/0x1a0
	 do_syscall_64+0x33/0x40
	 entry_SYSCALL_64_after_hwframe+0x44/0xa9

-> #0 (&delayed_node->mutex){+.+.}-{3:3}:

	 __lock_acquire+0x1184/0x1fa0
	 lock_acquire+0xa4/0x3d0
	 __mutex_lock+0x7e/0x7e0
	 __btrfs_release_delayed_node.part.0+0x3f/0x330
	 btrfs_evict_inode+0x24c/0x500
	 evict+0xcf/0x1f0
	 dispose_list+0x48/0x70
	 prune_icache_sb+0x44/0x50
	 super_cache_scan+0x161/0x1e0
	 do_shrink_slab+0x178/0x3c0
	 shrink_slab+0x17c/0x290
	 shrink_node+0x2b2/0x6d0
	 balance_pgdat+0x30a/0x670
	 kswapd+0x213/0x4c0
	 kthread+0x138/0x160
	 ret_from_fork+0x1f/0x30

other info that might help us debug this:

  Chain exists of:
    &delayed_node->mutex --> &fs_info->chunk_mutex --> fs_reclaim

   Possible unsafe locking scenario:

	 CPU0                    CPU1
	 ----                    ----
    lock(fs_reclaim);
				 lock(&fs_info->chunk_mutex);
				 lock(fs_reclaim);
    lock(&delayed_node->mutex);

*** DEADLOCK ***

3 locks held by kswapd0/100:
#0: ffffffffa9d74700 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x5/0x30 #1: ffffffffa9d65c50 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x115/0x290 #2: ffff9e8e9da260e0 (&type->s_umount_key#48){++++}-{3:3}, at: super_cache_scan+0x38/0x1e0

  stack backtrace:
  CPU: 1 PID: 100 Comm: kswapd0 Tainted: G        W         5.9.0-rc2+ #1
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Call Trace:
   dump_stack+0x92/0xc8
   check_noncircular+0x12d/0x150
   __lock_acquire+0x1184/0x1fa0
   lock_acquire+0xa4/0x3d0
   ? __btrfs_release_delayed_node.part.0+0x3f/0x330
   __mutex_lock+0x7e/0x7e0
   ? __btrfs_release_delayed_node.part.0+0x3f/0x330
   ? __btrfs_release_delayed_node.part.0+0x3f/0x330
   ? lock_acquire+0xa4/0x3d0
   ? btrfs_evict_inode+0x11e/0x500
   ? find_held_lock+0x2b/0x80
   __btrfs_release_delayed_node.part.0+0x3f/0x330
   btrfs_evict_inode+0x24c/0x500
   evict+0xcf/0x1f0
   dispose_list+0x48/0x70
   prune_icache_sb+0x44/0x50
   super_cache_scan+0x161/0x1e0
   do_shrink_slab+0x178/0x3c0
   shrink_slab+0x17c/0x290
   shrink_node+0x2b2/0x6d0
   balance_pgdat+0x30a/0x670
   kswapd+0x213/0x4c0
   ? _raw_spin_unlock_irqrestore+0x46/0x60
   ? add_wait_queue_exclusive+0x70/0x70
   ? balance_pgdat+0x670/0x670
   kthread+0x138/0x160
   ? kthread_create_worker_on_cpu+0x40/0x40
   ret_from_fork+0x1f/0x30

This is because we are holding the chunk_mutex when we call btrfs_alloc_device, which does a GFP_KERNEL allocation. We don't want to switch that to a GFP_NOFS lock because this is the only place where it matters. So instead use memalloc_nofs_save() around the allocation in order to avoid the lockdep splat.

Reported-by Nikolay Borisov <[email protected]>

CC [email protected] # 4.4+

Reviewed-by Anand Jain <[email protected]>

Signed-off-by Josef Bacik <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/volumes.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

fs/btrfs/volumes.c +10 -0

@@ -4,6 +4,7 @@
  */
 
 #include <linux/sched.h>
+#include <linux/sched/mm.h>
 #include <linux/bio.h>
 #include <linux/slab.h>
 #include <linux/blkdev.h>

@@ -6500,8 +6501,17 @@ static struct btrfs_device *add_missing_
 					    u64 devid, u8 *dev_uuid)
 {
 	struct btrfs_device *device;
+	unsigned int nofs_flag;
 
+	/*
+	 * We call this under the chunk_mutex, so we want to use NOFS for this
+	 * allocation, however we don't want to change btrfs_alloc_device() to
+	 * always do NOFS because we use it in a lot of other GFP_KERNEL safe
+	 * places.
+	 */
+	nofs_flag = memalloc_nofs_save();
 	device = btrfs_alloc_device(NULL, &devid, dev_uuid);
+	memalloc_nofs_restore(nofs_flag);
 	if (IS_ERR(device))
 		return device;

Greg Kroah-Hartman

author maintainer

2020-09-15 23:15 UTC #141 lore raw

PATCH 128/177 btrfs: free data reloc tree on failed mount

From: Josef Bacik <[email protected]>

commit 9e3aa8054453d23d9f477f0cdae70a6a1ea6ec8a upstream.

While testing a weird problem with -o degraded, I noticed I was getting leaked root errors

BTRFS warning (device loop0): writable mount is not allowed due to too many missing devices BTRFS error (device loop0): open_ctree failed
BTRFS error (device loop0): leaked root -9-0 refcount 1

This is the DATA_RELOC root, which gets read before the other fs roots, but is included in the fs roots radix tree. Handle this by adding a btrfs_drop_and_free_fs_root() on the data reloc root if it exists. This is ok to do here if we fail further up because we will only drop the ref if we delete the root from the radix tree, and all other cleanup won't be duplicated.

CC [email protected] # 5.8+

Reviewed-by Nikolay Borisov <[email protected]>

Signed-off-by Josef Bacik <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/disk-io.c |    2 ++
 1 file changed, 2 insertions(+)

fs/btrfs/disk-io.c +2 -0

@@ -3446,6 +3446,8 @@ fail_block_groups:
 	btrfs_put_block_group_cache(fs_info);
 
 fail_tree_roots:
+	if (fs_info->data_reloc_root)
+		btrfs_drop_and_free_fs_root(fs_info, fs_info->data_reloc_root);
 	free_root_pointers(fs_info, true);
 	invalidate_inode_pages2(fs_info->btree_inode->i_mapping);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:16 UTC #142 lore raw

PATCH 129/177 btrfs: fix wrong address when faulting in pages in the search ioctl

Link https://lore.kernel.org/linux-btrfs/[email protected]/ open here

From: Filipe Manana <[email protected]>

commit 1c78544eaa4660096aeb6a57ec82b42cdb3bfe5a upstream.

When faulting in the pages for the user supplied buffer for the search ioctl, we are passing only the base address of the buffer to the function fault_in_pages_writeable(). This means that after the first iteration of the while loop that searches for leaves, when we have a non-zero offset, stored in 'sk_offset', we try to fault in a wrong page range.

So fix this by adding the offset in 'sk_offset' to the base address of the user supplied buffer when calling fault_in_pages_writeable().

Several users have reported that the applications compsize and bees have started to operate incorrectly since commit a48b73eca4ceb9 ("btrfs: fix potential deadlock in the search ioctl") was added to stable trees, and these applications make heavy use of the search ioctls. This fixes their issues.

Link https://github.com/kilobyte/compsize/issues/34

Fixes a48b73eca4ceb9 ("btrfs: fix potential deadlock in the search ioctl")

CC [email protected] # 4.4+

Tested-by A L <[email protected]>

Reviewed-by Josef Bacik <[email protected]>

Signed-off-by Filipe Manana <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 fs/btrfs/ioctl.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/btrfs/ioctl.c +2 -1

@@ -2193,7 +2193,8 @@ static noinline int search_ioctl(struct
 	key.offset = sk->min_offset;
 
 	while (1) {
-		ret = fault_in_pages_writeable(ubuf, *buf_size - sk_offset);
+		ret = fault_in_pages_writeable(ubuf + sk_offset,
+					       *buf_size - sk_offset);
 		if (ret)
 			break;

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #143 lore raw

PATCH 130/177 firmware_loader: fix memory leak for paged buffer

From: Prateek Sood <[email protected]>

commit 4965b8cd1bc1ffb017e5c58e622da82b55e49414 upstream.

vfree() is being called on paged buffer allocated
using alloc_page() and mapped using vmap().

Freeing of pages in vfree() relies on nr_pages of struct vm_struct. vmap() does not update nr_pages. It can lead to memory leaks.

Fixes ddaf29fd9bb6 ("firmware: Free temporary page table after vmapping")

Signed-off-by Prateek Sood <[email protected]>

Reviewed-by Takashi Iwai <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/base/firmware_loader/firmware.h |    2 ++
 drivers/base/firmware_loader/main.c     |   17 +++++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)

drivers/base/firmware_loader/firmware.h +2 -0

@@ -142,10 +142,12 @@ int assign_fw(struct firmware *fw, struc
 void fw_free_paged_buf(struct fw_priv *fw_priv);
 int fw_grow_paged_buf(struct fw_priv *fw_priv, int pages_needed);
 int fw_map_paged_buf(struct fw_priv *fw_priv);
+bool fw_is_paged_buf(struct fw_priv *fw_priv);
 #else
 static inline void fw_free_paged_buf(struct fw_priv *fw_priv) {}
 static inline int fw_grow_paged_buf(struct fw_priv *fw_priv, int pages_needed) { return -ENXIO; }
 static inline int fw_map_paged_buf(struct fw_priv *fw_priv) { return -ENXIO; }
+static inline bool fw_is_paged_buf(struct fw_priv *fw_priv) { return false; }
 #endif
 
 #endif /* __FIRMWARE_LOADER_H */

drivers/base/firmware_loader/main.c +11 -6

@@ -252,9 +252,11 @@ static void __free_fw_priv(struct kref *
 	list_del(&fw_priv->list);
 	spin_unlock(&fwc->lock);
 
-	fw_free_paged_buf(fw_priv); /* free leftover pages */
-	if (!fw_priv->allocated_size)
+	if (fw_is_paged_buf(fw_priv))
+		fw_free_paged_buf(fw_priv);
+	else if (!fw_priv->allocated_size)
 		vfree(fw_priv->data);
+
 	kfree_const(fw_priv->fw_name);
 	kfree(fw_priv);
 }

@@ -268,6 +270,11 @@ static void free_fw_priv(struct fw_priv
 }
 
 #ifdef CONFIG_FW_LOADER_PAGED_BUF
+bool fw_is_paged_buf(struct fw_priv *fw_priv)
+{
+	return fw_priv->is_paged_buf;
+}
+
 void fw_free_paged_buf(struct fw_priv *fw_priv)
 {
 	int i;

@@ -275,6 +282,8 @@ void fw_free_paged_buf(struct fw_priv *f
 	if (!fw_priv->pages)
 		return;
 
+	vunmap(fw_priv->data);
+
 	for (i = 0; i < fw_priv->nr_pages; i++)
 		__free_page(fw_priv->pages[i]);
 	kvfree(fw_priv->pages);

@@ -328,10 +337,6 @@ int fw_map_paged_buf(struct fw_priv *fw_
 	if (!fw_priv->data)
 		return -ENOMEM;
 
-	/* page table is no longer needed after mapping, let's free */
-	kvfree(fw_priv->pages);
-	fw_priv->pages = NULL;
-
 	return 0;
 }
 #endif

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #144 lore raw

PATCH 131/177 thunderbolt: Disable ports that are not implemented

From: Nikunj A. Dadhania <[email protected]>

commit 8824d19b45867be75d375385414c4f06719a11a4 upstream.

Commit 4caf2511ec49 ("thunderbolt: Add trivial .shutdown") exposes a bug in the Thunderbolt driver, that frees an unallocated id, resulting in the following spinlock bad magic bug.

[ 20.633803] BUG: spinlock bad magic on CPU#4, halt/3313
[ 20.640030] lock: 0xffff92e6ad5c97e0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 20.672139] Call Trace:
[ 20.675032] dump_stack+0x97/0xdb
[ 20.678950] ? spin_bug+0xa5/0xb0
[ 20.682865] do_raw_spin_lock+0x68/0x98
[ 20.687397] _raw_spin_lock_irqsave+0x3f/0x5d
[ 20.692535] ida_destroy+0x4f/0x124
[ 20.696657] tb_switch_release+0x6d/0xfd
[ 20.701295] device_release+0x2c/0x7d
[ 20.705622] kobject_put+0x8e/0xac
[ 20.709637] tb_stop+0x55/0x66
[ 20.713243] tb_domain_remove+0x36/0x62
[ 20.717774] nhi_remove+0x4d/0x58

Fix the issue by disabling ports that are enabled as per the EEPROM, but not implemented. While at it, update the kernel doc for the disabled field, to reflect this.

Fixes 4caf2511ec49 ("thunderbolt: Add trivial .shutdown")

Reported-by Srikanth Nandamuri <[email protected]>

Signed-off-by Nikunj A. Dadhania <[email protected]>

Signed-off-by Mika Westerberg <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/thunderbolt/switch.c |    1 +
 drivers/thunderbolt/tb.h     |    2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

drivers/thunderbolt/switch.c +1 -0

@@ -739,6 +739,7 @@ static int tb_init_port(struct tb_port *
 		if (res == -ENODEV) {
 			tb_dbg(port->sw->tb, " Port %d: not implemented\n",
 			       port->port);
+			port->disabled = true;
 			return 0;
 		}
 		return res;

drivers/thunderbolt/tb.h +1 -1

@@ -167,7 +167,7 @@ struct tb_switch {
  * @cap_adap: Offset of the adapter specific capability (%0 if not present)
  * @cap_usb4: Offset to the USB4 port capability (%0 if not present)
  * @port: Port number on switch
- * @disabled: Disabled by eeprom
+ * @disabled: Disabled by eeprom or enabled but not implemented
  * @bonded: true if the port is bonded (two lanes combined as one)
  * @dual_link_port: If the switch is connected using two ports, points
  *		    to the other port.

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #145 lore raw

PATCH 132/177 kobject: Restore old behaviour of kobject_del(NULL)

From: Andy Shevchenko <[email protected]>

commit 40b8b826a6998639dd1c26f0e127f18371e1058d upstream.

The commit 079ad2fb4bf9 ("kobject: Avoid premature parent object freeing in kobject_cleanup()") inadvertently dropped a possibility to call kobject_del() with NULL pointer. Restore the old behaviour.

Fixes 079ad2fb4bf9 ("kobject: Avoid premature parent object freeing in kobject_cleanup()")

Cc stable <[email protected]>

Reported-by Qu Wenruo <[email protected]>

Cc Heikki Krogerus <[email protected]>

Signed-off-by Andy Shevchenko <[email protected]>

Reviewed-by Qu Wenruo <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 lib/kobject.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

lib/kobject.c +5 -1

@@ -637,8 +637,12 @@ static void __kobject_del(struct kobject
  */
 void kobject_del(struct kobject *kobj)
 {
-	struct kobject *parent = kobj->parent;
+	struct kobject *parent;
 
+	if (!kobj)
+		return;
+
+	parent = kobj->parent;
 	__kobject_del(kobj);
 	kobject_put(parent);
 }

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #146 lore raw

PATCH 133/177 regulator: push allocation in regulator_init_coupling() outside of lock

From: Michał Mirosław <[email protected]>

commit 73a32129f8ccb556704a26b422f54e048bf14bd0 upstream.

Allocating memory with regulator_list_mutex held makes lockdep unhappy when memory pressure makes the system do fs_reclaim on eg. eMMC using a regulator. Push the lock inside regulator_init_coupling() after the allocation.

======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #533 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
cca78ca4 (&sbi->write_io[i][j].io_rwsem){++++}-{3:3}, at: __submit_merged_write_cond+0x104/0x154 but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (fs_reclaim){+.+.}-{0:0}:

       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       __kmalloc+0x54/0x218
       regulator_register+0x860/0x1584
       dummy_regulator_probe+0x60/0xa8

[...]
other info that might help us debug this:

Chain exists of:
  &sbi->write_io[i][j].io_rwsem --> regulator_list_mutex --> fs_reclaim

Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(regulator_list_mutex);
                               lock(fs_reclaim);

lock(&sbi->write_io[i][j].io_rwsem);
*** DEADLOCK ***

1 lock held by kswapd0/383:
#0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
[...]

Fixes d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization")

Reviewed-by Dmitry Osipenko <[email protected]>

Link https://lore.kernel.org/r/1a889cf7f61c6429c9e6b34ddcdde99be77a26b6.1597195321.git.mirq-linux@rere.qmqm.pl open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/regulator/core.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/regulator/core.c +3 -2

@@ -4978,7 +4978,10 @@ static int regulator_init_coupling(struc
 	if (!of_check_coupling_data(rdev))
 		return -EPERM;
 
+	mutex_lock(&regulator_list_mutex);
 	rdev->coupling_desc.coupler = regulator_find_coupler(rdev);
+	mutex_unlock(&regulator_list_mutex);
+
 	if (IS_ERR(rdev->coupling_desc.coupler)) {
 		err = PTR_ERR(rdev->coupling_desc.coupler);
 		rdev_err(rdev, "failed to get coupler: %d\n", err);

@@ -5184,9 +5187,7 @@ regulator_register(const struct regulato
 	if (ret < 0)
 		goto wash;
 
-	mutex_lock(&regulator_list_mutex);
 	ret = regulator_init_coupling(rdev);
-	mutex_unlock(&regulator_list_mutex);
 	if (ret < 0)
 		goto wash;

Greg Kroah-Hartman

author maintainer

2020-09-15 23:15 UTC #147 lore raw

PATCH 134/177 regulator: push allocations in create_regulator() outside of lock

From: Michał Mirosław <[email protected]>

commit 87fe29b61f9522a3d7b60a4580851f548558186f upstream.

Move all allocations outside of the regulator_lock()ed section.

======================================================
WARNING: possible circular locking dependency detected
5.7.13+ #535 Not tainted
------------------------------------------------------
f2fs_discard-179:7/702 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0

but task is already holding lock:
cb95b080 (&dcc->cmd_lock){+.+.}-{3:3}, at: __issue_discard_cmd+0xec/0x5f8

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

[...]

-> #3 (fs_reclaim){+.+.}-{0:0}:

       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       __kmalloc_track_caller+0x54/0x218
       kstrdup+0x40/0x5c
       create_regulator+0xf4/0x368
       regulator_resolve_supply+0x1a0/0x200
       regulator_register+0x9c8/0x163c

[...]

other info that might help us debug this:

Chain exists of:
  regulator_list_mutex --> &sit_i->sentry_lock --> &dcc->cmd_lock

[...]

Fixes f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")

Link https://lore.kernel.org/r/6eebc99b2474f4ffaa0405b15178ece0e7e4f608.1597195321.git.mirq-linux@rere.qmqm.pl open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/regulator/core.c |   53 ++++++++++++++++++++++++-----------------------
 1 file changed, 28 insertions(+), 25 deletions(-)

drivers/regulator/core.c +28 ~~-25~~

@@ -1579,44 +1579,53 @@ static struct regulator *create_regulato
 					  const char *supply_name)
 {
 	struct regulator *regulator;
-	char buf[REG_STR_SIZE];
-	int err, size;
+	int err;
+
+	if (dev) {
+		char buf[REG_STR_SIZE];
+		int size;
+
+		size = snprintf(buf, REG_STR_SIZE, "%s-%s",
+				dev->kobj.name, supply_name);
+		if (size >= REG_STR_SIZE)
+			return NULL;
+
+		supply_name = kstrdup(buf, GFP_KERNEL);
+		if (supply_name == NULL)
+			return NULL;
+	} else {
+		supply_name = kstrdup_const(supply_name, GFP_KERNEL);
+		if (supply_name == NULL)
+			return NULL;
+	}
 
 	regulator = kzalloc(sizeof(*regulator), GFP_KERNEL);
-	if (regulator == NULL)
+	if (regulator == NULL) {
+		kfree(supply_name);
 		return NULL;
+	}
 
-	regulator_lock(rdev);
 	regulator->rdev = rdev;
+	regulator->supply_name = supply_name;
+
+	regulator_lock(rdev);
 	list_add(&regulator->list, &rdev->consumer_list);
+	regulator_unlock(rdev);
 
 	if (dev) {
 		regulator->dev = dev;
 
 		/* Add a link to the device sysfs entry */
-		size = snprintf(buf, REG_STR_SIZE, "%s-%s",
-				dev->kobj.name, supply_name);
-		if (size >= REG_STR_SIZE)
-			goto overflow_err;
-
-		regulator->supply_name = kstrdup(buf, GFP_KERNEL);
-		if (regulator->supply_name == NULL)
-			goto overflow_err;
-
 		err = sysfs_create_link_nowarn(&rdev->dev.kobj, &dev->kobj,
-					buf);
+					       supply_name);
 		if (err) {
 			rdev_dbg(rdev, "could not add device link %s err %d\n",
 				  dev->kobj.name, err);
 			/* non-fatal */
 		}
-	} else {
-		regulator->supply_name = kstrdup_const(supply_name, GFP_KERNEL);
-		if (regulator->supply_name == NULL)
-			goto overflow_err;
 	}
 
-	regulator->debugfs = debugfs_create_dir(regulator->supply_name,
+	regulator->debugfs = debugfs_create_dir(supply_name,
 						rdev->debugfs);
 	if (!regulator->debugfs) {
 		rdev_dbg(rdev, "Failed to create debugfs directory\n");

@@ -1641,13 +1650,7 @@ static struct regulator *create_regulato
 	    _regulator_is_enabled(rdev))
 		regulator->always_on = true;
 
-	regulator_unlock(rdev);
 	return regulator;
-overflow_err:
-	list_del(&regulator->list);
-	kfree(regulator);
-	regulator_unlock(rdev);
-	return NULL;
 }
 
 static int _regulator_get_enable_time(struct regulator_dev *rdev)

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #148 lore raw

PATCH 135/177 regulator: push allocation in set_consumer_device_supply() out of lock

From: Michał Mirosław <[email protected]>

commit 5c06540165d443c6455123eb48e7f1a9b618ab34 upstream.

Pull regulator_list_mutex into set_consumer_device_supply() and keep allocations outside of it. Fourth of the fs_reclaim deadlock case.

Fixes 45389c47526d ("regulator: core: Add early supply resolution for regulators")

Link https://lore.kernel.org/r/f0380bdb3d60aeefa9693c4e234d2dcda7e56747.1597195321.git.mirq-linux@rere.qmqm.pl open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/regulator/core.c |   46 ++++++++++++++++++++++++++--------------------
 1 file changed, 26 insertions(+), 20 deletions(-)

drivers/regulator/core.c +26 ~~-20~~

@@ -1460,7 +1460,7 @@ static int set_consumer_device_supply(st
 				      const char *consumer_dev_name,
 				      const char *supply)
 {
-	struct regulator_map *node;
+	struct regulator_map *node, *new_node;
 	int has_dev;
 
 	if (supply == NULL)

@@ -1471,6 +1471,22 @@ static int set_consumer_device_supply(st
 	else
 		has_dev = 0;
 
+	new_node = kzalloc(sizeof(struct regulator_map), GFP_KERNEL);
+	if (new_node == NULL)
+		return -ENOMEM;
+
+	new_node->regulator = rdev;
+	new_node->supply = supply;
+
+	if (has_dev) {
+		new_node->dev_name = kstrdup(consumer_dev_name, GFP_KERNEL);
+		if (new_node->dev_name == NULL) {
+			kfree(new_node);
+			return -ENOMEM;
+		}
+	}
+
+	mutex_lock(&regulator_list_mutex);
 	list_for_each_entry(node, &regulator_map_list, list) {
 		if (node->dev_name && consumer_dev_name) {
 			if (strcmp(node->dev_name, consumer_dev_name) != 0)

@@ -1488,26 +1504,19 @@ static int set_consumer_device_supply(st
 			 node->regulator->desc->name,
 			 supply,
 			 dev_name(&rdev->dev), rdev_get_name(rdev));
-		return -EBUSY;
+		goto fail;
 	}
 
-	node = kzalloc(sizeof(struct regulator_map), GFP_KERNEL);
-	if (node == NULL)
-		return -ENOMEM;
-
-	node->regulator = rdev;
-	node->supply = supply;
-
-	if (has_dev) {
-		node->dev_name = kstrdup(consumer_dev_name, GFP_KERNEL);
-		if (node->dev_name == NULL) {
-			kfree(node);
-			return -ENOMEM;
-		}
-	}
+	list_add(&new_node->list, &regulator_map_list);
+	mutex_unlock(&regulator_list_mutex);
 
-	list_add(&node->list, &regulator_map_list);
 	return 0;
+
+fail:
+	mutex_unlock(&regulator_list_mutex);
+	kfree(new_node->dev_name);
+	kfree(new_node);
+	return -EBUSY;
 }
 
 static void unset_regulator_supplies(struct regulator_dev *rdev)

@@ -5196,19 +5205,16 @@ regulator_register(const struct regulato
 
 	/* add consumers devices */
 	if (init_data) {
-		mutex_lock(&regulator_list_mutex);
 		for (i = 0; i < init_data->num_consumer_supplies; i++) {
 			ret = set_consumer_device_supply(rdev,
 				init_data->consumer_supplies[i].dev_name,
 				init_data->consumer_supplies[i].supply);
 			if (ret < 0) {
-				mutex_unlock(&regulator_list_mutex);
 				dev_err(dev, "Failed to set supply %s\n",
 					init_data->consumer_supplies[i].supply);
 				goto unset_supplies;
 			}
 		}
-		mutex_unlock(&regulator_list_mutex);
 	}
 
 	if (!rdev->desc->ops->get_voltage &&

Greg Kroah-Hartman

author maintainer

2020-09-15 23:15 UTC #149 lore raw

PATCH 136/177 regulator: plug of_node leak in regulator_register()s error path

From: Michał Mirosław <[email protected]>

commit d3c731564e09b6c2ebefcd1344743a91a237d6dc upstream.

By calling device_initialize() earlier and noting that kfree(NULL) is ok, we can save a bit of code in error handling and plug of_node leak. Fixed commit already did part of the work.

Fixes 9177514ce349 ("regulator: fix memory leak on error path of regulator_register()")

Reviewed-by Vladimir Zapolskiy <[email protected]>

Acked-by Vladimir Zapolskiy <[email protected]>

Link https://lore.kernel.org/r/f5035b1b4d40745e66bacd571bbbb5e4644d21a1.1597195321.git.mirq-linux@rere.qmqm.pl open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/regulator/core.c |   13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

drivers/regulator/core.c +4 -9

@@ -5094,6 +5094,7 @@ regulator_register(const struct regulato
 		ret = -ENOMEM;
 		goto rinse;
 	}
+	device_initialize(&rdev->dev);
 
 	/*
 	 * Duplicate the config so the driver could override it after

@@ -5101,9 +5102,8 @@ regulator_register(const struct regulato
 	 */
 	config = kmemdup(cfg, sizeof(*cfg), GFP_KERNEL);
 	if (config == NULL) {
-		kfree(rdev);
 		ret = -ENOMEM;
-		goto rinse;
+		goto clean;
 	}
 
 	init_data = regulator_of_get_init_data(dev, regulator_desc, config,

@@ -5115,10 +5115,8 @@ regulator_register(const struct regulato
 	 * from a gpio extender or something else.
 	 */
 	if (PTR_ERR(init_data) == -EPROBE_DEFER) {
-		kfree(config);
-		kfree(rdev);
 		ret = -EPROBE_DEFER;
-		goto rinse;
+		goto clean;
 	}
 
 	/*

@@ -5171,7 +5169,6 @@ regulator_register(const struct regulato
 	}
 
 	/* register with sysfs */
-	device_initialize(&rdev->dev);
 	rdev->dev.class = &regulator_class;
 	rdev->dev.parent = dev;
 	dev_set_name(&rdev->dev, "regulator.%lu",

@@ -5249,13 +5246,11 @@ wash:
 	mutex_lock(&regulator_list_mutex);
 	regulator_ena_gpio_free(rdev);
 	mutex_unlock(&regulator_list_mutex);
-	put_device(&rdev->dev);
-	rdev = NULL;
 clean:
 	if (dangling_of_gpiod)
 		gpiod_put(config->ena_gpiod);
-	kfree(rdev);
 	kfree(config);
+	put_device(&rdev->dev);
 rinse:
 	if (dangling_cfg_gpiod)
 		gpiod_put(cfg->ena_gpiod);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:16 UTC #150 lore raw

PATCH 137/177 regulator: core: Fix slab-out-of-bounds in regulator_unlock_recursive()

From: Dmitry Osipenko <[email protected]>

commit 0a7416f94707c60b9f66b01c0a505b7e41375f3a upstream.

The recent commit 7d8196641ee1 ("regulator: Remove pointer table overallocation") changed the size of coupled_rdevs and now KASAN is able to detect slab-out-of-bounds problem in regulator_unlock_recursive(), which is a legit problem caused by a typo in the code. The recursive unlock function uses n_coupled value of a parent regulator for unlocking supply regulator, while supply's n_coupled should be used. In practice problem may only affect platforms that use coupled regulators.

Cc [email protected] # 5.0+

Fixes f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")

Signed-off-by Dmitry Osipenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/regulator/core.c |   15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

drivers/regulator/core.c +9 -6

@@ -235,8 +235,8 @@ static bool regulator_supply_is_couple(s
 static void regulator_unlock_recursive(struct regulator_dev *rdev,
 				       unsigned int n_coupled)
 {
-	struct regulator_dev *c_rdev;
-	int i;
+	struct regulator_dev *c_rdev, *supply_rdev;
+	int i, supply_n_coupled;
 
 	for (i = n_coupled; i > 0; i--) {
 		c_rdev = rdev->coupling_desc.coupled_rdevs[i - 1];

@@ -244,10 +244,13 @@ static void regulator_unlock_recursive(s
 		if (!c_rdev)
 			continue;
 
-		if (c_rdev->supply && !regulator_supply_is_couple(c_rdev))
-			regulator_unlock_recursive(
-					c_rdev->supply->rdev,
-					c_rdev->coupling_desc.n_coupled);
+		if (c_rdev->supply && !regulator_supply_is_couple(c_rdev)) {
+			supply_rdev = c_rdev->supply->rdev;
+			supply_n_coupled = supply_rdev->coupling_desc.n_coupled;
+
+			regulator_unlock_recursive(supply_rdev,
+						   supply_n_coupled);
+		}
 
 		regulator_unlock(c_rdev);
 	}

Greg Kroah-Hartman

author maintainer

2020-09-15 23:15 UTC #151 lore raw

PATCH 138/177 misc: eeprom: at24: register nvmem only after eeprom is ready to use

From: Vadym Kochan <[email protected]>

commit 45df80d7605c25055a85fbc5a8446c81c6c0ca24 upstream.

During nvmem_register() the nvmem core sends notifications when:

- cell added
- nvmem added

and during these notifications some callback func may access the nvmem device, which will fail in case of at24 eeprom because regulator and pm are enabled after nvmem_register().

Fixes cd5676db0574 ("misc: eeprom: at24: support pm_runtime control")

Fixes b20eb4c1f026 ("eeprom: at24: drop unnecessary label")

Signed-off-by Vadym Kochan <[email protected]>

Signed-off-by Bartosz Golaszewski <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/misc/eeprom/at24.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

drivers/misc/eeprom/at24.c +7 -4

@@ -692,10 +692,6 @@ static int at24_probe(struct i2c_client
 	nvmem_config.word_size = 1;
 	nvmem_config.size = byte_len;
 
-	at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
-	if (IS_ERR(at24->nvmem))
-		return PTR_ERR(at24->nvmem);
-
 	i2c_set_clientdata(client, at24);
 
 	err = regulator_enable(at24->vcc_reg);

@@ -708,6 +704,13 @@ static int at24_probe(struct i2c_client
 	pm_runtime_set_active(dev);
 	pm_runtime_enable(dev);
 
+	at24->nvmem = devm_nvmem_register(dev, &nvmem_config);
+	if (IS_ERR(at24->nvmem)) {
+		pm_runtime_disable(dev);
+		regulator_disable(at24->vcc_reg);
+		return PTR_ERR(at24->nvmem);
+	}
+
 	/*
 	 * Perform a one-byte test read to verify that the
 	 * chip is functional.

Greg Kroah-Hartman

author maintainer

2020-09-15 23:19 UTC #152 lore raw

PATCH 139/177 scsi: target: iscsi: Fix data digest calculation

From: Varun Prakash <[email protected]>

commit 5528d03183fe5243416c706f64b1faa518b05130 upstream.

Current code does not consider 'page_off' in data digest calculation. To fix this, add a local variable 'first_sg' and set first_sg.offset to sg->offset + page_off.

Link https://lore.kernel.org/r/[email protected] open here

Fixes e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1")

Reviewed-by Mike Christie <[email protected]>

Signed-off-by Varun Prakash <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/target/iscsi/iscsi_target.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

drivers/target/iscsi/iscsi_target.c +15 -2

@@ -1389,14 +1389,27 @@ static u32 iscsit_do_crypto_hash_sg(
 	sg = cmd->first_data_sg;
 	page_off = cmd->first_data_sg_off;
 
+	if (data_length && page_off) {
+		struct scatterlist first_sg;
+		u32 len = min_t(u32, data_length, sg->length - page_off);
+
+		sg_init_table(&first_sg, 1);
+		sg_set_page(&first_sg, sg_page(sg), len, sg->offset + page_off);
+
+		ahash_request_set_crypt(hash, &first_sg, NULL, len);
+		crypto_ahash_update(hash);
+
+		data_length -= len;
+		sg = sg_next(sg);
+	}
+
 	while (data_length) {
-		u32 cur_len = min_t(u32, data_length, (sg->length - page_off));
+		u32 cur_len = min_t(u32, data_length, sg->length);
 
 		ahash_request_set_crypt(hash, sg, NULL, cur_len);
 		crypto_ahash_update(hash);
 
 		data_length -= cur_len;
-		page_off = 0;
 		/* iscsit_map_iovec has already checked for invalid sg pointers */
 		sg = sg_next(sg);
 	}

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #153 lore raw

PATCH 140/177 scsi: lpfc: Fix setting IRQ affinity with an empty CPU mask

From: James Smart <[email protected]>

commit 7ac836ebcb1509845fe7d66314f469f8e709da93 upstream.

Some systems are reporting the following log message during driver unload or system shutdown:

ics_rtas_set_affinity: No online cpus in the mask

A prior commit introduced the writing of an empty affinity mask in calls to irq_set_affinity_hint() when disabling interrupts or when there are no remaining online CPUs to service an eq interrupt. At least some ppc64 systems are checking whether affinity masks are empty or not.

Do not call irq_set_affinity_hint() with an empty CPU mask.

Fixes dcaa21367938 ("scsi: lpfc: Change default IRQ model on AMD architectures")

Link https://lore.kernel.org/r/[email protected] open here

Cc <[email protected]> # v5.5+

Co-developed-by Dick Kennedy <[email protected]>

Signed-off-by Dick Kennedy <[email protected]>

Signed-off-by James Smart <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/scsi/lpfc/lpfc_init.c |    1 -
 1 file changed, 1 deletion(-)

drivers/scsi/lpfc/lpfc_init.c +0 -1

@@ -11257,7 +11257,6 @@ lpfc_irq_clear_aff(struct lpfc_hba_eq_hd
 {
 	cpumask_clear(&eqhdl->aff_mask);
 	irq_clear_status_flags(eqhdl->irq, IRQ_NO_BALANCING);
-	irq_set_affinity_hint(eqhdl->irq, &eqhdl->aff_mask);
 }
 
 /**

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #154 lore raw

PATCH 141/177 scsi: target: iscsi: Fix hang in iscsit_access_np() when getting tpg->np_login_sem

From: Hou Pu <[email protected]>

commit ed43ffea78dcc97db3f561da834f1a49c8961e33 upstream.

The iSCSI target login thread might get stuck with the following stack:

cat /proc/pidof iscsi_np/stack

[<0>] down_interruptible+0x42/0x50
[<0>] iscsit_access_np+0xe3/0x167
[<0>] iscsi_target_locate_portal+0x695/0x8ac
[<0>] __iscsi_target_login_thread+0x855/0xb82
[<0>] iscsi_target_login_thread+0x2f/0x5a
[<0>] kthread+0xfa/0x130
[<0>] ret_from_fork+0x1f/0x30

This can be reproduced via the following steps:

1. Initiator A tries to log in to iqn1-tpg1 on port 3260. After finishing PDU exchange in the login thread and before the negotiation is finished the the network link goes down. At this point A has not finished login and tpg->np_login_sem is held.

2. Initiator B tries to log in to iqn2-tpg1 on port 3260. After finishing PDU exchange in the login thread the target expects to process remaining login PDUs in workqueue context.

3. Initiator A' tries to log in to iqn1-tpg1 on port 3260 from a new socket. A' will wait for tpg->np_login_sem with np->np_login_timer loaded to wait for at most 15 seconds. The lock is held by A so A' eventually times out.

4. Before A' got timeout initiator B gets negotiation failed and calls iscsi_target_login_drop()->iscsi_target_login_sess_out(). The np->np_login_timer is canceled and initiator A' will hang forever. Because A' is now in the login thread, no new login requests can be serviced.

Fix this by moving iscsi_stop_login_thread_timer() out of iscsi_target_login_sess_out(). Also remove iscsi_np parameter from iscsi_target_login_sess_out().

Link https://lore.kernel.org/r/[email protected] open here

Reviewed-by Mike Christie <[email protected]>

Signed-off-by Hou Pu <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/target/iscsi/iscsi_target_login.c |    6 +++---
 drivers/target/iscsi/iscsi_target_login.h |    3 +--
 drivers/target/iscsi/iscsi_target_nego.c  |    3 +--
 3 files changed, 5 insertions(+), 7 deletions(-)

drivers/target/iscsi/iscsi_target_login.c +3 -3

@@ -1149,7 +1149,7 @@ void iscsit_free_conn(struct iscsi_conn
 }
 
 void iscsi_target_login_sess_out(struct iscsi_conn *conn,
-		struct iscsi_np *np, bool zero_tsih, bool new_sess)
+				 bool zero_tsih, bool new_sess)
 {
 	if (!new_sess)
 		goto old_sess_out;

@@ -1167,7 +1167,6 @@ void iscsi_target_login_sess_out(struct
 	conn->sess = NULL;
 
 old_sess_out:
-	iscsi_stop_login_thread_timer(np);
 	/*
 	 * If login negotiation fails check if the Time2Retain timer
 	 * needs to be restarted.

@@ -1407,8 +1406,9 @@ static int __iscsi_target_login_thread(s
 new_sess_out:
 	new_sess = true;
 old_sess_out:
+	iscsi_stop_login_thread_timer(np);
 	tpg_np = conn->tpg_np;
-	iscsi_target_login_sess_out(conn, np, zero_tsih, new_sess);
+	iscsi_target_login_sess_out(conn, zero_tsih, new_sess);
 	new_sess = false;
 
 	if (tpg) {

drivers/target/iscsi/iscsi_target_login.h +1 -2

@@ -22,8 +22,7 @@ extern int iscsit_put_login_tx(struct is
 extern void iscsit_free_conn(struct iscsi_conn *);
 extern int iscsit_start_kthreads(struct iscsi_conn *);
 extern void iscsi_post_login_handler(struct iscsi_np *, struct iscsi_conn *, u8);
-extern void iscsi_target_login_sess_out(struct iscsi_conn *, struct iscsi_np *,
-				bool, bool);
+extern void iscsi_target_login_sess_out(struct iscsi_conn *, bool, bool);
 extern int iscsi_target_login_thread(void *);
 extern void iscsi_handle_login_thread_timeout(struct timer_list *t);

drivers/target/iscsi/iscsi_target_nego.c +1 -2

@@ -535,12 +535,11 @@ static bool iscsi_target_sk_check_and_cl
 
 static void iscsi_target_login_drop(struct iscsi_conn *conn, struct iscsi_login *login)
 {
-	struct iscsi_np *np = login->np;
 	bool zero_tsih = login->zero_tsih;
 
 	iscsi_remove_failed_auth_entry(conn);
 	iscsi_target_nego_release(conn);
-	iscsi_target_login_sess_out(conn, np, zero_tsih, true);
+	iscsi_target_login_sess_out(conn, zero_tsih, true);
 }
 
 struct conn_timeout {

Greg Kroah-Hartman

author maintainer

2020-09-15 23:15 UTC #155 lore raw

PATCH 142/177 drm/tve200: Stabilize enable/disable

From: Linus Walleij <[email protected]>

commit f71800228dc74711c3df43854ce7089562a3bc2d upstream.

The TVE200 will occasionally print a bunch of lost interrupts and similar dmesg messages, sometimes during boot and sometimes after disabling and coming back to enablement. This is probably because the hardware is left in an unknown state by the boot loader that displays a logo.

This can be fixed by bringing the controller into a known state by resetting the controller while enabling it. We retry reset 5 times like the vendor driver does. We also put the controller into reset before de-clocking it and clear all interrupts before enabling the vblank IRQ.

This makes the video enable/disable/enable cycle rock solid on the D-Link DIR-685. Tested extensively.

Signed-off-by Linus Walleij <[email protected]>

Acked-by Daniel Vetter <[email protected]>

Link https://patchwork.freedesktop.org/patch/msgid/[email protected]

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/tve200/tve200_display.c |   22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

drivers/gpu/drm/tve200/tve200_display.c +21 -1

@@ -14,6 +14,7 @@
 #include <linux/version.h>
 #include <linux/dma-buf.h>
 #include <linux/of_graph.h>
+#include <linux/delay.h>
 
 #include <drm/drm_fb_cma_helper.h>
 #include <drm/drm_fourcc.h>

@@ -130,9 +131,25 @@ static void tve200_display_enable(struct
 	struct drm_connector *connector = priv->connector;
 	u32 format = fb->format->format;
 	u32 ctrl1 = 0;
+	int retries;
 
 	clk_prepare_enable(priv->clk);
 
+	/* Reset the TVE200 and wait for it to come back online */
+	writel(TVE200_CTRL_4_RESET, priv->regs + TVE200_CTRL_4);
+	for (retries = 0; retries < 5; retries++) {
+		usleep_range(30000, 50000);
+		if (readl(priv->regs + TVE200_CTRL_4) & TVE200_CTRL_4_RESET)
+			continue;
+		else
+			break;
+	}
+	if (retries == 5 &&
+	    readl(priv->regs + TVE200_CTRL_4) & TVE200_CTRL_4_RESET) {
+		dev_err(drm->dev, "can't get hardware out of reset\n");
+		return;
+	}
+
 	/* Function 1 */
 	ctrl1 |= TVE200_CTRL_CSMODE;
 	/* Interlace mode for CCIR656: parameterize? */

@@ -230,8 +247,9 @@ static void tve200_display_disable(struc
 
 	drm_crtc_vblank_off(crtc);
 
-	/* Disable and Power Down */
+	/* Disable put into reset and Power Down */
 	writel(0, priv->regs + TVE200_CTRL);
+	writel(TVE200_CTRL_4_RESET, priv->regs + TVE200_CTRL_4);
 
 	clk_disable_unprepare(priv->clk);
 }

@@ -279,6 +297,8 @@ static int tve200_display_enable_vblank(
 	struct drm_device *drm = crtc->dev;
 	struct tve200_drm_dev_private *priv = drm->dev_private;
 
+	/* Clear any IRQs and enable */
+	writel(0xFF, priv->regs + TVE200_INT_CLR);
 	writel(TVE200_INT_V_STATUS, priv->regs + TVE200_INT_EN);
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2020-09-15 23:17 UTC #156 lore raw

PATCH 143/177 drm/msm: Split the a5xx preemption record

From: Jordan Crouse <[email protected]>

commit 34221545d2069dc947131f42392fd4cebabe1b39 upstream.

The main a5xx preemption record can be marked as privileged to protect it from user access but the counters storage needs to be remain unprivileged. Split the buffers and mark the critical memory as privileged.

Signed-off-by Jordan Crouse <[email protected]>

Signed-off-by Rob Clark <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h     |    1 +
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c |   25 ++++++++++++++++++++-----
 2 files changed, 21 insertions(+), 5 deletions(-)

drivers/gpu/drm/msm/adreno/a5xx_gpu.h +1 -0

@@ -31,6 +31,7 @@ struct a5xx_gpu {
 	struct msm_ringbuffer *next_ring;
 
 	struct drm_gem_object *preempt_bo[MSM_GPU_MAX_RINGS];
+	struct drm_gem_object *preempt_counters_bo[MSM_GPU_MAX_RINGS];
 	struct a5xx_preempt_record *preempt[MSM_GPU_MAX_RINGS];
 	uint64_t preempt_iova[MSM_GPU_MAX_RINGS];

drivers/gpu/drm/msm/adreno/a5xx_preempt.c +20 -5

@@ -226,19 +226,31 @@ static int preempt_init_ring(struct a5xx
 	struct adreno_gpu *adreno_gpu = &a5xx_gpu->base;
 	struct msm_gpu *gpu = &adreno_gpu->base;
 	struct a5xx_preempt_record *ptr;
-	struct drm_gem_object *bo = NULL;
-	u64 iova = 0;
+	void *counters;
+	struct drm_gem_object *bo = NULL, *counters_bo = NULL;
+	u64 iova = 0, counters_iova = 0;
 
 	ptr = msm_gem_kernel_new(gpu->dev,
 		A5XX_PREEMPT_RECORD_SIZE + A5XX_PREEMPT_COUNTER_SIZE,
-		MSM_BO_UNCACHED, gpu->aspace, &bo, &iova);
+		MSM_BO_UNCACHED | MSM_BO_MAP_PRIV, gpu->aspace, &bo, &iova);
 
 	if (IS_ERR(ptr))
 		return PTR_ERR(ptr);
 
+	/* The buffer to store counters needs to be unprivileged */
+	counters = msm_gem_kernel_new(gpu->dev,
+		A5XX_PREEMPT_COUNTER_SIZE,
+		MSM_BO_UNCACHED, gpu->aspace, &counters_bo, &counters_iova);
+	if (IS_ERR(counters)) {
+		msm_gem_kernel_put(bo, gpu->aspace, true);
+		return PTR_ERR(counters);
+	}
+
 	msm_gem_object_set_name(bo, "preempt");
+	msm_gem_object_set_name(counters_bo, "preempt_counters");
 
 	a5xx_gpu->preempt_bo[ring->id] = bo;
+	a5xx_gpu->preempt_counters_bo[ring->id] = counters_bo;
 	a5xx_gpu->preempt_iova[ring->id] = iova;
 	a5xx_gpu->preempt[ring->id] = ptr;

@@ -249,7 +261,7 @@ static int preempt_init_ring(struct a5xx
 	ptr->data = 0;
 	ptr->cntl = MSM_GPU_RB_CNTL_DEFAULT;
 	ptr->rptr_addr = rbmemptr(ring, rptr);
-	ptr->counter = iova + A5XX_PREEMPT_RECORD_SIZE;
+	ptr->counter = counters_iova;
 
 	return 0;
 }

@@ -260,8 +272,11 @@ void a5xx_preempt_fini(struct msm_gpu *g
 	struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
 	int i;
 
-	for (i = 0; i < gpu->nr_rings; i++)
+	for (i = 0; i < gpu->nr_rings; i++) {
 		msm_gem_kernel_put(a5xx_gpu->preempt_bo[i], gpu->aspace, true);
+		msm_gem_kernel_put(a5xx_gpu->preempt_counters_bo[i],
+			gpu->aspace, true);
+	}
 }
 
 void a5xx_preempt_init(struct msm_gpu *gpu)

Greg Kroah-Hartman

author maintainer

2020-09-15 23:19 UTC #157 lore raw

PATCH 144/177 drm/msm: Disable preemption on all 5xx targets

From: Jordan Crouse <[email protected]>

commit 7b3f3948c8b7053d771acc9f79810cc410f5e2e0 upstream.

Temporarily disable preemption on a5xx targets pending some improvements to protect the RPTR shadow from being corrupted.

Signed-off-by Jordan Crouse <[email protected]>

Signed-off-by Rob Clark <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/gpu/drm/msm/adreno/a5xx_gpu.c +2 -1

@@ -1510,7 +1510,8 @@ struct msm_gpu *a5xx_gpu_init(struct drm
 
 	check_speed_bin(&pdev->dev);
 
-	ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 4);
+	/* Restricting nr_rings to 1 to temporarily disable preemption */
+	ret = adreno_gpu_init(dev, pdev, adreno_gpu, &funcs, 1);
 	if (ret) {
 		a5xx_destroy(&(a5xx_gpu->base.base));
 		return ERR_PTR(ret);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:15 UTC #158 lore raw

PATCH 145/177 drm/msm: Disable the RPTR shadow

From: Jordan Crouse <[email protected]>

commit f6828e0c4045f03f9cf2df6c2a768102641183f4 upstream.

Disable the RPTR shadow across all targets. It will be selectively re-enabled later for targets that need it.

Signed-off-by Jordan Crouse <[email protected]>

Signed-off-by Rob Clark <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/gpu/drm/msm/adreno/a2xx_gpu.c   |    5 +++++
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |   10 ++++++++++
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |   10 ++++++++++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |   11 +++++++++--
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |    7 +++++++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |   27 ++-------------------------
 6 files changed, 43 insertions(+), 27 deletions(-)

drivers/gpu/drm/msm/adreno/a2xx_gpu.c +5 -0

@@ -164,6 +164,11 @@ static int a2xx_hw_init(struct msm_gpu *
 	if (ret)
 		return ret;
 
+	gpu_write(gpu, REG_AXXX_CP_RB_CNTL,
+		MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+	gpu_write(gpu, REG_AXXX_CP_RB_BASE, lower_32_bits(gpu->rb[0]->iova));
+
 	/* NOTE: PM4/micro-engine firmware registers look to be the same
 	 * for a2xx and a3xx.. we could possibly push that part down to
 	 * adreno_gpu base class.  Or push both PM4 and PFP but

drivers/gpu/drm/msm/adreno/a3xx_gpu.c +10 -0

@@ -211,6 +211,16 @@ static int a3xx_hw_init(struct msm_gpu *
 	if (ret)
 		return ret;
 
+	/*
+	 * Use the default ringbuffer size and block size but disable the RPTR
+	 * shadow
+	 */
+	gpu_write(gpu, REG_AXXX_CP_RB_CNTL,
+		MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+	/* Set the ringbuffer address */
+	gpu_write(gpu, REG_AXXX_CP_RB_BASE, lower_32_bits(gpu->rb[0]->iova));
+
 	/* setup access protection: */
 	gpu_write(gpu, REG_A3XX_CP_PROTECT_CTRL, 0x00000007);

drivers/gpu/drm/msm/adreno/a4xx_gpu.c +10 -0

@@ -267,6 +267,16 @@ static int a4xx_hw_init(struct msm_gpu *
 	if (ret)
 		return ret;
 
+	/*
+	 * Use the default ringbuffer size and block size but disable the RPTR
+	 * shadow
+	 */
+	gpu_write(gpu, REG_A4XX_CP_RB_CNTL,
+		MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+	/* Set the ringbuffer address */
+	gpu_write(gpu, REG_A4XX_CP_RB_BASE, lower_32_bits(gpu->rb[0]->iova));
+
 	/* Load PM4: */
 	ptr = (uint32_t *)(adreno_gpu->fw[ADRENO_FW_PM4]->data);
 	len = adreno_gpu->fw[ADRENO_FW_PM4]->size / 4;

drivers/gpu/drm/msm/adreno/a5xx_gpu.c +9 -2

@@ -702,8 +702,6 @@ static int a5xx_hw_init(struct msm_gpu *
 	if (ret)
 		return ret;
 
-	a5xx_preempt_hw_init(gpu);
-
 	if (!adreno_is_a510(adreno_gpu))
 		a5xx_gpmu_ucode_init(gpu);

@@ -711,6 +709,15 @@ static int a5xx_hw_init(struct msm_gpu *
 	if (ret)
 		return ret;
 
+	/* Set the ringbuffer address */
+	gpu_write64(gpu, REG_A5XX_CP_RB_BASE, REG_A5XX_CP_RB_BASE_HI,
+		gpu->rb[0]->iova);
+
+	gpu_write(gpu, REG_A5XX_CP_RB_CNTL,
+		MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
+	a5xx_preempt_hw_init(gpu);
+
 	/* Disable the interrupts through the initial bringup stage */
 	gpu_write(gpu, REG_A5XX_RBBM_INT_0_MASK, A5XX_INT_MASK);

drivers/gpu/drm/msm/adreno/a6xx_gpu.c +7 -0

@@ -557,6 +557,13 @@ static int a6xx_hw_init(struct msm_gpu *
 	if (ret)
 		goto out;
 
+	/* Set the ringbuffer address */
+	gpu_write64(gpu, REG_A6XX_CP_RB_BASE, REG_A6XX_CP_RB_BASE_HI,
+		gpu->rb[0]->iova);
+
+	gpu_write(gpu, REG_A6XX_CP_RB_CNTL,
+		MSM_GPU_RB_CNTL_DEFAULT | AXXX_CP_RB_CNTL_NO_UPDATE);
+
 	/* Always come up on rb 0 */
 	a6xx_gpu->cur_ring = gpu->rb[0];

drivers/gpu/drm/msm/adreno/adreno_gpu.c +2 ~~-25~~

@@ -400,26 +400,6 @@ int adreno_hw_init(struct msm_gpu *gpu)
 		ring->memptrs->rptr = 0;
 	}
 
-	/*
-	 * Setup REG_CP_RB_CNTL.  The same value is used across targets (with
-	 * the excpetion of A430 that disables the RPTR shadow) - the cacluation
-	 * for the ringbuffer size and block size is moved to msm_gpu.h for the
-	 * pre-processor to deal with and the A430 variant is ORed in here
-	 */
-	adreno_gpu_write(adreno_gpu, REG_ADRENO_CP_RB_CNTL,
-		MSM_GPU_RB_CNTL_DEFAULT |
-		(adreno_is_a430(adreno_gpu) ? AXXX_CP_RB_CNTL_NO_UPDATE : 0));
-
-	/* Setup ringbuffer address - use ringbuffer[0] for GPU init */
-	adreno_gpu_write64(adreno_gpu, REG_ADRENO_CP_RB_BASE,
-		REG_ADRENO_CP_RB_BASE_HI, gpu->rb[0]->iova);
-
-	if (!adreno_is_a430(adreno_gpu)) {
-		adreno_gpu_write64(adreno_gpu, REG_ADRENO_CP_RB_RPTR_ADDR,
-			REG_ADRENO_CP_RB_RPTR_ADDR_HI,
-			rbmemptr(gpu->rb[0], rptr));
-	}
-
 	return 0;
 }

@@ -427,11 +407,8 @@ int adreno_hw_init(struct msm_gpu *gpu)
 static uint32_t get_rptr(struct adreno_gpu *adreno_gpu,
 		struct msm_ringbuffer *ring)
 {
-	if (adreno_is_a430(adreno_gpu))
-		return ring->memptrs->rptr = adreno_gpu_read(
-			adreno_gpu, REG_ADRENO_CP_RB_RPTR);
-	else
-		return ring->memptrs->rptr;
+	return ring->memptrs->rptr = adreno_gpu_read(
+		adreno_gpu, REG_ADRENO_CP_RB_RPTR);
 }
 
 struct msm_ringbuffer *adreno_active_ring(struct msm_gpu *gpu)

Greg Kroah-Hartman

author maintainer

2020-09-15 14:40 UTC #159 lore raw

PATCH 146/177 mmc: sdio: Use mmc_pre_req() / mmc_post_req()

From: Adrian Hunter <[email protected]>

commit f0c393e2104e48c8a881719a8bd37996f71b0aee upstream.

SDHCI changed from using a tasklet to finish requests, to using an IRQ thread i.e. commit c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet"). Because this increased the latency to complete requests, a preparatory change was made to complete the request from the IRQ handler if possible i.e. commit 19d2f695f4e827 ("mmc: sdhci: Call mmc_request_done() from IRQ handler if possible"). That alleviated the situation for MMC block devices because the MMC block driver makes use of mmc_pre_req() and mmc_post_req() so that successful requests are completed in the IRQ handler and any DMA unmapping is handled separately in mmc_post_req(). However SDIO was still affected, and an example has been reported with up to 20% degradation in performance.

Looking at SDIO I/O helper functions, sdio_io_rw_ext_helper() appeared to be a possible candidate for making use of asynchronous requests within its I/O loops, but analysis revealed that these loops almost never iterate more than once, so the complexity of the change would not be warrented.

Instead, mmc_pre_req() and mmc_post_req() are added before and after I/O submission (mmc_wait_for_req) in mmc_io_rw_extended(). This still has the potential benefit of reducing the duration of interrupt handlers, as well as addressing the latency issue for SDHCI. It also seems a more reasonable solution than forcing drivers to do everything in the IRQ handler.

Reported-by Dmitry Osipenko <[email protected]>

Fixes c07a48c2651965 ("mmc: sdhci: Remove finish_tasklet")

Signed-off-by Adrian Hunter <[email protected]>

Tested-by Dmitry Osipenko <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/core/sdio_ops.c |   39 ++++++++++++++++++++++-----------------
 1 file changed, 22 insertions(+), 17 deletions(-)

drivers/mmc/core/sdio_ops.c +22 ~~-17~~

@@ -121,6 +121,7 @@ int mmc_io_rw_extended(struct mmc_card *
 	struct sg_table sgtable;
 	unsigned int nents, left_size, i;
 	unsigned int seg_size = card->host->max_seg_size;
+	int err;
 
 	WARN_ON(blksz == 0);

@@ -170,28 +171,32 @@ int mmc_io_rw_extended(struct mmc_card *
 
 	mmc_set_data_timeout(&data, card);
 
-	mmc_wait_for_req(card->host, &mrq);
+	mmc_pre_req(card->host, &mrq);
 
-	if (nents > 1)
-		sg_free_table(&sgtable);
+	mmc_wait_for_req(card->host, &mrq);
 
 	if (cmd.error)
-		return cmd.error;
-	if (data.error)
-		return data.error;
-
-	if (mmc_host_is_spi(card->host)) {
+		err = cmd.error;
+	else if (data.error)
+		err = data.error;
+	else if (mmc_host_is_spi(card->host))
 		/* host driver already reported errors */
-	} else {
-		if (cmd.resp[0] & R5_ERROR)
-			return -EIO;
-		if (cmd.resp[0] & R5_FUNCTION_NUMBER)
-			return -EINVAL;
-		if (cmd.resp[0] & R5_OUT_OF_RANGE)
-			return -ERANGE;
-	}
+		err = 0;
+	else if (cmd.resp[0] & R5_ERROR)
+		err = -EIO;
+	else if (cmd.resp[0] & R5_FUNCTION_NUMBER)
+		err = -EINVAL;
+	else if (cmd.resp[0] & R5_OUT_OF_RANGE)
+		err = -ERANGE;
+	else
+		err = 0;
+
+	mmc_post_req(card->host, &mrq, err);
+
+	if (nents > 1)
+		sg_free_table(&sgtable);
 
-	return 0;
+	return err;
 }
 
 int sdio_reset(struct mmc_host *host)

Greg Kroah-Hartman

author maintainer

2020-09-15 23:12 UTC #160 lore raw

PATCH 147/177 mmc: sdhci-of-esdhc: Dont walk device-tree on every interrupt

From: Chris Packham <[email protected]>

commit 060522d89705f9d961ef1762dc1468645dd21fbd upstream.

Commit b214fe592ab7 ("mmc: sdhci-of-esdhc: add erratum eSDHC7 support") added code to check for a specific compatible string in the device-tree on every esdhc interrupat. Instead of doing this record the quirk in struct sdhci_esdhc and lookup the struct in esdhc_irq.

Signed-off-by Chris Packham <[email protected]>

Link https://lore.kernel.org/r/[email protected] open here

Fixes b214fe592ab7 ("mmc: sdhci-of-esdhc: add erratum eSDHC7 support")

Signed-off-by Ulf Hansson <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/mmc/host/sdhci-of-esdhc.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

drivers/mmc/host/sdhci-of-esdhc.c +7 -3

@@ -81,6 +81,7 @@ struct sdhci_esdhc {
 	bool quirk_tuning_erratum_type2;
 	bool quirk_ignore_data_inhibit;
 	bool quirk_delay_before_data_reset;
+	bool quirk_trans_complete_erratum;
 	bool in_sw_tuning;
 	unsigned int peripheral_clock;
 	const struct esdhc_clk_fixup *clk_fixup;

@@ -1177,10 +1178,11 @@ static void esdhc_set_uhs_signaling(stru
 
 static u32 esdhc_irq(struct sdhci_host *host, u32 intmask)
 {
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_esdhc *esdhc = sdhci_pltfm_priv(pltfm_host);
 	u32 command;
 
-	if (of_find_compatible_node(NULL, NULL,
-				"fsl,p2020-esdhc")) {
+	if (esdhc->quirk_trans_complete_erratum) {
 		command = SDHCI_GET_CMD(sdhci_readw(host,
 					SDHCI_COMMAND));
 		if (command == MMC_WRITE_MULTIPLE_BLOCK &&

@@ -1334,8 +1336,10 @@ static void esdhc_init(struct platform_d
 		esdhc->clk_fixup = match->data;
 	np = pdev->dev.of_node;
 
-	if (of_device_is_compatible(np, "fsl,p2020-esdhc"))
+	if (of_device_is_compatible(np, "fsl,p2020-esdhc")) {
 		esdhc->quirk_delay_before_data_reset = true;
+		esdhc->quirk_trans_complete_erratum = true;
+	}
 
 	clk = of_clk_get(np, 0);
 	if (!IS_ERR(clk)) {

Greg Kroah-Hartman

author maintainer

2020-09-15 23:12 UTC #161 lore raw

PATCH 148/177 nvme: Revert: Fix controller creation races with teardown flow

From: James Smart <[email protected]>

commit b63de8400a6e1001b5732286cf6f5ec27799b7b4 upstream.

The indicated patch introduced a barrier in the sysfs_delete attribute for the controller that rejects the request if the controller isn't created. "Created" is defined as at least 1 call to nvme_start_ctrl().

This is problematic in error-injection testing. If an error occurs on the initial attempt to create an association and the controller enters reconnect(s) attempts, the admin cannot delete the controller until either there is a successful association created or ctrl_loss_tmo times out.

Where this issue is particularly hurtful is when the "admin" is the nvme-cli, it is performing a connection to a discovery controller, and it is initiated via auto-connect scripts. With the FC transport, if the first connection attempt fails, the controller enters a normal reconnect state but returns control to the cli thread that created the controller. In this scenario, the cli attempts to read the discovery log via ioctl, which fails, causing the cli to see it as an empty log and then proceeds to delete the discovery controller. The delete is rejected and the controller is left live. If the discovery controller reconnect then succeeds, there is no action to delete it, and it sits live doing nothing.

Cc <[email protected]> # v5.7+

Fixes ce1518139e69 ("nvme: Fix controller creation races with teardown flow")

Signed-off-by James Smart <[email protected]>

CC Israel Rukshin <[email protected]>

CC Max Gurtovoy <[email protected]>

CC Christoph Hellwig <[email protected]>

CC Keith Busch <[email protected]>

CC Sagi Grimberg <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/nvme/host/core.c |    5 -----
 drivers/nvme/host/nvme.h |    1 -
 2 files changed, 6 deletions(-)

drivers/nvme/host/core.c +0 -5

@@ -3324,10 +3324,6 @@ static ssize_t nvme_sysfs_delete(struct
 {
 	struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
 
-	/* Can't delete non-created controllers */
-	if (!ctrl->created)
-		return -EBUSY;
-
 	if (device_remove_file_self(dev, attr))
 		nvme_delete_ctrl_sync(ctrl);
 	return count;

@@ -4129,7 +4125,6 @@ void nvme_start_ctrl(struct nvme_ctrl *c
 		nvme_queue_scan(ctrl);
 		nvme_start_queues(ctrl);
 	}
-	ctrl->created = true;
 }
 EXPORT_SYMBOL_GPL(nvme_start_ctrl);

drivers/nvme/host/nvme.h +0 -1

@@ -271,7 +271,6 @@ struct nvme_ctrl {
 	struct nvme_command ka_cmd;
 	struct work_struct fw_act_work;
 	unsigned long events;
-	bool created;
 
 #ifdef CONFIG_NVME_MULTIPATH
 	/* asymmetric namespace access: */

Greg Kroah-Hartman

author maintainer

2020-09-15 23:07 UTC #162 lore raw

PATCH 149/177 rbd: require global CAP_SYS_ADMIN for mapping and unmapping

From: Ilya Dryomov <[email protected]>

commit f44d04e696feaf13d192d942c4f14ad2e117065a upstream.

It turns out that currently we rely only on sysfs attribute permissions:

  $ ll /sys/bus/rbd/{add*,remove*}
  --w------- 1 root root 4096 Sep  3 20:37 /sys/bus/rbd/add
  --w------- 1 root root 4096 Sep  3 20:37 /sys/bus/rbd/add_single_major
  --w------- 1 root root 4096 Sep  3 20:37 /sys/bus/rbd/remove
  --w------- 1 root root 4096 Sep  3 20:38 /sys/bus/rbd/remove_single_major

This means that images can be mapped and unmapped (i.e. block devices can be created and deleted) by a UID 0 process even after it drops all privileges or by any process with CAP_DAC_OVERRIDE in its user namespace as long as UID 0 is mapped into that user namespace.

Be consistent with other virtual block devices (loop, nbd, dm, md, etc) and require CAP_SYS_ADMIN in the initial user namespace for mapping and unmapping, and also for dumping the configuration string and refreshing the image header.

Signed-off-by Ilya Dryomov <[email protected]>

Reviewed-by Jeff Layton <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/block/rbd.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

drivers/block/rbd.c +12 -0

@@ -5120,6 +5120,9 @@ static ssize_t rbd_config_info_show(stru
 {
 	struct rbd_device *rbd_dev = dev_to_rbd_dev(dev);
 
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	return sprintf(buf, "%s\n", rbd_dev->config_info);
 }

@@ -5231,6 +5234,9 @@ static ssize_t rbd_image_refresh(struct
 	struct rbd_device *rbd_dev = dev_to_rbd_dev(dev);
 	int ret;
 
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	ret = rbd_dev_refresh(rbd_dev);
 	if (ret)
 		return ret;

@@ -7059,6 +7065,9 @@ static ssize_t do_rbd_add(struct bus_typ
 	struct rbd_client *rbdc;
 	int rc;
 
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	if (!try_module_get(THIS_MODULE))
 		return -ENODEV;

@@ -7209,6 +7218,9 @@ static ssize_t do_rbd_remove(struct bus_
 	bool force = false;
 	int ret;
 
+	if (!capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	dev_id = -1;
 	opt_buf[0] = '\0';
 	sscanf(buf, "%d %5s", &dev_id, opt_buf);

Greg Kroah-Hartman

author maintainer

2020-09-15 14:41 UTC #163 lore raw

PATCH 150/177 RDMA/rxe: Fix the parent sysfs read when the interface has 15 chars

From: Yi Zhang <[email protected]>

commit 60b1af64eb35074a4f2d41cc1e503a7671e68963 upstream.

'parent' sysfs reads will yield '\0' bytes when the interface name has 15 chars, and there will no "\n" output.

To reproduce, create one interface with 15 chars:

[root@test ~]# ip a s enp0s29u1u7u3c2
2: enp0s29u1u7u3c2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000

     link/ether 02:21:28:57:47:17 brd ff:ff:ff:ff:ff:ff
     inet6 fe80::ac41:338f:5bcd:c222/64 scope link noprefixroute
        valid_lft forever preferred_lft forever

[root@test ~]# modprobe rdma_rxe
[root@test ~]# echo enp0s29u1u7u3c2 > /sys/module/rdma_rxe/parameters/add [root@test ~]# cat /sys/class/infiniband/rxe0/parent enp0s29u1u7u3c2[root@test ~]#
[root@test ~]# f="/sys/class/infiniband/rxe0/parent" [root@test ~]# echo "$(<"$f")"
-bash: warning: command substitution: ignored null byte in input enp0s29u1u7u3c2

Use scnprintf and PAGE_SIZE to fill the sysfs output buffer.

Fixes 8700e3e7c485 ("Soft RoCE driver")

Link https://lore.kernel.org/r/[email protected] open here

Signed-off-by Yi Zhang <[email protected]>

Reviewed-by Bart Van Assche <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/sw/rxe/rxe_verbs.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/infiniband/sw/rxe/rxe_verbs.c +1 -1

@@ -1083,7 +1083,7 @@ static ssize_t parent_show(struct device
 	struct rxe_dev *rxe =
 		rdma_device_to_drv_device(device, struct rxe_dev, ib_dev);
 
-	return snprintf(buf, 16, "%s\n", rxe_parent_name(rxe, 1));
+	return scnprintf(buf, PAGE_SIZE, "%s\n", rxe_parent_name(rxe, 1));
 }
 
 static DEVICE_ATTR_RO(parent);

Greg Kroah-Hartman

author maintainer

2020-09-15 23:07 UTC #164 lore raw

PATCH 151/177 RDMA/mlx4: Read pkey table length instead of hardcoded value

From: Mark Bloch <[email protected]>

commit ec78b3bd66bc9a015505df0ef0eb153d9e64b03b upstream.

If the pkey_table is not available (which is the case when RoCE is not supported), the cited commit caused a regression where mlx4_devices without RoCE are not created.

Fix this by returning a pkey table length of zero in procedure eth_link_query_port() if the pkey-table length reported by the device is zero.

Link https://lore.kernel.org/r/[email protected] open here

Fixes 1901b91f9982 ("IB/core: Fix potential NULL pointer dereference in pkey cache")

Fixes fa417f7b520e ("IB/mlx4: Add support for IBoE")

Signed-off-by Mark Bloch <[email protected]>

Reviewed-by Maor Gottlieb <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

Signed-off-by Greg Kroah-Hartman <[email protected]>

---
 drivers/infiniband/hw/mlx4/main.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/infiniband/hw/mlx4/main.c +2 -1

@@ -784,7 +784,8 @@ static int eth_link_query_port(struct ib
 	props->ip_gids = true;
 	props->gid_tbl_len	= mdev->dev->caps.gid_table_len[port];
 	props->max_msg_sz	= mdev->dev->caps.max_msg_sz;
-	props->pkey_tbl_len	= 1;
+	if (mdev->dev->caps.pkey_table_len[port])
+		props->pkey_tbl_len = 1;
 	props->max_mtu		= IB_MTU_4096;
 	props->max_vl_num	= 2;
 	props->state		= IB_PORT_DOWN;

Greg Kroah-Hartman

author maintainer

2020-09-15 14:42 UTC #165 lore raw

PATCH 152/177 fbcon: remove soft scrollback code