Skip to contentSkip to conversation

6.1.47-rc1 review

PATCH In review Greg Kroah-Hartman 13 participants 227 messages Aug 21, 2023 – Aug 24, 2023 Page 2 of 2

Subsystems (2)
lore
Share & tools
lore
author maintainer
#139 lore raw

PATCH 139/194 ARM: dts: imx: align LED node names with dtschema

In reply to Greg Kroah-Hartman

From: Krzysztof Kozlowski <[email protected]>

[ Upstream commit 4b0d1f2738899dbcc7a026d826373530019aa31b ]

The node names should be generic and DT schema expects certain pattern:

imx50-kobo-aura.dtb: gpio-leds: 'on' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' imx6dl-yapp4-draco.dtb: led-controller@30: 'chan@0', 'chan@1', 'chan@2' do not match any of the regexes: '^led@[0-8]$', '^multi-led@[0-8]$', 'pinctrl-[0-9]+'

Stable-dep-of: 762b700982a1 ("ARM: dts: imx6: phytec: fix RTC interrupt level")

---
 arch/arm/boot/dts/imx50-kobo-aura.dts            |  2 +-
 arch/arm/boot/dts/imx53-cx9020.dts               | 10 +++++-----
 arch/arm/boot/dts/imx53-m53evk.dts               |  4 ++--
 arch/arm/boot/dts/imx53-m53menlo.dts             |  6 +++---
 arch/arm/boot/dts/imx53-tx53.dtsi                |  2 +-
 arch/arm/boot/dts/imx53-usbarmory.dts            |  2 +-
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6dl-riotboard.dts           |  4 ++--
 arch/arm/boot/dts/imx6dl-yapp4-common.dtsi       |  6 +++---
 arch/arm/boot/dts/imx6q-gw5400-a.dts             |  6 +++---
 arch/arm/boot/dts/imx6q-h100.dts                 |  6 +++---
 arch/arm/boot/dts/imx6q-kp.dtsi                  |  4 ++--
 arch/arm/boot/dts/imx6q-marsboard.dts            |  4 ++--
 arch/arm/boot/dts/imx6q-tbs2910.dts              |  2 +-
 arch/arm/boot/dts/imx6qdl-emcon.dtsi             |  4 ++--
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi            |  4 ++--
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi            |  2 +-
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi            |  4 ++--
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw5903.dtsi            |  2 +-
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw5907.dtsi            |  4 ++--
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw5912.dtsi            |  6 +++---
 arch/arm/boot/dts/imx6qdl-gw5913.dtsi            |  4 ++--
 arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi         | 10 +++++-----
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi     |  4 ++--
 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi       |  6 +++---
 arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi     |  4 ++--
 arch/arm/boot/dts/imx6qdl-rex.dtsi               |  2 +-
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi         |  2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi           |  2 +-
 arch/arm/boot/dts/imx6qdl-ts7970.dtsi            |  4 ++--
 arch/arm/boot/dts/imx6qdl-tx6.dtsi               |  2 +-
 arch/arm/boot/dts/imx6sl-evk.dts                 |  2 +-
 arch/arm/boot/dts/imx6sll-evk.dts                |  2 +-
 arch/arm/boot/dts/imx6sx-sabreauto.dts           |  2 +-
 arch/arm/boot/dts/imx6sx-udoo-neo.dtsi           |  4 ++--
 arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi |  2 +-
 arch/arm/boot/dts/imx6ul-tx6ul.dtsi              |  2 +-
 44 files changed, 93 insertions(+), 93 deletions(-)
arch/arm/boot/dts/imx50-kobo-aura.dts +1 -1
index 51bf6117fb124..467db6b4ed7f8 100644
@@ -26,7 +26,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_leds>;
 
-		on {
+		led-on {
 			label = "kobo_aura:orange:on";
 			gpios = <&gpio6 24 GPIO_ACTIVE_LOW>;
 			panic-indicator;
arch/arm/boot/dts/imx53-cx9020.dts +5 -5
index cfb18849a92b4..055d23a9aee7c 100644
@@ -86,27 +86,27 @@
 	leds {
 		compatible = "gpio-leds";
 
-		pwr-r {
+		led-pwr-r {
 			gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
 			default-state = "off";
 		};
 
-		pwr-g {
+		led-pwr-g {
 			gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
 			default-state = "on";
 		};
 
-		pwr-b {
+		led-pwr-b {
 			gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
 			default-state = "off";
 		};
 
-		sd1-b {
+		led-sd1-b {
 			linux,default-trigger = "mmc0";
 			gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
 		};
 
-		sd2-b {
+		led-sd2-b {
 			linux,default-trigger = "mmc1";
 			gpios = <&gpio3 17 GPIO_ACTIVE_HIGH>;
 		};
arch/arm/boot/dts/imx53-m53evk.dts +2 -2
index a1a6228d1aa66..2bd2432d317ff 100644
@@ -52,13 +52,13 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&led_pin_gpio>;
 
-		user1 {
+		led-user1 {
 			label = "user1";
 			gpios = <&gpio2 8 0>;
 			linux,default-trigger = "heartbeat";
 		};
 
-		user2 {
+		led-user2 {
 			label = "user2";
 			gpios = <&gpio2 9 0>;
 			linux,default-trigger = "heartbeat";
arch/arm/boot/dts/imx53-m53menlo.dts +3 -3
index d5c68d1ea707c..4d77b6077fc1b 100644
@@ -34,19 +34,19 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		user1 {
+		led-user1 {
 			label = "TestLed601";
 			gpios = <&gpio6 1 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "mmc0";
 		};
 
-		user2 {
+		led-user2 {
 			label = "TestLed602";
 			gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
 		};
 
-		eth {
+		led-eth {
 			label = "EthLedYe";
 			gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "netdev";
arch/arm/boot/dts/imx53-tx53.dtsi +1 -1
index 892dd1a4bac35..a439a47fb65ac 100644
@@ -94,7 +94,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_stk5led>;
 
-		user {
+		led-user {
 			label = "Heartbeat";
 			gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
arch/arm/boot/dts/imx53-usbarmory.dts +1 -1
index f34993a490ee8..acc44010d5106 100644
@@ -67,7 +67,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		user {
+		led-user {
 			label = "LED";
 			gpios = <&gpio4 27 GPIO_ACTIVE_LOW>;
 			linux,default-trigger = "heartbeat";
arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi +3 -3
index 337db29b0010a..37697fac9dea9 100644
@@ -211,17 +211,17 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_q7_gpio1 &pinctrl_q7_gpio3 &pinctrl_q7_gpio5>;
 
-		alarm1 {
+		led-alarm1 {
 			label = "alarm:red";
 			gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
 		};
 
-		alarm2 {
+		led-alarm2 {
 			label = "alarm:yellow";
 			gpios = <&gpio4 27 GPIO_ACTIVE_HIGH>;
 		};
 
-		alarm3 {
+		led-alarm3 {
 			label = "alarm:blue";
 			gpios = <&gpio4 15 GPIO_ACTIVE_HIGH>;
 		};
arch/arm/boot/dts/imx6dl-riotboard.dts +2 -2
index e7be05f205d32..24c7f535f63bd 100644
@@ -25,14 +25,14 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
 			default-state = "off";
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi +3 -3
index 52162e8c7274b..aacbf317feea6 100644
@@ -274,7 +274,7 @@
 		#address-cells = <1>;
 		#size-cells = <0>;
 
-		chan@0 {
+		led@0 {
 			chan-name = "R";
 			led-cur = /bits/ 8 <0x20>;
 			max-cur = /bits/ 8 <0x60>;
@@ -282,7 +282,7 @@
 			color = <LED_COLOR_ID_RED>;
 		};
 
-		chan@1 {
+		led@1 {
 			chan-name = "G";
 			led-cur = /bits/ 8 <0x20>;
 			max-cur = /bits/ 8 <0x60>;
@@ -290,7 +290,7 @@
 			color = <LED_COLOR_ID_GREEN>;
 		};
 
-		chan@2 {
+		led@2 {
 			chan-name = "B";
 			led-cur = /bits/ 8 <0x20>;
 			max-cur = /bits/ 8 <0x60>;
arch/arm/boot/dts/imx6q-gw5400-a.dts +3 -3
index e894faba571f9..522a51042965a 100644
@@ -34,20 +34,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* 102 -> MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>; /* 106 -> MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* 111 -> MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6q-h100.dts +3 -3
index b8feadbff967d..6406ade14f57b 100644
@@ -76,19 +76,19 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_h100_leds>;
 
-		led0: power {
+		led0: led-power {
 			label = "power";
 			gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
 			default-state = "on";
 		};
 
-		led1: stream {
+		led1: led-stream {
 			label = "stream";
 			gpios = <&gpio2 29 GPIO_ACTIVE_LOW>;
 			default-state = "off";
 		};
 
-		led2: rec {
+		led2: led-rec {
 			label = "rec";
 			gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
 			default-state = "off";
arch/arm/boot/dts/imx6q-kp.dtsi +2 -2
index 1ade0bff681d6..5e0ed55600405 100644
@@ -66,14 +66,14 @@
 	leds {
 		compatible = "gpio-leds";
 
-		green {
+		led-green {
 			label = "led1";
 			gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "gpio";
 			default-state = "off";
 		};
 
-		red {
+		led-red {
 			label = "led0";
 			gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "gpio";
arch/arm/boot/dts/imx6q-marsboard.dts +2 -2
index cc18010023942..2c9961333b0a8 100644
@@ -73,14 +73,14 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		user1 {
+		led-user1 {
 			label = "imx6:green:user1";
 			gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
 			default-state = "off";
 			linux,default-trigger = "heartbeat";
 		};
 
-		user2 {
+		led-user2 {
 			label = "imx6:green:user2";
 			gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
 			default-state = "off";
arch/arm/boot/dts/imx6q-tbs2910.dts +1 -1
index 8daef65d5bb35..2f576e2ce73f2 100644
@@ -49,7 +49,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		blue {
+		led-blue {
 			label = "blue_status_led";
 			gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
 			default-state = "keep";
arch/arm/boot/dts/imx6qdl-emcon.dtsi +2 -2
index 7228b894a763f..ee2dd75cead6d 100644
@@ -46,14 +46,14 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_som_leds>;
 
-		green {
+		led-green {
 			label = "som:green";
 			gpios = <&gpio3 0 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
 			default-state = "on";
 		};
 
-		red {
+		led-red {
 			label = "som:red";
 			gpios = <&gpio3 1 GPIO_ACTIVE_LOW>;
 			default-state = "keep";
arch/arm/boot/dts/imx6qdl-gw51xx.dtsi +2 -2
index 069c27fab432c..e75e1a5364b85 100644
@@ -71,14 +71,14 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi +3 -3
index 728810b9d677d..47d9a8d08197d 100644
@@ -80,20 +80,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi +3 -3
index 6c0c109046d80..fb1d29abe0991 100644
@@ -80,20 +80,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi +3 -3
index a9b04f9f1c2bc..4e20cb97058eb 100644
@@ -81,20 +81,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw551x.dtsi +1 -1
index 435dec6338fe6..0fa4b8eeddee7 100644
@@ -115,7 +115,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 7 GPIO_ACTIVE_LOW>;
 			default-state = "on";
arch/arm/boot/dts/imx6qdl-gw552x.dtsi +3 -3
index 2e61102ae6946..77ae611b817a4 100644
@@ -72,20 +72,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw553x.dtsi +2 -2
index 4662408b225a5..7f16c602cc075 100644
@@ -113,14 +113,14 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 11 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw560x.dtsi +3 -3
index 4b81a975c979d..46cf4080fec38 100644
@@ -139,20 +139,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw5903.dtsi +1 -1
index 1fdb7ba630f1b..a74cde0501589 100644
@@ -123,7 +123,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio6 14 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw5904.dtsi +3 -3
index 612b6e068e282..9fc79af2bc9aa 100644
@@ -120,20 +120,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw5907.dtsi +2 -2
index fcd3bdfd61827..955a51226eda7 100644
@@ -71,14 +71,14 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw5910.dtsi +3 -3
index 6bb4855d13ce5..218d6e667ed24 100644
@@ -74,20 +74,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw5912.dtsi +3 -3
index 0415bcb416400..40e235e315cc4 100644
@@ -72,20 +72,20 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
 		};
 
-		led2: user3 {
+		led2: led-user3 {
 			label = "user3";
 			gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-gw5913.dtsi +2 -2
index 696427b487f01..82f47c295b085 100644
@@ -71,14 +71,14 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		led0: user1 {
+		led0: led-user1 {
 			label = "user1";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDG */
 			default-state = "on";
 			linux,default-trigger = "heartbeat";
 		};
 
-		led1: user2 {
+		led1: led-user2 {
 			label = "user2";
 			gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>; /* MX6_PANLEDR */
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi +5 -5
index a53a5d0766a51..6d4eab1942b94 100644
@@ -85,31 +85,31 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_leds>;
 
-		j14-pin1 {
+		led-j14-pin1 {
 			gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
 			retain-state-suspended;
 			default-state = "off";
 		};
 
-		j14-pin3 {
+		led-j14-pin3 {
 			gpios = <&gpio1 3 GPIO_ACTIVE_LOW>;
 			retain-state-suspended;
 			default-state = "off";
 		};
 
-		j14-pins8-9 {
+		led-j14-pins8-9 {
 			gpios = <&gpio3 29 GPIO_ACTIVE_LOW>;
 			retain-state-suspended;
 			default-state = "off";
 		};
 
-		j46-pin2 {
+		led-j46-pin2 {
 			gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
 			retain-state-suspended;
 			default-state = "off";
 		};
 
-		j46-pin3 {
+		led-j46-pin3 {
 			gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
 			retain-state-suspended;
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi +2 -2
index 57c21a01f126d..81a9a302aec1b 100644
@@ -181,13 +181,13 @@
 	leds {
 		compatible = "gpio-leds";
 
-		speaker-enable {
+		led-speaker-enable {
 			gpios = <&gpio1 29 GPIO_ACTIVE_HIGH>;
 			retain-state-suspended;
 			default-state = "off";
 		};
 
-		ttymxc4-rs232 {
+		led-ttymxc4-rs232 {
 			gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>;
 			retain-state-suspended;
 			default-state = "on";
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi +3 -3
index 120d6e997a4c5..1a599c294ab86 100644
@@ -25,17 +25,17 @@
 		pinctrl-0 = <&pinctrl_gpioleds>;
 		status = "disabled";
 
-		red {
+		led-red {
 			label = "phyboard-mira:red";
 			gpios = <&gpio5 22 GPIO_ACTIVE_HIGH>;
 		};
 
-		green {
+		led-green {
 			label = "phyboard-mira:green";
 			gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
 		};
 
-		blue {
+		led-blue {
 			label = "phyboard-mira:blue";
 			gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "mmc0";
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi +2 -2
index 768bc0e3a2b38..80adb2a02cc94 100644
@@ -47,12 +47,12 @@
 		pinctrl-0 = <&pinctrl_leds>;
 		compatible = "gpio-leds";
 
-		led_green: green {
+		led_green: led-green {
 			label = "phyflex:green";
 			gpios = <&gpio1 30 0>;
 		};
 
-		led_red: red {
+		led_red: led-red {
 			label = "phyflex:red";
 			gpios = <&gpio2 31 0>;
 		};
arch/arm/boot/dts/imx6qdl-rex.dtsi +1 -1
index de514eb5aa99d..f804ff95a6ad6 100644
@@ -55,7 +55,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		led0: usr {
+		led0: led-usr {
 			label = "usr";
 			gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi +1 -1
index 3dbb460ef102e..10886a1461bfb 100644
@@ -21,7 +21,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		user {
+		led-user {
 			label = "debug";
 			gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;
 		};
arch/arm/boot/dts/imx6qdl-sabresd.dtsi +1 -1
index 37482a9023fce..bcb83d52e26ed 100644
@@ -130,7 +130,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_gpio_leds>;
 
-		red {
+		led-red {
 			gpios = <&gpio1 2 0>;
 			default-state = "on";
 		};
arch/arm/boot/dts/imx6qdl-ts7970.dtsi +2 -2
index c096d25a6f5b5..1e0a041e9f60a 100644
@@ -73,13 +73,13 @@
 			default-state = "off";
 		};
 
-		en-usb-5v {
+		en-usb-5v-led {
 			label = "en-usb-5v";
 			gpios = <&gpio2 22 GPIO_ACTIVE_HIGH>;
 			default-state = "on";
 		};
 
-		sel_dc_usb {
+		sel-dc-usb-led {
 			label = "sel_dc_usb";
 			gpios = <&gpio5 17 GPIO_ACTIVE_HIGH>;
 			default-state = "off";
arch/arm/boot/dts/imx6qdl-tx6.dtsi +1 -1
index f41f86a76ea95..a197bac95cbac 100644
@@ -92,7 +92,7 @@
 	leds {
 		compatible = "gpio-leds";
 
-		user_led: user {
+		user_led: led-user {
 			label = "Heartbeat";
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_user_led>;
arch/arm/boot/dts/imx6sl-evk.dts +1 -1
index f16c830f1e918..dc5d596c18db4 100644
@@ -33,7 +33,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		user {
+		led-user {
 			label = "debug";
 			gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
arch/arm/boot/dts/imx6sll-evk.dts +1 -1
index 32b3d82fec53c..269092ac881c5 100644
@@ -37,7 +37,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		user {
+		led-user {
 			label = "debug";
 			gpios = <&gpio2 4 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
arch/arm/boot/dts/imx6sx-sabreauto.dts +1 -1
index 83ee97252ff11..b0c27b9b02446 100644
@@ -20,7 +20,7 @@
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_led>;
 
-		user {
+		led-user {
 			label = "debug";
 			gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
arch/arm/boot/dts/imx6sx-udoo-neo.dtsi +2 -2
index c84ea1fac5e98..725d0b5cb55f6 100644
@@ -15,14 +15,14 @@
 	leds {
 		compatible = "gpio-leds";
 
-		red {
+		led-red {
 			label = "udoo-neo:red:mmc";
 			gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>;
 			default-state = "off";
 			linux,default-trigger = "mmc0";
 		};
 
-		orange {
+		led-orange {
 			label = "udoo-neo:orange:user";
 			gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
 			default-state = "keep";
arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi +1 -1
index 3cddc68917a08..e4d2652a75c0b 100644
@@ -30,7 +30,7 @@
 		pinctrl-0 = <&pinctrl_gpioleds_som>;
 		compatible = "gpio-leds";
 
-		phycore-green {
+		led-phycore-green {
 			gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>;
 			linux,default-trigger = "heartbeat";
 		};
arch/arm/boot/dts/imx6ul-tx6ul.dtsi +1 -1
index 15ee0275feaff..70cef5e817bd1 100644
@@ -131,7 +131,7 @@
 	leds {
 		compatible = "gpio-leds";
 
-		user_led: user {
+		user_led: led-user {
 			label = "Heartbeat";
 			pinctrl-names = "default";
 			pinctrl-0 = <&pinctrl_led>;
Signature · 1 line
2.40.1
author maintainer
#140 lore raw

PATCH 140/194 ARM: dts: imx6: phytec: fix RTC interrupt level

In reply to Greg Kroah-Hartman

From: Andrej Picej <[email protected]>

[ Upstream commit 762b700982a1e0f562184363f19860c3b9bdd0bf ]

RTC interrupt level should be set to "LOW". This was revealed by the introduction of commit:

f181987ef477 ("rtc: m41t80: use IRQ flags obtained from fwnode")

which changed the way IRQ type is obtained.

Fixes 800d595151bb ("ARM: dts: imx6: Add initial support for phyBOARD-Mira")
---
 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi +1 -1
index 1a599c294ab86..1ca4d219609f6 100644
@@ -182,7 +182,7 @@
 		pinctrl-0 = <&pinctrl_rtc_int>;
 		reg = <0x68>;
 		interrupt-parent = <&gpio7>;
-		interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
+		interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
 		status = "disabled";
 	};
 };
Signature · 1 line
2.40.1
author maintainer
#141 lore raw

PATCH 141/194 arm64: dts: imx8mm: Drop CSI1 PHY reference clock configuration

In reply to Greg Kroah-Hartman

From: Fabio Estevam <[email protected]>

[ Upstream commit f02b53375e8f14b4c27a14f6e4fb6e89914fdc29 ]

The CSI1 PHY reference clock is limited to 125 MHz according to:
i.MX 8M Mini Applications Processor Reference Manual, Rev. 3, 11/2020 Table 5-1. Clock Root Table (continued) / page 307
Slice Index n = 123 .

Currently the IMX8MM_CLK_CSI1_PHY_REF clock is configured to be fed directly from 1 GHz PLL2 , which overclocks them. Instead, drop the configuration altogether, which defaults the clock to 24 MHz REF clock input, which for the PHY reference clock is just fine.

Based on a patch from Marek Vasut for the imx8mn.

Fixes e523b7c54c05 ("arm64: dts: imx8mm: Add CSI nodes")
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm.dtsi +3 -4
index 420ba0d6f1343..12c82bb1bb7aa 100644
@@ -1145,10 +1145,9 @@
 				compatible = "fsl,imx8mm-mipi-csi2";
 				reg = <0x32e30000 0x1000>;
 				interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
-				assigned-clocks = <&clk IMX8MM_CLK_CSI1_CORE>,
-						  <&clk IMX8MM_CLK_CSI1_PHY_REF>;
-				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_1000M>,
-							  <&clk IMX8MM_SYS_PLL2_1000M>;
+				assigned-clocks = <&clk IMX8MM_CLK_CSI1_CORE>;
+				assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_1000M>;
+
 				clock-frequency = <333000000>;
 				clocks = <&clk IMX8MM_CLK_DISP_APB_ROOT>,
 					 <&clk IMX8MM_CLK_CSI1_ROOT>,
Signature · 1 line
2.40.1
author maintainer
#142 lore raw

PATCH 142/194 ARM: dts: imx: Set default tuning step for imx6sx usdhc

In reply to Greg Kroah-Hartman

From: Xiaolei Wang <[email protected]>

[ Upstream commit 0a2b96e42a0284c4fc03022236f656a085ca714a ]

If the tuning step is not set, the tuning step is set to 1. For some sd cards, the following Tuning timeout will occur.

Tuning failed, falling back to fixed sampling clock

So set the default tuning step. This refers to the NXP vendor's commit below:

https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/
arch/arm/boot/dts/imx6sx.dtsi#L1108-L1109

Fixes 1e336aa0c025 ("mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting")
---
 arch/arm/boot/dts/imx6sx.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)
arch/arm/boot/dts/imx6sx.dtsi +6 -0
index abc3572d699e6..1f1053a898fbf 100644
@@ -981,6 +981,8 @@
 					 <&clks IMX6SX_CLK_USDHC1>;
 				clock-names = "ipg", "ahb", "per";
 				bus-width = <4>;
+				fsl,tuning-start-tap = <20>;
+				fsl,tuning-step= <2>;
 				status = "disabled";
 			};
 
@@ -993,6 +995,8 @@
 					 <&clks IMX6SX_CLK_USDHC2>;
 				clock-names = "ipg", "ahb", "per";
 				bus-width = <4>;
+				fsl,tuning-start-tap = <20>;
+				fsl,tuning-step= <2>;
 				status = "disabled";
 			};
 
@@ -1005,6 +1009,8 @@
 					 <&clks IMX6SX_CLK_USDHC3>;
 				clock-names = "ipg", "ahb", "per";
 				bus-width = <4>;
+				fsl,tuning-start-tap = <20>;
+				fsl,tuning-step= <2>;
 				status = "disabled";
 			};
 
Signature · 1 line
2.40.1
author maintainer
#143 lore raw

PATCH 143/194 arm64: dts: imx93: Fix anatop node size

In reply to Greg Kroah-Hartman

From: Alexander Stein <[email protected]>

[ Upstream commit 78e869dd8b2ba19765ac9b05cdea3e432d1dc188 ]

Although the memory map of i.MX93 reference manual rev. 2 claims that analog top has start address of 0x44480000 and end address of 0x4448ffff, this overlaps with TMU memory area starting at 0x44482000, as stated in section 73.6.1.
As PLL configuration registers start at addresses up to 0x44481400, as used by clk-imx93, reduce the anatop size to 0x2000, so exclude the TMU area but keep all PLL registers inside.

Fixes ec8b5b5058ea ("arm64: dts: freescale: Add i.MX93 dtsi support")
---
 arch/arm64/boot/dts/freescale/imx93.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/freescale/imx93.dtsi +1 -1
index 8ab9f8194702e..c2f60d41d6fd1 100644
@@ -254,7 +254,7 @@
 
 			anatop: anatop@44480000 {
 				compatible = "fsl,imx93-anatop", "syscon";
-				reg = <0x44480000 0x10000>;
+				reg = <0x44480000 0x2000>;
 			};
 		};
 
Signature · 1 line
2.40.1
author maintainer
#144 lore raw

PATCH 144/194 ASoC: rt5665: add missed regulator_bulk_disable

In reply to Greg Kroah-Hartman

From: Zhang Shurong <[email protected]>

[ Upstream commit c163108e706909570f8aa9aa5bcf6806e2b4c98c ]

The driver forgets to call regulator_bulk_disable()

Add the missed call to fix it.

Fixes 33ada14a26c8 ("ASoC: add rt5665 codec driver")
---
 sound/soc/codecs/rt5665.c | 2 ++
 1 file changed, 2 insertions(+)
sound/soc/codecs/rt5665.c +2 -0
index 6e66cc218fa8d..76ff097518c88 100644
@@ -4472,6 +4472,8 @@ static void rt5665_remove(struct snd_soc_component *component)
 	struct rt5665_priv *rt5665 = snd_soc_component_get_drvdata(component);
 
 	regmap_write(rt5665->regmap, RT5665_RESET, 0);
+
+	regulator_bulk_disable(ARRAY_SIZE(rt5665->supplies), rt5665->supplies);
 }
 
 #ifdef CONFIG_PM
Signature · 1 line
2.40.1
author maintainer
#145 lore raw

PATCH 145/194 ASoC: meson: axg-tdm-formatter: fix channel slot allocation

In reply to Greg Kroah-Hartman

From: Jerome Brunet <[email protected]>

[ Upstream commit c1f848f12103920ca165758aedb1c10904e193e1 ]

When the tdm lane mask is computed, the driver currently fills the 1st lane before moving on to the next. If the stream has less channels than the lanes can accommodate, slots will be disabled on the last lanes.

Unfortunately, the HW distribute channels in a different way. It distribute channels in pair on each lanes before moving on the next slots.

This difference leads to problems if a device has an interface with more than 1 lane and with more than 2 slots per lane.

For example: a playback interface with 2 lanes and 4 slots each (total 8 slots - zero based numbering)
- Playing a 8ch stream:
- All slots activated by the driver
- channel #2 will be played on lane #1 - slot #0 following HW placement
- Playing a 4ch stream:
- Lane #1 disabled by the driver
- channel #2 will be played on lane #0 - slot #2

This behaviour is obviously not desirable.

Change the way slots are activated on the TDM lanes to follow what the HW does and make sure each channel always get mapped to the same slot/lane.

Fixes 1a11d88f499c ("ASoC: meson: add tdm formatter base driver")
---
 sound/soc/meson/axg-tdm-formatter.c | 42 ++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 16 deletions(-)
sound/soc/meson/axg-tdm-formatter.c +26 -16
index 9883dc777f630..63333a2b0a9c3 100644
@@ -30,27 +30,32 @@ int axg_tdm_formatter_set_channel_masks(struct regmap *map,
 					struct axg_tdm_stream *ts,
 					unsigned int offset)
 {
-	unsigned int val, ch = ts->channels;
-	unsigned long mask;
-	int i, j;
+	unsigned int ch = ts->channels;
+	u32 val[AXG_TDM_NUM_LANES];
+	int i, j, k;
+
+	/*
+	 * We need to mimick the slot distribution used by the HW to keep the
+	 * channel placement consistent regardless of the number of channel
+	 * in the stream. This is why the odd algorithm below is used.
+	 */
+	memset(val, 0, sizeof(*val) * AXG_TDM_NUM_LANES);
 
 	/*
 	 * Distribute the channels of the stream over the available slots
-	 * of each TDM lane
+	 * of each TDM lane. We need to go over the 32 slots ...
 	 */
-	for (i = 0; i < AXG_TDM_NUM_LANES; i++) {
-		val = 0;
-		mask = ts->mask[i];
-
-		for (j = find_first_bit(&mask, 32);
-		     (j < 32) && ch;
-		     j = find_next_bit(&mask, 32, j + 1)) {
-			val |= 1 << j;
-			ch -= 1;
+	for (i = 0; (i < 32) && ch; i += 2) {
+		/* ... of all the lanes ... */
+		for (j = 0; j < AXG_TDM_NUM_LANES; j++) {
+			/* ... then distribute the channels in pairs */
+			for (k = 0; k < 2; k++) {
+				if ((BIT(i + k) & ts->mask[j]) && ch) {
+					val[j] |= BIT(i + k);
+					ch -= 1;
+				}
+			}
 		}
-
-		regmap_write(map, offset, val);
-		offset += regmap_get_reg_stride(map);
 	}
 
 	/*
@@ -63,6 +68,11 @@ int axg_tdm_formatter_set_channel_masks(struct regmap *map,
 		return -EINVAL;
 	}
 
+	for (i = 0; i < AXG_TDM_NUM_LANES; i++) {
+		regmap_write(map, offset, val[i]);
+		offset += regmap_get_reg_stride(map);
+	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(axg_tdm_formatter_set_channel_masks);
Signature · 1 line
2.40.1
author maintainer
#146 lore raw

PATCH 146/194 ALSA: hda/realtek: Add quirks for HP G11 Laptops

In reply to Greg Kroah-Hartman

From: Stefan Binding <[email protected]>

[ Upstream commit fb8cce69e5e56eedb35fc4d77b2f099860965859 ]

These HP G11 laptops use Realtek HDA codec combined with 2xCS35L41 Amplifiers using SPI or I2C with External Boost.

Laptop 103c8c26 has been removed as this has been replaced by this new series of laptops.

Fixes 3e10f6ca76c4 ("ALSA: hda/realtek: Add quirk for HP EliteBook G10 laptops")
---
 sound/pci/hda/patch_realtek.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
sound/pci/hda/patch_realtek.c +7 -1
index 526ec8cae9437..de6bd8a9871cf 100644
@@ -9596,7 +9596,13 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8b96, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8b97, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8bf0, "HP", ALC236_FIXUP_HP_GPIO_LED),
-	SND_PCI_QUIRK(0x103c, 0x8c26, "HP HP EliteBook 800G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8c46, "HP EliteBook 830 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8c47, "HP EliteBook 840 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8c48, "HP EliteBook 860 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8c49, "HP Elite x360 830 2-in-1 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8c70, "HP EliteBook 835 G11", ALC287_FIXUP_CS35L41_I2C_2_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8c71, "HP EliteBook 845 G11", ALC287_FIXUP_CS35L41_I2C_2_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8c72, "HP EliteBook 865 G11", ALC287_FIXUP_CS35L41_I2C_2_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x1043, 0x103e, "ASUS X540SA", ALC256_FIXUP_ASUS_MIC),
 	SND_PCI_QUIRK(0x1043, 0x103f, "ASUS TX300", ALC282_FIXUP_ASUS_TX300),
 	SND_PCI_QUIRK(0x1043, 0x106d, "Asus K53BE", ALC269_FIXUP_LIMIT_INT_MIC_BOOST),
Signature · 1 line
2.40.1
author maintainer
#147 lore raw

PATCH 147/194 soc: aspeed: uart-routing: Use __sysfs_match_string

In reply to Greg Kroah-Hartman

From: Zev Weiss <[email protected]>

[ Upstream commit e4ad279ae345413d900d791f2f618d0a1cd0d791 ]

The existing use of match_string() caused it to reject 'echo foo' due to the implicitly appended newline, which was somewhat ergonomically awkward and inconsistent with typical sysfs behavior. Using the __sysfs_* variant instead provides more convenient and consistent linefeed-agnostic behavior.

---
 drivers/soc/aspeed/aspeed-uart-routing.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soc/aspeed/aspeed-uart-routing.c +1 -1
index ef8b24fd18518..59123e1f27acb 100644
@@ -524,7 +524,7 @@ static ssize_t aspeed_uart_routing_store(struct device *dev,
 	struct aspeed_uart_routing_selector *sel = to_routing_selector(attr);
 	int val;
 
-	val = match_string(sel->options, -1, buf);
+	val = __sysfs_match_string(sel->options, -1, buf);
 	if (val < 0) {
 		dev_err(dev, "invalid value \"%s\"\n", buf);
 		return -EINVAL;
Signature · 1 line
2.40.1
author maintainer
#148 lore raw

PATCH 148/194 soc: aspeed: socinfo: Add kfree for kstrdup

In reply to Greg Kroah-Hartman

From: Jiasheng Jiang <[email protected]>

[ Upstream commit 6e6d847a8ce18ab2fbec4f579f682486a82d2c6b ]

Add kfree() in the later error handling in order to avoid memory leak.

---
 drivers/soc/aspeed/aspeed-socinfo.c | 1 +
 1 file changed, 1 insertion(+)
drivers/soc/aspeed/aspeed-socinfo.c +1 -0
index 1ca140356a084..3f759121dc00a 100644
@@ -137,6 +137,7 @@ static int __init aspeed_socinfo_init(void)
 
 	soc_dev = soc_device_register(attrs);
 	if (IS_ERR(soc_dev)) {
+		kfree(attrs->machine);
 		kfree(attrs->soc_id);
 		kfree(attrs->serial_number);
 		kfree(attrs);
Signature · 1 line
2.40.1
author maintainer
#149 lore raw

PATCH 149/194 ALSA: hda/realtek - Remodified 3k pull low procedure

In reply to Greg Kroah-Hartman

From: Kailang Yang <[email protected]>

[ Upstream commit 46cdff2369cbdf8d78081a22526e77bd1323f563 ]

Set spec->en_3kpull_low default to true.
Then fillback ALC236 and ALC257 to false.

Additional note: this addresses a regression caused by the previous fix 69ea4c9d02b7 ("ALSA: hda/realtek - remove 3k pull low procedure"). The previous workaround was applied too widely without necessity, which resulted in the pop noise at PM again. This patch corrects the condition and restores the old behavior for the devices that don't suffer from the original problem.

---
 sound/pci/hda/patch_realtek.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
sound/pci/hda/patch_realtek.c +5 -2
index de6bd8a9871cf..aa475154c582f 100644
@@ -10620,6 +10620,7 @@ static int patch_alc269(struct hda_codec *codec)
 	spec = codec->spec;
 	spec->gen.shared_mic_vref_pin = 0x18;
 	codec->power_save_node = 0;
+	spec->en_3kpull_low = true;
 
 #ifdef CONFIG_PM
 	codec->patch_ops.suspend = alc269_suspend;
@@ -10702,14 +10703,16 @@ static int patch_alc269(struct hda_codec *codec)
 		spec->shutup = alc256_shutup;
 		spec->init_hook = alc256_init;
 		spec->gen.mixer_nid = 0; /* ALC256 does not have any loopback mixer path */
-		if (codec->bus->pci->vendor == PCI_VENDOR_ID_AMD)
-			spec->en_3kpull_low = true;
+		if (codec->core.vendor_id == 0x10ec0236 &&
+		    codec->bus->pci->vendor != PCI_VENDOR_ID_AMD)
+			spec->en_3kpull_low = false;
 		break;
 	case 0x10ec0257:
 		spec->codec_variant = ALC269_TYPE_ALC257;
 		spec->shutup = alc256_shutup;
 		spec->init_hook = alc256_init;
 		spec->gen.mixer_nid = 0;
+		spec->en_3kpull_low = false;
 		break;
 	case 0x10ec0215:
 	case 0x10ec0245:
Signature · 1 line
2.40.1
author maintainer
#150 lore raw

PATCH 150/194 riscv: uaccess: Return the number of bytes effectively not copied

In reply to Greg Kroah-Hartman

From: Alexandre Ghiti <[email protected]>

[ Upstream commit 4b05b993900dd3eba0fc83ef5c5ddc7d65d786c6 ]

It was reported that the riscv kernel hangs while executing the test in [1].

Indeed, the test hangs when trying to write a buffer to a file. The problem is that the riscv implementation of raw_copy_from_user() does not return the correct number of bytes not written when an exception happens and is fixed up, instead it always returns the initial size to copy, even if some bytes were actually copied.

generic_perform_write() pre-faults the user pages and bails out if nothing can be written, otherwise it will access the userspace buffer: here the riscv implementation keeps returning it was not able to copy any byte though the pre-faulting indicates otherwise. So generic_perform_write() keeps retrying to access the user memory and ends up in an infinite loop.

Note that before the commit mentioned in [1] that introduced this regression, it worked because generic_perform_write() would bail out if only one byte could not be written.

So fix this by returning the number of bytes effectively not written in __asm_copy_[to|from]_user() and __clear_user(), as it is expected.

---
 arch/riscv/lib/uaccess.S | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)
arch/riscv/lib/uaccess.S +7 -4
index ec486e5369d9b..09b47ebacf2e8 100644
@@ -17,8 +17,11 @@ ENTRY(__asm_copy_from_user)
 	li t6, SR_SUM
 	csrs CSR_STATUS, t6
 
-	/* Save for return value */
-	mv	t5, a2
+	/*
+	 * Save the terminal address which will be used to compute the number
+	 * of bytes copied in case of a fixup exception.
+	 */
+	add	t5, a0, a2
 
 	/*
 	 * Register allocation for code below:
@@ -176,7 +179,7 @@ ENTRY(__asm_copy_from_user)
 10:
 	/* Disable access to user memory */
 	csrc CSR_STATUS, t6
-	mv a0, t5
+	sub a0, t5, a0
 	ret
 ENDPROC(__asm_copy_to_user)
 ENDPROC(__asm_copy_from_user)
@@ -228,7 +231,7 @@ ENTRY(__clear_user)
 11:
 	/* Disable access to user memory */
 	csrc CSR_STATUS, t6
-	mv a0, a1
+	sub a0, a3, a0
 	ret
 ENDPROC(__clear_user)
 EXPORT_SYMBOL(__clear_user)
Signature · 1 line
2.40.1
author maintainer
#151 lore raw

PATCH 151/194 serial: 8250: Fix oops for port->pm on uart_change_pm()

In reply to Greg Kroah-Hartman

From: Tony Lindgren <[email protected]>

[ Upstream commit dfe2aeb226fd5e19b0ee795f4f6ed8bc494c1534 ]

Unloading a hardware specific 8250 driver can produce error "Unable to handle kernel paging request at virtual address" about ten seconds after unloading the driver. This happens on uart_hangup() calling uart_change_pm().

Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") was only a partial fix. If the hardware specific driver has initialized port->pm function, we need to clear port->pm too. Just reinitializing port->ops does not do this. Otherwise serial8250_pm() will call port->pm() instead of serial8250_do_pm().

Fixes 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind")
---
 drivers/tty/serial/8250/8250_port.c | 1 +
 1 file changed, 1 insertion(+)
drivers/tty/serial/8250/8250_port.c +1 -0
index acf578aa9930b..38760bd6e0c29 100644
@@ -3281,6 +3281,7 @@ void serial8250_init_port(struct uart_8250_port *up)
 	struct uart_port *port = &up->port;
 
 	spin_lock_init(&port->lock);
+	port->pm = NULL;
 	port->ops = &serial8250_pops;
 	port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);
 
Signature · 1 line
2.40.1
author maintainer
#152 lore raw

PATCH 152/194 ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces.

In reply to Greg Kroah-Hartman

From: dengxiang <[email protected]>

commit 788449ae57f4273111b779bbcaad552b67f517d5 upstream.

This patch adds a USB quirk for Mythware XA001AU USB interface.

---
 sound/usb/quirks-table.h |   29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
sound/usb/quirks-table.h +29 -0
@@ -4507,6 +4507,35 @@ YAMAHA_DEVICE(0x7010, "UB99"),
 		}
 	}
 },
+{
+	/* Advanced modes of the Mythware XA001AU.
+	 * For the standard mode, Mythware XA001AU has ID ffad:a001
+	 */
+	USB_DEVICE_VENDOR_SPEC(0xffad, 0xa001),
+	.driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+		.vendor_name = "Mythware",
+		.product_name = "XA001AU",
+		.ifnum = QUIRK_ANY_INTERFACE,
+		.type = QUIRK_COMPOSITE,
+		.data = (const struct snd_usb_audio_quirk[]) {
+			{
+				.ifnum = 0,
+				.type = QUIRK_IGNORE_INTERFACE,
+			},
+			{
+				.ifnum = 1,
+				.type = QUIRK_AUDIO_STANDARD_INTERFACE,
+			},
+			{
+				.ifnum = 2,
+				.type = QUIRK_AUDIO_STANDARD_INTERFACE,
+			},
+			{
+				.ifnum = -1
+			}
+		}
+	}
+},
 
 #undef USB_DEVICE_VENDOR_SPEC
 #undef USB_AUDIO_DEVICE
author maintainer
#153 lore raw

PATCH 153/194 cifs: Release folio lock on fscache read hit.

In reply to Greg Kroah-Hartman

From: Russell Harmon via samba-technical <[email protected]>

commit 69513dd669e243928f7450893190915a88f84a2b upstream.

Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as:

Quoted 2 lines

The filesystem should unlock the folio once the read has completed, whether it was successful or not.

Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page:

$ cat /proc/3890/task/12864/stack
[<0>] folio_wait_bit_common+0x124/0x350
[<0>] filemap_read_folio+0xad/0xf0
[<0>] filemap_fault+0x8b1/0xab0
[<0>] __do_fault+0x39/0x150
[<0>] do_fault+0x25c/0x3e0
[<0>] __handle_mm_fault+0x6ca/0xc70
[<0>] handle_mm_fault+0xe9/0x350
[<0>] do_user_addr_fault+0x225/0x6c0
[<0>] exc_page_fault+0x84/0x1b0
[<0>] asm_exc_page_fault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead.

---
 fs/smb/client/file.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/smb/client/file.c +1 -1
@@ -4885,9 +4885,9 @@ static int cifs_readpage_worker(struct f
 
 io_error:
 	kunmap(page);
-	unlock_page(page);
 
 read_complete:
+	unlock_page(page);
 	return rc;
 }
 
author maintainer
#154 lore raw

PATCH 154/194 riscv: Handle zicsr/zifencei issue between gcc and binutils

In reply to Greg Kroah-Hartman

From: Mingzheng Xing <[email protected]>

commit ca09f772cccaeec4cd05a21528c37a260aa2dd2c upstream.

Binutils-2.38 and GCC-12.1.0 bumped[0][1] the default ISA spec to the newer 20191213 version which moves some instructions from the I extension to the Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds that version, we should explicitly specifying Zicsr and Zifencei via -march to cope with the new changes. but this only occurs when binutils >= 2.36 and GCC >= 11.1.0. It's a different story when binutils < 2.36.

binutils-2.36 supports the Zifencei extension[2] and splits Zifencei and Zicsr from I[3]. GCC-11.1.0 is particular[4] because it add support Zicsr and Zifencei extension for -march. binutils-2.35 does not support the Zifencei extension, and does not need to specify Zicsr and Zifencei when working with GCC >= 12.1.0.

To make our lives easier, let's relax the check to binutils >= 2.36 in CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. For the other two cases, where clang < 17 or GCC < 11.1.0, we will deal with them in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC.

For more information, please refer to:
commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38")
commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils")

---
 arch/riscv/Kconfig                     |   28 +++++++++++++++++-----------
 arch/riscv/kernel/compat_vdso/Makefile |    8 +++++++-
 2 files changed, 24 insertions(+), 12 deletions(-)
arch/riscv/Kconfig +17 -11
@@ -447,24 +447,30 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE
 config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
 	def_bool y
 	# https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
-	depends on AS_IS_GNU && AS_VERSION >= 23800
+	# https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd
+	depends on AS_IS_GNU && AS_VERSION >= 23600
 	help
-	  Newer binutils versions default to ISA spec version 20191213 which
-	  moves some instructions from the I extension to the Zicsr and Zifencei
-	  extensions.
+	  Binutils-2.38 and GCC-12.1.0 bumped the default ISA spec to the newer
+	  20191213 version, which moves some instructions from the I extension to
+	  the Zicsr and Zifencei extensions. This requires explicitly specifying
+	  Zicsr and Zifencei when binutils >= 2.38 or GCC >= 12.1.0. Zicsr
+	  and Zifencei are supported in binutils from version 2.36 onwards.
+	  To make life easier, and avoid forcing toolchains that default to a
+	  newer ISA spec to version 2.2, relax the check to binutils >= 2.36.
+	  For clang < 17 or GCC < 11.1.0, for which this is not possible, this is
+	  dealt with in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC.
 
 config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
 	def_bool y
 	depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
 	# https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
-	depends on CC_IS_CLANG && CLANG_VERSION < 170000
+	# https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a78fa3fb4ef49
+	depends on (CC_IS_CLANG && CLANG_VERSION < 170000) || (CC_IS_GCC && GCC_VERSION < 110100)
 	help
-	  Certain versions of clang do not support zicsr and zifencei via -march
-	  but newer versions of binutils require it for the reasons noted in the
-	  help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This
-	  option causes an older ISA spec compatible with these older versions
-	  of clang to be passed to GAS, which has the same result as passing zicsr
-	  and zifencei to -march.
+	  Certain versions of clang and GCC do not support zicsr and zifencei via
+	  -march. This option causes an older ISA spec compatible with these older
+	  versions of clang and GCC to be passed to GAS, which has the same result
+	  as passing zicsr and zifencei to -march.
 
 config FPU
 	bool "FPU support"
arch/riscv/kernel/compat_vdso/Makefile +7 -1
@@ -11,7 +11,13 @@ compat_vdso-syms += flush_icache
 COMPAT_CC := $(CC)
 COMPAT_LD := $(LD)
 
-COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32
+# binutils 2.35 does not support the zifencei extension, but in the ISA
+# spec 20191213, G stands for IMAFD_ZICSR_ZIFENCEI.
+ifdef CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
+	COMPAT_CC_FLAGS := -march=rv32g -mabi=ilp32
+else
+	COMPAT_CC_FLAGS := -march=rv32imafd -mabi=ilp32
+endif
 COMPAT_LD_FLAGS := -melf32lriscv
 
 # Disable attributes, as they're useless and break the build.
author maintainer
#155 lore raw

PATCH 155/194 virtio-net: Zero max_tx_vq field for VIRTIO_NET_CTRL_MQ_HASH_CONFIG case

In reply to Greg Kroah-Hartman

From: Hawkins Jiawei <[email protected]>

commit 2c507ce90e02cd78d00fd4b0fe26c8641873c13f upstream.

Kernel uses struct virtio_net_ctrl_rss to save command-specific-data for both the VIRTIO_NET_CTRL_MQ_HASH_CONFIG and VIRTIO_NET_CTRL_MQ_RSS_CONFIG commands.

According to the VirtIO standard, "Field reserved MUST contain zeroes. It is defined to make the structure to match the layout of virtio_net_rss_config structure, defined in 5.1.6.5.7.".

Yet for the VIRTIO_NET_CTRL_MQ_HASH_CONFIG command case, the max_tx_vq field in struct virtio_net_ctrl_rss, which corresponds to the reserved field in struct virtio_net_hash_config, is not zeroed, thereby violating the VirtIO standard.

This patch solves this problem by zeroing this field in virtnet_init_default_rss().

Cc Andrew Melnychenko <[email protected]>
Fixes c7114b1249fa ("drivers/net/virtio_net: Added basic RSS support.")

Message-Id: <[email protected]>

---
 drivers/net/virtio_net.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/virtio_net.c +1 -1
@@ -2504,7 +2504,7 @@ static void virtnet_init_default_rss(str
 		vi->ctrl->rss.indirection_table[i] = indir_val;
 	}
 
-	vi->ctrl->rss.max_tx_vq = vi->curr_queue_pairs;
+	vi->ctrl->rss.max_tx_vq = vi->has_rss ? vi->curr_queue_pairs : 0;
 	vi->ctrl->rss.hash_key_length = vi->rss_key_size;
 
 	netdev_rss_key_fill(vi->ctrl->rss.key, vi->rss_key_size);
author maintainer
#156 lore raw

PATCH 156/194 arm64: dts: rockchip: Fix Wifi/Bluetooth on ROCK Pi 4 boards

In reply to Greg Kroah-Hartman

From: Yogesh Hegde <[email protected]>

commit ebceec271e552a2b05e47d8ef0597052b1a39449 upstream.

This patch fixes an issue affecting the Wifi/Bluetooth connectivity on ROCK Pi 4 boards. Commit f471b1b2db08 ("arm64: dts: rockchip: Fix Bluetooth on ROCK Pi 4 boards") introduced a problem with the clock configuration. Specifically, the clock-names property of the sdio-pwrseq node was not updated to 'lpo', causing the driver to wait indefinitely for the wrong clock signal 'ext_clock' instead of the expected one 'lpo'. This prevented the proper initialization of Wifi/Bluetooth chip on ROCK Pi 4 boards.

To address this, this patch updates the clock-names property of the sdio-pwrseq node to "lpo" to align with the changes made to the bluetooth node.

This patch has been tested on ROCK Pi 4B.

Fixes f471b1b2db08 ("arm64: dts: rockchip: Fix Bluetooth on ROCK Pi 4 boards")
---
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi +1 -1
@@ -45,7 +45,7 @@
 	sdio_pwrseq: sdio-pwrseq {
 		compatible = "mmc-pwrseq-simple";
 		clocks = <&rk808 1>;
-		clock-names = "ext_clock";
+		clock-names = "lpo";
 		pinctrl-names = "default";
 		pinctrl-0 = <&wifi_enable_h>;
 		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
author maintainer
#157 lore raw

PATCH 157/194 blk-crypto: dynamically allocate fallback profile

In reply to Greg Kroah-Hartman

From: Sweet Tea Dorminy <[email protected]>

commit c984ff1423ae9f70b1f28ce811856db0d9c99021 upstream.

blk_crypto_profile_init() calls lockdep_register_key(), which warns and does not register if the provided memory is a static object. blk-crypto-fallback currently has a static blk_crypto_profile and calls blk_crypto_profile_init() thereupon, resulting in the warning and failure to register.

Fortunately it is simple enough to use a dynamically allocated profile and make lockdep function correctly.

Fixes 2fb48d88e77f ("blk-crypto: use dynamic lock class for blk_crypto_profile::lock")
---
 block/blk-crypto-fallback.c | 36 +++++++++++++++++++++++-------------
 1 file changed, 23 insertions(+), 13 deletions(-)
block/blk-crypto-fallback.c +23 -13
index ad9844c5b40c..e6468eab2681 100644
@@ -78,7 +78,7 @@ static struct blk_crypto_fallback_keyslot {
 	struct crypto_skcipher *tfms[BLK_ENCRYPTION_MODE_MAX];
 } *blk_crypto_keyslots;
 
-static struct blk_crypto_profile blk_crypto_fallback_profile;
+static struct blk_crypto_profile *blk_crypto_fallback_profile;
 static struct workqueue_struct *blk_crypto_wq;
 static mempool_t *blk_crypto_bounce_page_pool;
 static struct bio_set crypto_bio_split;
@@ -292,7 +292,7 @@ static bool blk_crypto_fallback_encrypt_bio(struct bio **bio_ptr)
 	 * Get a blk-crypto-fallback keyslot that contains a crypto_skcipher for
 	 * this bio's algorithm and key.
 	 */
-	blk_st = blk_crypto_get_keyslot(&blk_crypto_fallback_profile,
+	blk_st = blk_crypto_get_keyslot(blk_crypto_fallback_profile,
 					bc->bc_key, &slot);
 	if (blk_st != BLK_STS_OK) {
 		src_bio->bi_status = blk_st;
@@ -395,7 +395,7 @@ static void blk_crypto_fallback_decrypt_bio(struct work_struct *work)
 	 * Get a blk-crypto-fallback keyslot that contains a crypto_skcipher for
 	 * this bio's algorithm and key.
 	 */
-	blk_st = blk_crypto_get_keyslot(&blk_crypto_fallback_profile,
+	blk_st = blk_crypto_get_keyslot(blk_crypto_fallback_profile,
 					bc->bc_key, &slot);
 	if (blk_st != BLK_STS_OK) {
 		bio->bi_status = blk_st;
@@ -499,7 +499,7 @@ bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr)
 		return false;
 	}
 
-	if (!__blk_crypto_cfg_supported(&blk_crypto_fallback_profile,
+	if (!__blk_crypto_cfg_supported(blk_crypto_fallback_profile,
 					&bc->bc_key->crypto_cfg)) {
 		bio->bi_status = BLK_STS_NOTSUPP;
 		return false;
@@ -526,7 +526,7 @@ bool blk_crypto_fallback_bio_prep(struct bio **bio_ptr)
 
 int blk_crypto_fallback_evict_key(const struct blk_crypto_key *key)
 {
-	return __blk_crypto_evict_key(&blk_crypto_fallback_profile, key);
+	return __blk_crypto_evict_key(blk_crypto_fallback_profile, key);
 }
 
 static bool blk_crypto_fallback_inited;
@@ -534,7 +534,6 @@ static int blk_crypto_fallback_init(void)
 {
 	int i;
 	int err;
-	struct blk_crypto_profile *profile = &blk_crypto_fallback_profile;
 
 	if (blk_crypto_fallback_inited)
 		return 0;
@@ -545,18 +544,27 @@ static int blk_crypto_fallback_init(void)
 	if (err)
 		goto out;
 
-	err = blk_crypto_profile_init(profile, blk_crypto_num_keyslots);
-	if (err)
+	/* Dynamic allocation is needed because of lockdep_register_key(). */
+	blk_crypto_fallback_profile =
+		kzalloc(sizeof(*blk_crypto_fallback_profile), GFP_KERNEL);
+	if (!blk_crypto_fallback_profile) {
+		err = -ENOMEM;
 		goto fail_free_bioset;
+	}
+
+	err = blk_crypto_profile_init(blk_crypto_fallback_profile,
+				      blk_crypto_num_keyslots);
+	if (err)
+		goto fail_free_profile;
 	err = -ENOMEM;
 
-	profile->ll_ops = blk_crypto_fallback_ll_ops;
-	profile->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE;
+	blk_crypto_fallback_profile->ll_ops = blk_crypto_fallback_ll_ops;
+	blk_crypto_fallback_profile->max_dun_bytes_supported = BLK_CRYPTO_MAX_IV_SIZE;
 
 	/* All blk-crypto modes have a crypto API fallback. */
 	for (i = 0; i < BLK_ENCRYPTION_MODE_MAX; i++)
-		profile->modes_supported[i] = 0xFFFFFFFF;
-	profile->modes_supported[BLK_ENCRYPTION_MODE_INVALID] = 0;
+		blk_crypto_fallback_profile->modes_supported[i] = 0xFFFFFFFF;
+	blk_crypto_fallback_profile->modes_supported[BLK_ENCRYPTION_MODE_INVALID] = 0;
 
 	blk_crypto_wq = alloc_workqueue("blk_crypto_wq",
 					WQ_UNBOUND | WQ_HIGHPRI |
@@ -597,7 +605,9 @@ static int blk_crypto_fallback_init(void)
 fail_free_wq:
 	destroy_workqueue(blk_crypto_wq);
 fail_destroy_profile:
-	blk_crypto_profile_destroy(profile);
+	blk_crypto_profile_destroy(blk_crypto_fallback_profile);
+fail_free_profile:
+	kfree(blk_crypto_fallback_profile);
 fail_free_bioset:
 	bioset_exit(&crypto_bio_split);
 out:
Signature · 1 line
2.41.0
author maintainer
#158 lore raw

PATCH 158/194 mmc: wbsd: fix double mmc_free_host() in wbsd_init()

In reply to Greg Kroah-Hartman

From: Yang Yingliang <[email protected]>

commit d83035433701919ac6db15f7737cbf554c36c1a6 upstream.

mmc_free_host() has already be called in wbsd_free_mmc(), remove the mmc_free_host() in error path in wbsd_init().

Fixes dc5b9b50fc9d ("mmc: wbsd: fix return value check of mmc_add_host()")
---
 drivers/mmc/host/wbsd.c |    2 --
 1 file changed, 2 deletions(-)
drivers/mmc/host/wbsd.c +0 -2
@@ -1705,8 +1705,6 @@ static int wbsd_init(struct device *dev,
 
 		wbsd_release_resources(host);
 		wbsd_free_mmc(dev);
-
-		mmc_free_host(mmc);
 		return ret;
 	}
 
author maintainer
#159 lore raw

PATCH 159/194 mmc: block: Fix in_flight[issue_type] value error

In reply to Greg Kroah-Hartman

From: Yibin Ding <[email protected]>

commit 4b430d4ac99750ee2ae2f893f1055c7af1ec3dc5 upstream.

For a completed request, after the mmc_blk_mq_complete_rq(mq, req) function is executed, the bitmap_tags corresponding to the request will be cleared, that is, the request will be regarded as idle. If the request is acquired by a different type of process at this time, the issue_type of the request may change. It further caused the value of mq->in_flight[issue_type] to be abnormal, and a large number of requests could not be sent.

p1: p2:
mmc_blk_mq_complete_rq
blk_mq_free_request
blk_mq_get_request
blk_mq_rq_ctx_init
mmc_blk_mq_dec_in_flight
mmc_issue_type(mq, req)

This strategy can ensure the consistency of issue_type before and after executing mmc_blk_mq_complete_rq.

---
 drivers/mmc/core/block.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/mmc/core/block.c +4 -3
@@ -2097,14 +2097,14 @@ static void mmc_blk_mq_poll_completion(s
 	mmc_blk_urgent_bkops(mq, mqrq);
 }
 
-static void mmc_blk_mq_dec_in_flight(struct mmc_queue *mq, struct request *req)
+static void mmc_blk_mq_dec_in_flight(struct mmc_queue *mq, enum mmc_issue_type issue_type)
 {
 	unsigned long flags;
 	bool put_card;
 
 	spin_lock_irqsave(&mq->lock, flags);
 
-	mq->in_flight[mmc_issue_type(mq, req)] -= 1;
+	mq->in_flight[issue_type] -= 1;
 
 	put_card = (mmc_tot_in_flight(mq) == 0);
 
@@ -2117,6 +2117,7 @@ static void mmc_blk_mq_dec_in_flight(str
 static void mmc_blk_mq_post_req(struct mmc_queue *mq, struct request *req,
 				bool can_sleep)
 {
+	enum mmc_issue_type issue_type = mmc_issue_type(mq, req);
 	struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
 	struct mmc_request *mrq = &mqrq->brq.mrq;
 	struct mmc_host *host = mq->card->host;
@@ -2136,7 +2137,7 @@ static void mmc_blk_mq_post_req(struct m
 			blk_mq_complete_request(req);
 	}
 
-	mmc_blk_mq_dec_in_flight(mq, req);
+	mmc_blk_mq_dec_in_flight(mq, issue_type);
 }
 
 void mmc_blk_mq_recovery(struct mmc_queue *mq)
author maintainer
#160 lore raw

PATCH 160/194 drm/qxl: fix UAF on handle creation

In reply to Greg Kroah-Hartman

From: Wander Lairson Costa <[email protected]>

commit c611589b4259ed63b9b77be6872b1ce07ec0ac16 upstream.

qxl_mode_dumb_create() dereferences the qobj returned by qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it.

A potential attacker could guess the returned handle value and closes it between the return of qxl_gem_object_create_with_handle() and the qobj usage, triggering a use-after-free scenario.

Reproducer:

int dri_fd =-1;
struct drm_mode_create_dumb arg = {0};

void gem_close(int handle);

void* trigger(void* ptr)

{
	int ret;
	arg.width = arg.height = 0x20;
	arg.bpp = 32;
	ret = ioctl(dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, &arg);
	if(ret)
	{
		perror("[*] DRM_IOCTL_MODE_CREATE_DUMB Failed");
		exit(-1);
	}
	gem_close(arg.handle);
	while(1) {
		struct drm_mode_create_dumb args = {0};
		args.width = args.height = 0x20;
		args.bpp = 32;
		ret = ioctl(dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, &args);
		if (ret) {
			perror("[*] DRM_IOCTL_MODE_CREATE_DUMB Failed");
			exit(-1);
		}

		printf("[*] DRM_IOCTL_MODE_CREATE_DUMB created, %d\n", args.handle);
		gem_close(args.handle);
	}
	return NULL;
}

void gem_close(int handle)

{
	struct drm_gem_close args;
	args.handle = handle;
	int ret = ioctl(dri_fd, DRM_IOCTL_GEM_CLOSE, &args); // gem close handle
	if (!ret)
		printf("gem close handle %d\n", args.handle);
}

int main(void)

{
	dri_fd= open("/dev/dri/card0", O_RDWR);
	printf("fd:%d\n", dri_fd);

	if(dri_fd == -1)
		return -1;

	pthread_t tid1;

	if(pthread_create(&tid1,NULL,trigger,NULL)){
		perror("[*] thread_create tid1\n");
		return -1;
	}
	while (1)
	{
		gem_close(arg.handle);
	}
	return 0;
}

This is a KASAN report:

==================================================================

BUG: KASAN: slab-use-after-free in qxl_mode_dumb_create+0x3c2/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:69
Write of size 1 at addr ffff88801136c240 by task poc/515

CPU: 1 PID: 515 Comm: poc Not tainted 6.3.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
Call Trace:
<TASK>
__dump_stack linux/lib/dump_stack.c:88
dump_stack_lvl+0x48/0x70 linux/lib/dump_stack.c:106
print_address_description linux/mm/kasan/report.c:319
print_report+0xd2/0x660 linux/mm/kasan/report.c:430
kasan_report+0xd2/0x110 linux/mm/kasan/report.c:536
__asan_report_store1_noabort+0x17/0x30 linux/mm/kasan/report_generic.c:383
qxl_mode_dumb_create+0x3c2/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:69
drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96
drm_mode_create_dumb_ioctl+0x1f5/0x2d0 linux/drivers/gpu/drm/drm_dumb_buffers.c:102
drm_ioctl_kernel+0x21d/0x430 linux/drivers/gpu/drm/drm_ioctl.c:788
drm_ioctl+0x56f/0xcc0 linux/drivers/gpu/drm/drm_ioctl.c:891
vfs_ioctl linux/fs/ioctl.c:51
__do_sys_ioctl linux/fs/ioctl.c:870
__se_sys_ioctl linux/fs/ioctl.c:856
__x64_sys_ioctl+0x13d/0x1c0 linux/fs/ioctl.c:856
do_syscall_x64 linux/arch/x86/entry/common.c:50
do_syscall_64+0x5b/0x90 linux/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x72/0xdc linux/arch/x86/entry/entry_64.S:120
RIP: 0033:0x7ff5004ff5f7
Code: 00 00 00 48 8b 05 99 c8 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 c8 0d 00 f7 d8 64 89 01 48

RSP: 002b:00007ff500408ea8 EFLAGS: 00000286 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff5004ff5f7
RDX: 00007ff500408ec0 RSI: 00000000c02064b2 RDI: 0000000000000003
RBP: 00007ff500408ef0 R08: 0000000000000000 R09: 000000000000002a
R10: 0000000000000000 R11: 0000000000000286 R12: 00007fff1c6cdafe
R13: 00007fff1c6cdaff R14: 00007ff500408fc0 R15: 0000000000802000

</TASK>

Allocated by task 515:
kasan_save_stack+0x38/0x70 linux/mm/kasan/common.c:45
kasan_set_track+0x25/0x40 linux/mm/kasan/common.c:52
kasan_save_alloc_info+0x1e/0x40 linux/mm/kasan/generic.c:510
____kasan_kmalloc linux/mm/kasan/common.c:374
__kasan_kmalloc+0xc3/0xd0 linux/mm/kasan/common.c:383
kasan_kmalloc linux/./include/linux/kasan.h:196
kmalloc_trace+0x48/0xc0 linux/mm/slab_common.c:1066
kmalloc linux/./include/linux/slab.h:580
kzalloc linux/./include/linux/slab.h:720
qxl_bo_create+0x11a/0x610 linux/drivers/gpu/drm/qxl/qxl_object.c:124
qxl_gem_object_create+0xd9/0x360 linux/drivers/gpu/drm/qxl/qxl_gem.c:58
qxl_gem_object_create_with_handle+0xa1/0x180 linux/drivers/gpu/drm/qxl/qxl_gem.c:89
qxl_mode_dumb_create+0x1cd/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:63
drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96
drm_mode_create_dumb_ioctl+0x1f5/0x2d0 linux/drivers/gpu/drm/drm_dumb_buffers.c:102
drm_ioctl_kernel+0x21d/0x430 linux/drivers/gpu/drm/drm_ioctl.c:788
drm_ioctl+0x56f/0xcc0 linux/drivers/gpu/drm/drm_ioctl.c:891
vfs_ioctl linux/fs/ioctl.c:51
__do_sys_ioctl linux/fs/ioctl.c:870
__se_sys_ioctl linux/fs/ioctl.c:856
__x64_sys_ioctl+0x13d/0x1c0 linux/fs/ioctl.c:856
do_syscall_x64 linux/arch/x86/entry/common.c:50
do_syscall_64+0x5b/0x90 linux/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x72/0xdc linux/arch/x86/entry/entry_64.S:120

Freed by task 515:
kasan_save_stack+0x38/0x70 linux/mm/kasan/common.c:45
kasan_set_track+0x25/0x40 linux/mm/kasan/common.c:52
kasan_save_free_info+0x2e/0x60 linux/mm/kasan/generic.c:521
____kasan_slab_free linux/mm/kasan/common.c:236
____kasan_slab_free+0x180/0x1f0 linux/mm/kasan/common.c:200
__kasan_slab_free+0x12/0x30 linux/mm/kasan/common.c:244
kasan_slab_free linux/./include/linux/kasan.h:162
slab_free_hook linux/mm/slub.c:1781
slab_free_freelist_hook+0xd2/0x1a0 linux/mm/slub.c:1807
slab_free linux/mm/slub.c:3787
__kmem_cache_free+0x196/0x2d0 linux/mm/slub.c:3800
kfree+0x78/0x120 linux/mm/slab_common.c:1019
qxl_ttm_bo_destroy+0x140/0x1a0 linux/drivers/gpu/drm/qxl/qxl_object.c:49
ttm_bo_release+0x678/0xa30 linux/drivers/gpu/drm/ttm/ttm_bo.c:381
kref_put linux/./include/linux/kref.h:65
ttm_bo_put+0x50/0x80 linux/drivers/gpu/drm/ttm/ttm_bo.c:393
qxl_gem_object_free+0x3e/0x60 linux/drivers/gpu/drm/qxl/qxl_gem.c:42
drm_gem_object_free+0x5c/0x90 linux/drivers/gpu/drm/drm_gem.c:974
kref_put linux/./include/linux/kref.h:65
__drm_gem_object_put linux/./include/drm/drm_gem.h:431
drm_gem_object_put linux/./include/drm/drm_gem.h:444
qxl_gem_object_create_with_handle+0x151/0x180 linux/drivers/gpu/drm/qxl/qxl_gem.c:100
qxl_mode_dumb_create+0x1cd/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:63
drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96
drm_mode_create_dumb_ioctl+0x1f5/0x2d0 linux/drivers/gpu/drm/drm_dumb_buffers.c:102
drm_ioctl_kernel+0x21d/0x430 linux/drivers/gpu/drm/drm_ioctl.c:788
drm_ioctl+0x56f/0xcc0 linux/drivers/gpu/drm/drm_ioctl.c:891
vfs_ioctl linux/fs/ioctl.c:51
__do_sys_ioctl linux/fs/ioctl.c:870
__se_sys_ioctl linux/fs/ioctl.c:856
__x64_sys_ioctl+0x13d/0x1c0 linux/fs/ioctl.c:856
do_syscall_x64 linux/arch/x86/entry/common.c:50
do_syscall_64+0x5b/0x90 linux/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x72/0xdc linux/arch/x86/entry/entry_64.S:120

The buggy address belongs to the object at ffff88801136c000

which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 576 bytes inside of freed 1024-byte region [ffff88801136c000, ffff88801136c400)

The buggy address belongs to the physical page:
page:0000000089fc329b refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11368
head:0000000089fc329b order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0010200 ffff888007841dc0 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff88801136c100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801136c180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88801136c200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

^
ffff88801136c280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88801136c300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint

Instead of returning a weak reference to the qxl_bo object, return the created drm_gem_object and let the caller decrement the reference count when it no longer needs it. As a convenience, if the caller is not interested in the gobj object, it can pass NULL to the parameter and the reference counting is descremented internally.

The bug and the reproducer were originally found by the Zero Day Initiative project (ZDI-CAN-20940).

---
 drivers/gpu/drm/qxl/qxl_drv.h   |    2 +-
 drivers/gpu/drm/qxl/qxl_dumb.c  |    5 ++++-
 drivers/gpu/drm/qxl/qxl_gem.c   |   25 +++++++++++++++++--------
 drivers/gpu/drm/qxl/qxl_ioctl.c |    6 ++----
 4 files changed, 24 insertions(+), 14 deletions(-)
drivers/gpu/drm/qxl/qxl_drv.h +1 -1
@@ -312,7 +312,7 @@ int qxl_gem_object_create_with_handle(st
 				      u32 domain,
 				      size_t size,
 				      struct qxl_surface *surf,
-				      struct qxl_bo **qobj,
+				      struct drm_gem_object **gobj,
 				      uint32_t *handle);
 void qxl_gem_object_free(struct drm_gem_object *gobj);
 int qxl_gem_object_open(struct drm_gem_object *obj, struct drm_file *file_priv);
drivers/gpu/drm/qxl/qxl_dumb.c +4 -1
@@ -34,6 +34,7 @@ int qxl_mode_dumb_create(struct drm_file
 {
 	struct qxl_device *qdev = to_qxl(dev);
 	struct qxl_bo *qobj;
+	struct drm_gem_object *gobj;
 	uint32_t handle;
 	int r;
 	struct qxl_surface surf;
@@ -62,11 +63,13 @@ int qxl_mode_dumb_create(struct drm_file
 
 	r = qxl_gem_object_create_with_handle(qdev, file_priv,
 					      QXL_GEM_DOMAIN_CPU,
-					      args->size, &surf, &qobj,
+					      args->size, &surf, &gobj,
 					      &handle);
 	if (r)
 		return r;
+	qobj = gem_to_qxl_bo(gobj);
 	qobj->is_dumb = true;
+	drm_gem_object_put(gobj);
 	args->pitch = pitch;
 	args->handle = handle;
 	return 0;
drivers/gpu/drm/qxl/qxl_gem.c +17 -8
@@ -72,32 +72,41 @@ int qxl_gem_object_create(struct qxl_dev
 	return 0;
 }
 
+/*
+ * If the caller passed a valid gobj pointer, it is responsible to call
+ * drm_gem_object_put() when it no longer needs to acess the object.
+ *
+ * If gobj is NULL, it is handled internally.
+ */
 int qxl_gem_object_create_with_handle(struct qxl_device *qdev,
 				      struct drm_file *file_priv,
 				      u32 domain,
 				      size_t size,
 				      struct qxl_surface *surf,
-				      struct qxl_bo **qobj,
+				      struct drm_gem_object **gobj,
 				      uint32_t *handle)
 {
-	struct drm_gem_object *gobj;
 	int r;
+	struct drm_gem_object *local_gobj;
 
-	BUG_ON(!qobj);
 	BUG_ON(!handle);
 
 	r = qxl_gem_object_create(qdev, size, 0,
 				  domain,
 				  false, false, surf,
-				  &gobj);
+				  &local_gobj);
 	if (r)
 		return -ENOMEM;
-	r = drm_gem_handle_create(file_priv, gobj, handle);
+	r = drm_gem_handle_create(file_priv, local_gobj, handle);
 	if (r)
 		return r;
-	/* drop reference from allocate - handle holds it now */
-	*qobj = gem_to_qxl_bo(gobj);
-	drm_gem_object_put(gobj);
+
+	if (gobj)
+		*gobj = local_gobj;
+	else
+		/* drop reference from allocate - handle holds it now */
+		drm_gem_object_put(local_gobj);
+
 	return 0;
 }
 
drivers/gpu/drm/qxl/qxl_ioctl.c +2 -4
@@ -38,7 +38,6 @@ int qxl_alloc_ioctl(struct drm_device *d
 	struct qxl_device *qdev = to_qxl(dev);
 	struct drm_qxl_alloc *qxl_alloc = data;
 	int ret;
-	struct qxl_bo *qobj;
 	uint32_t handle;
 	u32 domain = QXL_GEM_DOMAIN_VRAM;
 
@@ -50,7 +49,7 @@ int qxl_alloc_ioctl(struct drm_device *d
 						domain,
 						qxl_alloc->size,
 						NULL,
-						&qobj, &handle);
+						NULL, &handle);
 	if (ret) {
 		DRM_ERROR("%s: failed to create gem ret=%d\n",
 			  __func__, ret);
@@ -386,7 +385,6 @@ int qxl_alloc_surf_ioctl(struct drm_devi
 {
 	struct qxl_device *qdev = to_qxl(dev);
 	struct drm_qxl_alloc_surf *param = data;
-	struct qxl_bo *qobj;
 	int handle;
 	int ret;
 	int size, actual_stride;
@@ -406,7 +404,7 @@ int qxl_alloc_surf_ioctl(struct drm_devi
 						QXL_GEM_DOMAIN_SURFACE,
 						size,
 						&surf,
-						&qobj, &handle);
+						NULL, &handle);
 	if (ret) {
 		DRM_ERROR("%s: failed to create gem ret=%d\n",
 			  __func__, ret);
author maintainer
#161 lore raw

PATCH 161/194 drm/i915/sdvo: fix panel_type initialization

In reply to Greg Kroah-Hartman

From: Jani Nikula <[email protected]>

commit 2002eb6d3ea954dde9f8a223018d5335779937d0 upstream.

Commit 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") started using -1 as the value for unset panel_type. It gets initialized in intel_panel_init_alloc(), but the SDVO code never calls it.

Call intel_panel_init_alloc() to initialize the panel, including the panel_type.

Fixes 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type")
Cc Ville Syrjälä <[email protected]>
Cc <[email protected]> # v6.1+
(cherry picked from commit 26e60294e8eacedc8ebb33405b2c375fd80e0900)
---
 drivers/gpu/drm/i915/display/intel_sdvo.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/i915/display/intel_sdvo.c +1 -1
@@ -2727,7 +2727,7 @@ static struct intel_sdvo_connector *inte
 	__drm_atomic_helper_connector_reset(&sdvo_connector->base.base,
 					    &conn_state->base.base);
 
-	INIT_LIST_HEAD(&sdvo_connector->base.panel.fixed_modes);
+	intel_panel_init_alloc(&sdvo_connector->base);
 
 	return sdvo_connector;
 }
author maintainer
#162 lore raw

PATCH 162/194 drm/amd: flush any delayed gfxoff on suspend entry

In reply to Greg Kroah-Hartman

From: Mario Limonciello <[email protected]>

commit a7b7d9e8aee4f71b4c7151702fd74237b8cef989 upstream.

DCN 3.1.4 is reported to hang on s2idle entry if graphics activity is happening during entry. This is because GFXOFF was scheduled as delayed but RLC gets disabled in s2idle entry sequence which will hang GFX IP if not already in GFXOFF.

To help this problem, flush any delayed work for GFXOFF early in s2idle entry sequence to ensure that it's off when RLC is changed.

commit 4b31b92b143f ("drm/amdgpu: complete gfxoff allow signal during suspend without delay") modified power gating flow so that if called in s0ix that it ensured that GFXOFF wasn't put in work queue but instead processed immediately.

This is dead code due to commit 10cb67eb8a1b ("drm/amdgpu: skip CG/PG for gfx during S0ix") because GFXOFF will now not be explicitly called as part of the suspend entry code. Remove that dead code.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |    1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c    |    9 +--------
 2 files changed, 2 insertions(+), 8 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +1 -0
@@ -4232,6 +4232,7 @@ int amdgpu_device_suspend(struct drm_dev
 		drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)->fb_helper, true);
 
 	cancel_delayed_work_sync(&adev->delayed_init_work);
+	flush_delayed_work(&adev->gfx.gfx_off_delay_work);
 
 	amdgpu_ras_suspend(adev);
 
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c +1 -8
@@ -585,15 +585,8 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_d
 
 		if (adev->gfx.gfx_off_req_count == 0 &&
 		    !adev->gfx.gfx_off_state) {
-			/* If going to s2idle, no need to wait */
-			if (adev->in_s0ix) {
-				if (!amdgpu_dpm_set_powergating_by_smu(adev,
-						AMD_IP_BLOCK_TYPE_GFX, true))
-					adev->gfx.gfx_off_state = true;
-			} else {
-				schedule_delayed_work(&adev->gfx.gfx_off_delay_work,
+			schedule_delayed_work(&adev->gfx.gfx_off_delay_work,
 					      delay);
-			}
 		}
 	} else {
 		if (adev->gfx.gfx_off_req_count == 0) {
author maintainer
#163 lore raw

PATCH 163/194 drm/amdgpu: skip fence GFX interrupts disable/enable for S0ix

In reply to Greg Kroah-Hartman

From: Tim Huang <[email protected]>

commit f1740b1ab2703b2a057da7cf33b03297e0381aa0 upstream.

GFX v11.0.1 reported fence fallback timer expired issue on SDMA and GFX rings after S0ix resume. This is generated by EOP interrupts are disabled when S0ix suspend but fails to re-enable when resume because of the GFX is in GFXOFF.

[  203.349571] [drm] Fence fallback timer expired on ring sdma0
[  203.349572] [drm] Fence fallback timer expired on ring gfx_0.0.0
[  203.861635] [drm] Fence fallback timer expired on ring gfx_0.0.0

For S0ix, GFX is in GFXOFF state, avoid to touch the GFX registers to configure the fence driver interrupts for rings that belong to GFX. The interrupts configuration will be restored by GFXOFF exit.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c |   41 ++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c +39 -2
@@ -502,6 +502,41 @@ int amdgpu_fence_driver_sw_init(struct a
 }
 
 /**
+ * amdgpu_fence_need_ring_interrupt_restore - helper function to check whether
+ * fence driver interrupts need to be restored.
+ *
+ * @ring: ring that to be checked
+ *
+ * Interrupts for rings that belong to GFX IP don't need to be restored
+ * when the target power state is s0ix.
+ *
+ * Return true if need to restore interrupts, false otherwise.
+ */
+static bool amdgpu_fence_need_ring_interrupt_restore(struct amdgpu_ring *ring)
+{
+	struct amdgpu_device *adev = ring->adev;
+	bool is_gfx_power_domain = false;
+
+	switch (ring->funcs->type) {
+	case AMDGPU_RING_TYPE_SDMA:
+	/* SDMA 5.x+ is part of GFX power domain so it's covered by GFXOFF */
+		if (adev->ip_versions[SDMA0_HWIP][0] >= IP_VERSION(5, 0, 0))
+			is_gfx_power_domain = true;
+		break;
+	case AMDGPU_RING_TYPE_GFX:
+	case AMDGPU_RING_TYPE_COMPUTE:
+	case AMDGPU_RING_TYPE_KIQ:
+	case AMDGPU_RING_TYPE_MES:
+		is_gfx_power_domain = true;
+		break;
+	default:
+		break;
+	}
+
+	return !(adev->in_s0ix && is_gfx_power_domain);
+}
+
+/**
  * amdgpu_fence_driver_hw_fini - tear down the fence driver
  * for all possible rings.
  *
@@ -529,7 +564,8 @@ void amdgpu_fence_driver_hw_fini(struct
 			amdgpu_fence_driver_force_completion(ring);
 
 		if (!drm_dev_is_unplugged(adev_to_drm(adev)) &&
-		    ring->fence_drv.irq_src)
+		    ring->fence_drv.irq_src &&
+		    amdgpu_fence_need_ring_interrupt_restore(ring))
 			amdgpu_irq_put(adev, ring->fence_drv.irq_src,
 				       ring->fence_drv.irq_type);
 
@@ -604,7 +640,8 @@ void amdgpu_fence_driver_hw_init(struct
 			continue;
 
 		/* enable the interrupt */
-		if (ring->fence_drv.irq_src)
+		if (ring->fence_drv.irq_src &&
+		    amdgpu_fence_need_ring_interrupt_restore(ring))
 			amdgpu_irq_get(adev, ring->fence_drv.irq_src,
 				       ring->fence_drv.irq_type);
 	}
author maintainer
#164 lore raw

PATCH 164/194 drm/amdgpu/pm: fix throttle_status for other than MP1 11.0.7

In reply to Greg Kroah-Hartman

From: Umio Yasuno <[email protected]>

commit 6a92761a86817ad15c9a562e2a809386237fae3e upstream.

Use the right metrics table version based on the firmware.

---
 drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +7 -7
@@ -588,7 +588,9 @@ err0_out:
 	return -ENOMEM;
 }
 
-static uint32_t sienna_cichlid_get_throttler_status_locked(struct smu_context *smu)
+static uint32_t sienna_cichlid_get_throttler_status_locked(struct smu_context *smu,
+							   bool use_metrics_v3,
+							   bool use_metrics_v2)
 {
 	struct smu_table_context *smu_table= &smu->smu_table;
 	SmuMetricsExternal_t *metrics_ext =
@@ -596,13 +598,11 @@ static uint32_t sienna_cichlid_get_throt
 	uint32_t throttler_status = 0;
 	int i;
 
-	if ((smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(11, 0, 7)) &&
-	     (smu->smc_fw_version >= 0x3A4900)) {
+	if (use_metrics_v3) {
 		for (i = 0; i < THROTTLER_COUNT; i++)
 			throttler_status |=
 				(metrics_ext->SmuMetrics_V3.ThrottlingPercentage[i] ? 1U << i : 0);
-	} else if ((smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(11, 0, 7)) &&
-	     (smu->smc_fw_version >= 0x3A4300)) {
+	} else if (use_metrics_v2) {
 		for (i = 0; i < THROTTLER_COUNT; i++)
 			throttler_status |=
 				(metrics_ext->SmuMetrics_V2.ThrottlingPercentage[i] ? 1U << i : 0);
@@ -864,7 +864,7 @@ static int sienna_cichlid_get_smu_metric
 			metrics->TemperatureVrSoc) * SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
 		break;
 	case METRICS_THROTTLER_STATUS:
-		*value = sienna_cichlid_get_throttler_status_locked(smu);
+		*value = sienna_cichlid_get_throttler_status_locked(smu, use_metrics_v3, use_metrics_v2);
 		break;
 	case METRICS_CURR_FANSPEED:
 		*value = use_metrics_v3 ? metrics_v3->CurrFanSpeed :
@@ -4017,7 +4017,7 @@ static ssize_t sienna_cichlid_get_gpu_me
 	gpu_metrics->current_dclk1 = use_metrics_v3 ? metrics_v3->CurrClock[PPCLK_DCLK_1] :
 		use_metrics_v2 ? metrics_v2->CurrClock[PPCLK_DCLK_1] : metrics->CurrClock[PPCLK_DCLK_1];
 
-	gpu_metrics->throttle_status = sienna_cichlid_get_throttler_status_locked(smu);
+	gpu_metrics->throttle_status = sienna_cichlid_get_throttler_status_locked(smu, use_metrics_v3, use_metrics_v2);
 	gpu_metrics->indep_throttle_status =
 			smu_cmn_get_indep_throttler_status(gpu_metrics->throttle_status,
 							   sienna_cichlid_throttler_map);
author maintainer
#165 lore raw

PATCH 165/194 ASoC: amd: vangogh: select CONFIG_SND_AMD_ACP_CONFIG

In reply to Greg Kroah-Hartman

From: Arnd Bergmann <[email protected]>

commit 812a05256d673b2b9c5db906775d1e6625ba4787 upstream.

The vangogh driver just gained a link time dependency that now causes randconfig builds to fail:

x86_64-linux-ld: sound/soc/amd/vangogh/pci-acp5x.o: in function `snd_acp5x_probe':
pci-acp5x.c:(.text+0xbb): undefined reference to `snd_amd_acp_find_config'

Fixes e89f45edb747e ("ASoC: amd: vangogh: Add check for acp config flags in vangogh platform")
---
 sound/soc/amd/Kconfig |    1 +
 1 file changed, 1 insertion(+)
sound/soc/amd/Kconfig +1 -0
@@ -81,6 +81,7 @@ config SND_SOC_AMD_VANGOGH_MACH
 	tristate "AMD Vangogh support for NAU8821 CS35L41"
 	select SND_SOC_NAU8821
 	select SND_SOC_CS35L41_SPI
+	select SND_AMD_ACP_CONFIG
 	depends on SND_SOC_AMD_ACP5x && I2C && SPI_MASTER
 	help
 	  This option enables machine driver for Vangogh platform
author maintainer
#166 lore raw

PATCH 166/194 drm/amd/display: disable RCO for DCN314

In reply to Greg Kroah-Hartman

From: Daniel Miess <[email protected]>

commit 85e41f1ed5d94a26fe4e57003c399936d291ed70 upstream.

[Why]
RCO is causing error messages on some DCN314 systems

[How]
Force disable RCO for DCN314

Fixes 17fbdbda9cc8 ("drm/amd/display: Enable dcn314 DPP RCO")
---
 drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c     |    2 +-
 drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c |    4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c +1 -1
@@ -296,7 +296,7 @@ static void dccg314_dpp_root_clock_contr
 {
 	struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg);
 
-	if (dccg->dpp_clock_gated[dpp_inst] == clock_on)
+	if (dccg->dpp_clock_gated[dpp_inst] != clock_on)
 		return;
 
 	if (clock_on) {
drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c +4 -0
@@ -1933,6 +1933,10 @@ static bool dcn314_resource_construct(
 		dc->debug = debug_defaults_drv;
 	else
 		dc->debug = debug_defaults_diags;
+
+	/* Disable root clock optimization */
+	dc->debug.root_clock_optimization.u32All = 0;
+
 	// Init the vm_helper
 	if (dc->vm_helper)
 		vm_helper_init(dc->vm_helper, 16);
author maintainer
#167 lore raw

PATCH 167/194 zsmalloc: allow only one active pool compaction context

In reply to Greg Kroah-Hartman

From: Sergey Senozhatsky <[email protected]>

commit d2658f2052c7db6ec0a79977205f8cf1cb9effc2 upstream.

zsmalloc pool can be compacted concurrently by many contexts, e.g.

cc1 handle_mm_fault()

      do_anonymous_page()
       __alloc_pages_slowpath()
        try_to_free_pages()
         do_try_to_free_pages(
          lru_gen_shrink_node()
           shrink_slab()
            do_shrink_slab()
             zs_shrinker_scan()
              zs_compact()

Pool compaction is currently (basically) single-threaded as it is performed under pool->lock. Having multiple compaction threads results in unnecessary contention, as each thread competes for pool->lock. This, in turn, affects all zsmalloc operations such as zs_malloc(), zs_map_object(), zs_free(), etc.

Introduce the pool->compaction_in_progress atomic variable, which ensures that only one compaction context can run at a time. This reduces overall pool->lock contention in (corner) cases when many contexts attempt to shrink zspool simultaneously.

Fixes c0547d0b6a4b ("zsmalloc: consolidate zs_pool's migrate_lock and size_class's locks")
Cc Minchan Kim <[email protected]>
---
 mm/zsmalloc.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)
mm/zsmalloc.c +12 -0
@@ -246,6 +246,7 @@ struct zs_pool {
 	struct work_struct free_work;
 #endif
 	spinlock_t lock;
+	atomic_t compaction_in_progress;
 };
 
 struct zspage {
@@ -2100,6 +2101,15 @@ unsigned long zs_compact(struct zs_pool
 	struct size_class *class;
 	unsigned long pages_freed = 0;
 
+	/*
+	 * Pool compaction is performed under pool->lock so it is basically
+	 * single-threaded. Having more than one thread in __zs_compact()
+	 * will increase pool->lock contention, which will impact other
+	 * zsmalloc operations that need pool->lock.
+	 */
+	if (atomic_xchg(&pool->compaction_in_progress, 1))
+		return 0;
+
 	for (i = ZS_SIZE_CLASSES - 1; i >= 0; i--) {
 		class = pool->size_class[i];
 		if (class->index != i)
@@ -2107,6 +2117,7 @@ unsigned long zs_compact(struct zs_pool
 		pages_freed += __zs_compact(pool, class);
 	}
 	atomic_long_add(pages_freed, &pool->stats.pages_compacted);
+	atomic_set(&pool->compaction_in_progress, 0);
 
 	return pages_freed;
 }
@@ -2193,6 +2204,7 @@ struct zs_pool *zs_create_pool(const cha
 
 	init_deferred_free(pool);
 	spin_lock_init(&pool->lock);
+	atomic_set(&pool->compaction_in_progress, 0);
 
 	pool->name = kstrdup(name, GFP_KERNEL);
 	if (!pool->name)
author maintainer
#168 lore raw

PATCH 168/194 sched/fair: unlink misfit task from cpu overutilized

In reply to Greg Kroah-Hartman

From: Vincent Guittot <[email protected]>

commit e5ed0550c04c5469ecdc1634d8aa18c8609590f0 upstream.

By taking into account uclamp_min, the 1:1 relation between task misfit and cpu overutilized is no more true as a task with a small util_avg may not fit a high capacity cpu because of uclamp_min constraint.

Add a new state in util_fits_cpu() to reflect the case that task would fit a CPU except for the uclamp_min hint which is a performance requirement.

Use -1 to reflect that a CPU doesn't fit only because of uclamp_min so we can use this new value to take additional action to select the best CPU that doesn't match uclamp_min hint.

When util_fits_cpu() returns -1, we will continue to look for a possible CPU with better performance, which replaces Capacity Inversion detection with capacity_orig_of() - thermal_load_avg to detect a capacity inversion.

---
 kernel/sched/fair.c |  105 ++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 82 insertions(+), 23 deletions(-)
kernel/sched/fair.c +82 -23
@@ -4549,8 +4549,8 @@ static inline int util_fits_cpu(unsigned
 	 * handle the case uclamp_min > uclamp_max.
 	 */
 	uclamp_min = min(uclamp_min, uclamp_max);
-	if (util < uclamp_min && capacity_orig != SCHED_CAPACITY_SCALE)
-		fits = fits && (uclamp_min <= capacity_orig_thermal);
+	if (fits && (util < uclamp_min) && (uclamp_min > capacity_orig_thermal))
+		return -1;
 
 	return fits;
 }
@@ -4560,7 +4560,11 @@ static inline int task_fits_cpu(struct t
 	unsigned long uclamp_min = uclamp_eff_value(p, UCLAMP_MIN);
 	unsigned long uclamp_max = uclamp_eff_value(p, UCLAMP_MAX);
 	unsigned long util = task_util_est(p);
-	return util_fits_cpu(util, uclamp_min, uclamp_max, cpu);
+	/*
+	 * Return true only if the cpu fully fits the task requirements, which
+	 * include the utilization but also the performance hints.
+	 */
+	return (util_fits_cpu(util, uclamp_min, uclamp_max, cpu) > 0);
 }
 
 static inline void update_misfit_status(struct task_struct *p, struct rq *rq)
@@ -6043,6 +6047,7 @@ static inline bool cpu_overutilized(int
 	unsigned long rq_util_min = uclamp_rq_get(cpu_rq(cpu), UCLAMP_MIN);
 	unsigned long rq_util_max = uclamp_rq_get(cpu_rq(cpu), UCLAMP_MAX);
 
+	/* Return true only if the utilization doesn't fit CPU's capacity */
 	return !util_fits_cpu(cpu_util_cfs(cpu), rq_util_min, rq_util_max, cpu);
 }
 
@@ -6836,6 +6841,7 @@ static int
 select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int target)
 {
 	unsigned long task_util, util_min, util_max, best_cap = 0;
+	int fits, best_fits = 0;
 	int cpu, best_cpu = -1;
 	struct cpumask *cpus;
 
@@ -6851,12 +6857,28 @@ select_idle_capacity(struct task_struct
 
 		if (!available_idle_cpu(cpu) && !sched_idle_cpu(cpu))
 			continue;
-		if (util_fits_cpu(task_util, util_min, util_max, cpu))
+
+		fits = util_fits_cpu(task_util, util_min, util_max, cpu);
+
+		/* This CPU fits with all requirements */
+		if (fits > 0)
 			return cpu;
+		/*
+		 * Only the min performance hint (i.e. uclamp_min) doesn't fit.
+		 * Look for the CPU with best capacity.
+		 */
+		else if (fits < 0)
+			cpu_cap = capacity_orig_of(cpu) - thermal_load_avg(cpu_rq(cpu));
 
-		if (cpu_cap > best_cap) {
+		/*
+		 * First, select CPU which fits better (-1 being better than 0).
+		 * Then, select the one with best capacity at same level.
+		 */
+		if ((fits < best_fits) ||
+		    ((fits == best_fits) && (cpu_cap > best_cap))) {
 			best_cap = cpu_cap;
 			best_cpu = cpu;
+			best_fits = fits;
 		}
 	}
 
@@ -6869,7 +6891,11 @@ static inline bool asym_fits_cpu(unsigne
 				 int cpu)
 {
 	if (sched_asym_cpucap_active())
-		return util_fits_cpu(util, util_min, util_max, cpu);
+		/*
+		 * Return true only if the cpu fully fits the task requirements
+		 * which include the utilization and the performance hints.
+		 */
+		return (util_fits_cpu(util, util_min, util_max, cpu) > 0);
 
 	return true;
 }
@@ -7236,6 +7262,9 @@ static int find_energy_efficient_cpu(str
 	unsigned long p_util_max = uclamp_is_used() ? uclamp_eff_value(p, UCLAMP_MAX) : 1024;
 	struct root_domain *rd = this_rq()->rd;
 	int cpu, best_energy_cpu, target = -1;
+	int prev_fits = -1, best_fits = -1;
+	unsigned long best_thermal_cap = 0;
+	unsigned long prev_thermal_cap = 0;
 	struct sched_domain *sd;
 	struct perf_domain *pd;
 	struct energy_env eenv;
@@ -7271,6 +7300,7 @@ static int find_energy_efficient_cpu(str
 		unsigned long prev_spare_cap = 0;
 		int max_spare_cap_cpu = -1;
 		unsigned long base_energy;
+		int fits, max_fits = -1;
 
 		cpumask_and(cpus, perf_domain_span(pd), cpu_online_mask);
 
@@ -7320,7 +7350,9 @@ static int find_energy_efficient_cpu(str
 				util_min = max(rq_util_min, p_util_min);
 				util_max = max(rq_util_max, p_util_max);
 			}
-			if (!util_fits_cpu(util, util_min, util_max, cpu))
+
+			fits = util_fits_cpu(util, util_min, util_max, cpu);
+			if (!fits)
 				continue;
 
 			lsub_positive(&cpu_cap, util);
@@ -7328,7 +7360,9 @@ static int find_energy_efficient_cpu(str
 			if (cpu == prev_cpu) {
 				/* Always use prev_cpu as a candidate. */
 				prev_spare_cap = cpu_cap;
-			} else if (cpu_cap > max_spare_cap) {
+				prev_fits = fits;
+			} else if ((fits > max_fits) ||
+				   ((fits == max_fits) && (cpu_cap > max_spare_cap))) {
 				/*
 				 * Find the CPU with the maximum spare capacity
 				 * among the remaining CPUs in the performance
@@ -7336,6 +7370,7 @@ static int find_energy_efficient_cpu(str
 				 */
 				max_spare_cap = cpu_cap;
 				max_spare_cap_cpu = cpu;
+				max_fits = fits;
 			}
 		}
 
@@ -7354,26 +7389,50 @@ static int find_energy_efficient_cpu(str
 			if (prev_delta < base_energy)
 				goto unlock;
 			prev_delta -= base_energy;
+			prev_thermal_cap = cpu_thermal_cap;
 			best_delta = min(best_delta, prev_delta);
 		}
 
 		/* Evaluate the energy impact of using max_spare_cap_cpu. */
 		if (max_spare_cap_cpu >= 0 && max_spare_cap > prev_spare_cap) {
+			/* Current best energy cpu fits better */
+			if (max_fits < best_fits)
+				continue;
+
+			/*
+			 * Both don't fit performance hint (i.e. uclamp_min)
+			 * but best energy cpu has better capacity.
+			 */
+			if ((max_fits < 0) &&
+			    (cpu_thermal_cap <= best_thermal_cap))
+				continue;
+
 			cur_delta = compute_energy(&eenv, pd, cpus, p,
 						   max_spare_cap_cpu);
 			/* CPU utilization has changed */
 			if (cur_delta < base_energy)
 				goto unlock;
 			cur_delta -= base_energy;
-			if (cur_delta < best_delta) {
-				best_delta = cur_delta;
-				best_energy_cpu = max_spare_cap_cpu;
-			}
+
+			/*
+			 * Both fit for the task but best energy cpu has lower
+			 * energy impact.
+			 */
+			if ((max_fits > 0) && (best_fits > 0) &&
+			    (cur_delta >= best_delta))
+				continue;
+
+			best_delta = cur_delta;
+			best_energy_cpu = max_spare_cap_cpu;
+			best_fits = max_fits;
+			best_thermal_cap = cpu_thermal_cap;
 		}
 	}
 	rcu_read_unlock();
 
-	if (best_delta < prev_delta)
+	if ((best_fits > prev_fits) ||
+	    ((best_fits > 0) && (best_delta < prev_delta)) ||
+	    ((best_fits < 0) && (best_thermal_cap > prev_thermal_cap)))
 		target = best_energy_cpu;
 
 	return target;
@@ -10183,24 +10242,23 @@ static struct sched_group *find_busiest_
 	 */
 	update_sd_lb_stats(env, &sds);
 
-	if (sched_energy_enabled()) {
-		struct root_domain *rd = env->dst_rq->rd;
-
-		if (rcu_dereference(rd->pd) && !READ_ONCE(rd->overutilized))
-			goto out_balanced;
-	}
-
-	local = &sds.local_stat;
-	busiest = &sds.busiest_stat;
-
 	/* There is no busy sibling group to pull tasks from */
 	if (!sds.busiest)
 		goto out_balanced;
 
+	busiest = &sds.busiest_stat;
+
 	/* Misfit tasks should be dealt with regardless of the avg load */
 	if (busiest->group_type == group_misfit_task)
 		goto force_balance;
 
+	if (sched_energy_enabled()) {
+		struct root_domain *rd = env->dst_rq->rd;
+
+		if (rcu_dereference(rd->pd) && !READ_ONCE(rd->overutilized))
+			goto out_balanced;
+	}
+
 	/* ASYM feature bypasses nice load balance check */
 	if (busiest->group_type == group_asym_packing)
 		goto force_balance;
@@ -10213,6 +10271,7 @@ static struct sched_group *find_busiest_
 	if (busiest->group_type == group_imbalanced)
 		goto force_balance;
 
+	local = &sds.local_stat;
 	/*
 	 * If the local group is busier than the selected busiest group
 	 * don't try and pull any tasks.
author maintainer
#169 lore raw

PATCH 169/194 sched/fair: Remove capacity inversion detection

In reply to Greg Kroah-Hartman

From: Vincent Guittot <[email protected]>

commit a2e90611b9f425adbbfcdaa5b5e49958ddf6f61b upstream.

Remove the capacity inversion detection which is now handled by util_fits_cpu() returning -1 when we need to continue to look for a potential CPU with better performance.

This ends up almost reverting patches below except for some comments:
commit da07d2f9c153 ("sched/fair: Fixes for capacity inversion detection") commit aa69c36f31aa ("sched/fair: Consider capacity inversion in util_fits_cpu()") commit 44c7b80bffc3 ("sched/fair: Detect capacity inversion")

---
 kernel/sched/fair.c  |   84 +++------------------------------------------------
 kernel/sched/sched.h |   19 -----------
 2 files changed, 5 insertions(+), 98 deletions(-)
kernel/sched/fair.c +5 -79
@@ -4464,17 +4464,9 @@ static inline int util_fits_cpu(unsigned
 	 *
 	 * For uclamp_max, we can tolerate a drop in performance level as the
 	 * goal is to cap the task. So it's okay if it's getting less.
-	 *
-	 * In case of capacity inversion we should honour the inverted capacity
-	 * for both uclamp_min and uclamp_max all the time.
 	 */
-	capacity_orig = cpu_in_capacity_inversion(cpu);
-	if (capacity_orig) {
-		capacity_orig_thermal = capacity_orig;
-	} else {
-		capacity_orig = capacity_orig_of(cpu);
-		capacity_orig_thermal = capacity_orig - arch_scale_thermal_pressure(cpu);
-	}
+	capacity_orig = capacity_orig_of(cpu);
+	capacity_orig_thermal = capacity_orig - arch_scale_thermal_pressure(cpu);
 
 	/*
 	 * We want to force a task to fit a cpu as implied by uclamp_max.
@@ -8929,82 +8921,16 @@ static unsigned long scale_rt_capacity(i
 
 static void update_cpu_capacity(struct sched_domain *sd, int cpu)
 {
-	unsigned long capacity_orig = arch_scale_cpu_capacity(cpu);
 	unsigned long capacity = scale_rt_capacity(cpu);
 	struct sched_group *sdg = sd->groups;
-	struct rq *rq = cpu_rq(cpu);
 
-	rq->cpu_capacity_orig = capacity_orig;
+	cpu_rq(cpu)->cpu_capacity_orig = arch_scale_cpu_capacity(cpu);
 
 	if (!capacity)
 		capacity = 1;
 
-	rq->cpu_capacity = capacity;
-
-	/*
-	 * Detect if the performance domain is in capacity inversion state.
-	 *
-	 * Capacity inversion happens when another perf domain with equal or
-	 * lower capacity_orig_of() ends up having higher capacity than this
-	 * domain after subtracting thermal pressure.
-	 *
-	 * We only take into account thermal pressure in this detection as it's
-	 * the only metric that actually results in *real* reduction of
-	 * capacity due to performance points (OPPs) being dropped/become
-	 * unreachable due to thermal throttling.
-	 *
-	 * We assume:
-	 *   * That all cpus in a perf domain have the same capacity_orig
-	 *     (same uArch).
-	 *   * Thermal pressure will impact all cpus in this perf domain
-	 *     equally.
-	 */
-	if (sched_energy_enabled()) {
-		unsigned long inv_cap = capacity_orig - thermal_load_avg(rq);
-		struct perf_domain *pd;
-
-		rcu_read_lock();
-
-		pd = rcu_dereference(rq->rd->pd);
-		rq->cpu_capacity_inverted = 0;
-
-		for (; pd; pd = pd->next) {
-			struct cpumask *pd_span = perf_domain_span(pd);
-			unsigned long pd_cap_orig, pd_cap;
-
-			/* We can't be inverted against our own pd */
-			if (cpumask_test_cpu(cpu_of(rq), pd_span))
-				continue;
-
-			cpu = cpumask_any(pd_span);
-			pd_cap_orig = arch_scale_cpu_capacity(cpu);
-
-			if (capacity_orig < pd_cap_orig)
-				continue;
-
-			/*
-			 * handle the case of multiple perf domains have the
-			 * same capacity_orig but one of them is under higher
-			 * thermal pressure. We record it as capacity
-			 * inversion.
-			 */
-			if (capacity_orig == pd_cap_orig) {
-				pd_cap = pd_cap_orig - thermal_load_avg(cpu_rq(cpu));
-
-				if (pd_cap > inv_cap) {
-					rq->cpu_capacity_inverted = inv_cap;
-					break;
-				}
-			} else if (pd_cap_orig > inv_cap) {
-				rq->cpu_capacity_inverted = inv_cap;
-				break;
-			}
-		}
-
-		rcu_read_unlock();
-	}
-
-	trace_sched_cpu_capacity_tp(rq);
+	cpu_rq(cpu)->cpu_capacity = capacity;
+	trace_sched_cpu_capacity_tp(cpu_rq(cpu));
 
 	sdg->sgc->capacity = capacity;
 	sdg->sgc->min_capacity = capacity;
kernel/sched/sched.h +0 -19
@@ -1041,7 +1041,6 @@ struct rq {
 
 	unsigned long		cpu_capacity;
 	unsigned long		cpu_capacity_orig;
-	unsigned long		cpu_capacity_inverted;
 
 	struct balance_callback *balance_callback;
 
@@ -2879,24 +2878,6 @@ static inline unsigned long capacity_ori
 	return cpu_rq(cpu)->cpu_capacity_orig;
 }
 
-/*
- * Returns inverted capacity if the CPU is in capacity inversion state.
- * 0 otherwise.
- *
- * Capacity inversion detection only considers thermal impact where actual
- * performance points (OPPs) gets dropped.
- *
- * Capacity inversion state happens when another performance domain that has
- * equal or lower capacity_orig_of() becomes effectively larger than the perf
- * domain this CPU belongs to due to thermal pressure throttling it hard.
- *
- * See comment in update_cpu_capacity().
- */
-static inline unsigned long cpu_in_capacity_inversion(int cpu)
-{
-	return cpu_rq(cpu)->cpu_capacity_inverted;
-}
-
 /**
  * enum cpu_util_type - CPU utilization type
  * @FREQUENCY_UTIL:	Utilization used to select frequency
author maintainer
#170 lore raw

PATCH 170/194 drm/amd/display: Implement workaround for writing to OTG_PIXEL_RATE_DIV register

In reply to Greg Kroah-Hartman

From: Saaem Rizvi <[email protected]>

commit 74fa4c81aadf418341f0d073c864ea7dca730a2e upstream.

[Why and How]
Current implementation requires FPGA builds to take a different code path from DCN32 to write to OTG_PIXEL_RATE_DIV. Now that we have a workaround to write to OTG_PIXEL_RATE_DIV register without blanking display on hotplug on DCN32, we can allow the code paths for FPGA to be exactly the same allowing for more consistent testing.

---
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dccg.h     |    3 +-
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.c     |   22 ++++++++++++++++++
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.h     |    3 +-
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hwseq.c    |    2 -
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.h |    3 +-
 5 files changed, 29 insertions(+), 4 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dccg.h +2 -1
@@ -230,7 +230,8 @@
 	type DTBCLK_P2_SRC_SEL;\
 	type DTBCLK_P2_EN;\
 	type DTBCLK_P3_SRC_SEL;\
-	type DTBCLK_P3_EN;
+	type DTBCLK_P3_EN;\
+	type DENTIST_DISPCLK_CHG_DONE;
 
 struct dccg_shift {
 	DCCG_REG_FIELD_LIST(uint8_t)
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.c +22 -0
@@ -42,6 +42,20 @@
 #define DC_LOGGER \
 	dccg->ctx->logger
 
+/* This function is a workaround for writing to OTG_PIXEL_RATE_DIV
+ * without the probability of causing a DIG FIFO error.
+ */
+static void dccg32_wait_for_dentist_change_done(
+	struct dccg *dccg)
+{
+	struct dcn_dccg *dccg_dcn = TO_DCN_DCCG(dccg);
+
+	uint32_t dentist_dispclk_value = REG_READ(DENTIST_DISPCLK_CNTL);
+
+	REG_WRITE(DENTIST_DISPCLK_CNTL, dentist_dispclk_value);
+	REG_WAIT(DENTIST_DISPCLK_CNTL, DENTIST_DISPCLK_CHG_DONE, 1, 50, 2000);
+}
+
 static void dccg32_get_pixel_rate_div(
 		struct dccg *dccg,
 		uint32_t otg_inst,
@@ -110,21 +124,29 @@ static void dccg32_set_pixel_rate_div(
 		REG_UPDATE_2(OTG_PIXEL_RATE_DIV,
 				OTG0_PIXEL_RATE_DIVK1, k1,
 				OTG0_PIXEL_RATE_DIVK2, k2);
+
+		dccg32_wait_for_dentist_change_done(dccg);
 		break;
 	case 1:
 		REG_UPDATE_2(OTG_PIXEL_RATE_DIV,
 				OTG1_PIXEL_RATE_DIVK1, k1,
 				OTG1_PIXEL_RATE_DIVK2, k2);
+
+		dccg32_wait_for_dentist_change_done(dccg);
 		break;
 	case 2:
 		REG_UPDATE_2(OTG_PIXEL_RATE_DIV,
 				OTG2_PIXEL_RATE_DIVK1, k1,
 				OTG2_PIXEL_RATE_DIVK2, k2);
+
+		dccg32_wait_for_dentist_change_done(dccg);
 		break;
 	case 3:
 		REG_UPDATE_2(OTG_PIXEL_RATE_DIV,
 				OTG3_PIXEL_RATE_DIVK1, k1,
 				OTG3_PIXEL_RATE_DIVK2, k2);
+
+		dccg32_wait_for_dentist_change_done(dccg);
 		break;
 	default:
 		BREAK_TO_DEBUGGER();
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.h +2 -1
@@ -147,7 +147,8 @@
 	DCCG_SF(DTBCLK_P_CNTL, DTBCLK_P3_SRC_SEL, mask_sh),\
 	DCCG_SF(DTBCLK_P_CNTL, DTBCLK_P3_EN, mask_sh),\
 	DCCG_SF(DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO_SEL, mask_sh),\
-	DCCG_SF(DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO0_SOURCE_SEL, mask_sh)
+	DCCG_SF(DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO0_SOURCE_SEL, mask_sh),\
+	DCCG_SF(DENTIST_DISPCLK_CNTL, DENTIST_DISPCLK_CHG_DONE, mask_sh)
 
 
 struct dccg *dccg32_create(
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hwseq.c +1 -1
@@ -1177,7 +1177,7 @@ unsigned int dcn32_calculate_dccg_k1_k2_
 			*k2_div = PIXEL_RATE_DIV_BY_2;
 		else
 			*k2_div = PIXEL_RATE_DIV_BY_4;
-	} else if (dc_is_dp_signal(stream->signal)) {
+	} else if (dc_is_dp_signal(stream->signal) || dc_is_virtual_signal(stream->signal)) {
 		if (two_pix_per_container) {
 			*k1_div = PIXEL_RATE_DIV_BY_1;
 			*k2_div = PIXEL_RATE_DIV_BY_2;
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_resource.h +2 -1
@@ -1272,7 +1272,8 @@ unsigned int dcn32_calc_num_avail_chans_
       DCCG_SRII(PHASE, DTBCLK_DTO, 0), DCCG_SRII(PHASE, DTBCLK_DTO, 1),        \
       DCCG_SRII(PHASE, DTBCLK_DTO, 2), DCCG_SRII(PHASE, DTBCLK_DTO, 3),        \
       SR(DCCG_AUDIO_DTBCLK_DTO_MODULO), SR(DCCG_AUDIO_DTBCLK_DTO_PHASE),       \
-      SR(OTG_PIXEL_RATE_DIV), SR(DTBCLK_P_CNTL), SR(DCCG_AUDIO_DTO_SOURCE)     \
+      SR(OTG_PIXEL_RATE_DIV), SR(DTBCLK_P_CNTL),                               \
+      SR(DCCG_AUDIO_DTO_SOURCE), SR(DENTIST_DISPCLK_CNTL)                      \
   )
 
 /* VMID */
author maintainer
#171 lore raw

PATCH 171/194 hugetlb: do not clear hugetlb dtor until allocating vmemmap

In reply to Greg Kroah-Hartman

From: Mike Kravetz <[email protected]>

commit 32c877191e022b55fe3a374f3d7e9fb5741c514d upstream.

Patch series "Fix hugetlb free path race with memory errors".

In the discussion of Jiaqi Yan's series "Improve hugetlbfs read on HWPOISON hugepages" the race window was discovered.
https://lore.kernel.org/linux-mm/20230616233447.GB7371@monkey/

Freeing a hugetlb page back to low level memory allocators is performed in two steps.
1) Under hugetlb lock, remove page from hugetlb lists and clear destructor
2) Outside lock, allocate vmemmap if necessary and call low level free Between these two steps, the hugetlb page will appear as a normal compound page. However, vmemmap for tail pages could be missing. If a memory error occurs at this time, we could try to update page flags non-existant page structs.

A much more detailed description is in the first patch.

The first patch addresses the race window. However, it adds a hugetlb_lock lock/unlock cycle to every vmemmap optimized hugetlb page free operation. This could lead to slowdowns if one is freeing a large number of hugetlb pages.

The second path optimizes the update_and_free_pages_bulk routine to only take the lock once in bulk operations.

The second patch is technically not a bug fix, but includes a Fixes tag and Cc stable to avoid a performance regression. It can be combined with the first, but was done separately make reviewing easier.

This patch (of 2):

Freeing a hugetlb page and releasing base pages back to the underlying allocator such as buddy or cma is performed in two steps:
- remove_hugetlb_folio() is called to remove the folio from hugetlb lists, get a ref on the page and remove hugetlb destructor. This all must be done under the hugetlb lock. After this call, the page can be treated as a normal compound page or a collection of base size pages.
- update_and_free_hugetlb_folio() is called to allocate vmemmap if needed and the free routine of the underlying allocator is called on the resulting page. We can not hold the hugetlb lock here.

One issue with this scheme is that a memory error could occur between these two steps. In this case, the memory error handling code treats the old hugetlb page as a normal compound page or collection of base pages. It will then try to SetPageHWPoison(page) on the page with an error. If the page with error is a tail page without vmemmap, a write error will occur when trying to set the flag.

Address this issue by modifying remove_hugetlb_folio() and update_and_free_hugetlb_folio() such that the hugetlb destructor is not cleared until after allocating vmemmap. Since clearing the destructor requires holding the hugetlb lock, the clearing is done in remove_hugetlb_folio() if the vmemmap is present. This saves a lock/unlock cycle. Otherwise, destructor is cleared in update_and_free_hugetlb_folio() after allocating vmemmap.

Note that this will leave hugetlb pages in a state where they are marked free (by hugetlb specific page flag) and have a ref count. This is not a normal state. The only code that would notice is the memory error code, and it is set up to retry in such a case.

A subsequent patch will create a routine to do bulk processing of vmemmap allocation. This will eliminate a lock/unlock cycle for each hugetlb page in the case where we are freeing a large number of pages.

---
 mm/hugetlb.c |   75 ++++++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 51 insertions(+), 24 deletions(-)
mm/hugetlb.c +51 -24
@@ -1581,9 +1581,37 @@ static inline void destroy_compound_giga
 						unsigned int order) { }
 #endif
 
+static inline void __clear_hugetlb_destructor(struct hstate *h,
+						struct page *page)
+{
+	lockdep_assert_held(&hugetlb_lock);
+
+	/*
+	 * Very subtle
+	 *
+	 * For non-gigantic pages set the destructor to the normal compound
+	 * page dtor.  This is needed in case someone takes an additional
+	 * temporary ref to the page, and freeing is delayed until they drop
+	 * their reference.
+	 *
+	 * For gigantic pages set the destructor to the null dtor.  This
+	 * destructor will never be called.  Before freeing the gigantic
+	 * page destroy_compound_gigantic_folio will turn the folio into a
+	 * simple group of pages.  After this the destructor does not
+	 * apply.
+	 *
+	 */
+	if (hstate_is_gigantic(h))
+		set_compound_page_dtor(page, NULL_COMPOUND_DTOR);
+	else
+		set_compound_page_dtor(page, COMPOUND_PAGE_DTOR);
+}
+
 /*
- * Remove hugetlb page from lists, and update dtor so that page appears
- * as just a compound page.
+ * Remove hugetlb page from lists.
+ * If vmemmap exists for the page, update dtor so that the page appears
+ * as just a compound page.  Otherwise, wait until after allocating vmemmap
+ * to update dtor.
  *
  * A reference is held on the page, except in the case of demote.
  *
@@ -1614,31 +1642,19 @@ static void __remove_hugetlb_page(struct
 	}
 
 	/*
-	 * Very subtle
-	 *
-	 * For non-gigantic pages set the destructor to the normal compound
-	 * page dtor.  This is needed in case someone takes an additional
-	 * temporary ref to the page, and freeing is delayed until they drop
-	 * their reference.
-	 *
-	 * For gigantic pages set the destructor to the null dtor.  This
-	 * destructor will never be called.  Before freeing the gigantic
-	 * page destroy_compound_gigantic_page will turn the compound page
-	 * into a simple group of pages.  After this the destructor does not
-	 * apply.
-	 *
-	 * This handles the case where more than one ref is held when and
-	 * after update_and_free_page is called.
-	 *
-	 * In the case of demote we do not ref count the page as it will soon
-	 * be turned into a page of smaller size.
+	 * We can only clear the hugetlb destructor after allocating vmemmap
+	 * pages.  Otherwise, someone (memory error handling) may try to write
+	 * to tail struct pages.
+	 */
+	if (!HPageVmemmapOptimized(page))
+		__clear_hugetlb_destructor(h, page);
+
+	 /*
+	  * In the case of demote we do not ref count the page as it will soon
+	  * be turned into a page of smaller size.
 	 */
 	if (!demote)
 		set_page_refcounted(page);
-	if (hstate_is_gigantic(h))
-		set_compound_page_dtor(page, NULL_COMPOUND_DTOR);
-	else
-		set_compound_page_dtor(page, COMPOUND_PAGE_DTOR);
 
 	h->nr_huge_pages--;
 	h->nr_huge_pages_node[nid]--;
@@ -1706,6 +1722,7 @@ static void __update_and_free_page(struc
 {
 	int i;
 	struct page *subpage;
+	bool clear_dtor = HPageVmemmapOptimized(page);
 
 	if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported())
 		return;
@@ -1736,6 +1753,16 @@ static void __update_and_free_page(struc
 	if (unlikely(PageHWPoison(page)))
 		hugetlb_clear_page_hwpoison(page);
 
+	/*
+	 * If vmemmap pages were allocated above, then we need to clear the
+	 * hugetlb destructor under the hugetlb lock.
+	 */
+	if (clear_dtor) {
+		spin_lock_irq(&hugetlb_lock);
+		__clear_hugetlb_destructor(h, page);
+		spin_unlock_irq(&hugetlb_lock);
+	}
+
 	for (i = 0; i < pages_per_huge_page(h); i++) {
 		subpage = nth_page(page, i);
 		subpage->flags &= ~(1 << PG_locked | 1 << PG_error |
author maintainer
#172 lore raw

PATCH 172/194 netfilter: set default timeout to 3 secs for sctp shutdown send and recv state

In reply to Greg Kroah-Hartman

From: Xin Long <[email protected]>

commit 9bfab6d23a2865966a4f89a96536fbf23f83bc8c upstream.

In SCTP protocol, it is using the same timer (T2 timer) for SHUTDOWN and SHUTDOWN_ACK retransmission. However in sctp conntrack the default timeout value for SCTP_CONNTRACK_SHUTDOWN_ACK_SENT state is 3 secs while it's 300 msecs for SCTP_CONNTRACK_SHUTDOWN_SEND/RECV state.

As Paolo Valerio noticed, this might cause unwanted expiration of the ct entry. In my test, with 1s tc netem delay set on the NAT path, after the SHUTDOWN is sent, the sctp ct entry enters SCTP_CONNTRACK_SHUTDOWN_SEND state. However, due to 300ms (too short) delay, when the SHUTDOWN_ACK is sent back from the peer, the sctp ct entry has expired and been deleted, and then the SHUTDOWN_ACK has to be dropped.

Also, it is confusing these two sysctl options always show 0 due to all timeout values using sec as unit:

net.netfilter.nf_conntrack_sctp_timeout_shutdown_recd = 0 net.netfilter.nf_conntrack_sctp_timeout_shutdown_sent = 0

This patch fixes it by also using 3 secs for sctp shutdown send and recv state in sctp conntrack, which is also RTO.initial value in SCTP protocol.

Note that the very short time value for SCTP_CONNTRACK_SHUTDOWN_SEND/RECV was probably used for a rare scenario where SHUTDOWN is sent on 1st path but SHUTDOWN_ACK is replied on 2nd path, then a new connection started immediately on 1st path. So this patch also moves from SHUTDOWN_SEND/RECV to CLOSE when receiving INIT in the ORIGINAL direction.

Fixes 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
---
 net/netfilter/nf_conntrack_proto_sctp.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
net/netfilter/nf_conntrack_proto_sctp.c +3 -3
@@ -49,8 +49,8 @@ static const unsigned int sctp_timeouts[
 	[SCTP_CONNTRACK_COOKIE_WAIT]		= 3 SECS,
 	[SCTP_CONNTRACK_COOKIE_ECHOED]		= 3 SECS,
 	[SCTP_CONNTRACK_ESTABLISHED]		= 210 SECS,
-	[SCTP_CONNTRACK_SHUTDOWN_SENT]		= 300 SECS / 1000,
-	[SCTP_CONNTRACK_SHUTDOWN_RECD]		= 300 SECS / 1000,
+	[SCTP_CONNTRACK_SHUTDOWN_SENT]		= 3 SECS,
+	[SCTP_CONNTRACK_SHUTDOWN_RECD]		= 3 SECS,
 	[SCTP_CONNTRACK_SHUTDOWN_ACK_SENT]	= 3 SECS,
 	[SCTP_CONNTRACK_HEARTBEAT_SENT]		= 30 SECS,
 };
@@ -105,7 +105,7 @@ static const u8 sctp_conntracks[2][11][S
 	{
 /*	ORIGINAL	*/
 /*                  sNO, sCL, sCW, sCE, sES, sSS, sSR, sSA, sHS */
-/* init         */ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA, sCW},
+/* init         */ {sCL, sCL, sCW, sCE, sES, sCL, sCL, sSA, sCW},
 /* init_ack     */ {sCL, sCL, sCW, sCE, sES, sSS, sSR, sSA, sCL},
 /* abort        */ {sCL, sCL, sCL, sCL, sCL, sCL, sCL, sCL, sCL},
 /* shutdown     */ {sCL, sCL, sCW, sCE, sSS, sSS, sSR, sSA, sCL},
author maintainer
#173 lore raw

PATCH 173/194 x86/cpu: Fix __x86_return_thunk symbol type

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit 77f67119004296a9b2503b377d610e08b08afc2a upstream.

Commit

fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")

reimplemented __x86_return_thunk with a mix of SYM_FUNC_START and SYM_CODE_END, this is not a sane combination.

Since nothing should ever actually 'CALL' this, make it consistently CODE.

Fixes fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
---
 arch/x86/lib/retpoline.S |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
arch/x86/lib/retpoline.S +3 -1
@@ -207,7 +207,9 @@ SYM_CODE_END(srso_safe_ret)
 SYM_FUNC_END(srso_untrain_ret)
 __EXPORT_THUNK(srso_untrain_ret)
 
-SYM_FUNC_START(__x86_return_thunk)
+SYM_CODE_START(__x86_return_thunk)
+	UNWIND_HINT_FUNC
+	ANNOTATE_NOENDBR
 	ALTERNATIVE_2 "jmp __ret", "call srso_safe_ret", X86_FEATURE_SRSO, \
 			"call srso_safe_ret_alias", X86_FEATURE_SRSO_ALIAS
 	int3
author maintainer
#174 lore raw

PATCH 174/194 x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit af023ef335f13c8b579298fc432daeef609a9e60 upstream.

vmlinux.o: warning: objtool: srso_untrain_ret() falls through to next function __x86_return_skl() vmlinux.o: warning: objtool: __x86_return_thunk() falls through to next function __x86_return_skl()

This is because these functions (can) end with CALL, which objtool does not consider a terminating instruction. Therefore, replace the INT3 instruction (which is a non-fatal trap) with UD2 (which is a fatal-trap).

This indicates execution will not continue past this point.

Fixes fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
---
 arch/x86/lib/retpoline.S |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/x86/lib/retpoline.S +2 -2
@@ -202,7 +202,7 @@ SYM_INNER_LABEL(srso_safe_ret, SYM_L_GLO
 	int3
 	lfence
 	call srso_safe_ret
-	int3
+	ud2
 SYM_CODE_END(srso_safe_ret)
 SYM_FUNC_END(srso_untrain_ret)
 __EXPORT_THUNK(srso_untrain_ret)
@@ -212,7 +212,7 @@ SYM_CODE_START(__x86_return_thunk)
 	ANNOTATE_NOENDBR
 	ALTERNATIVE_2 "jmp __ret", "call srso_safe_ret", X86_FEATURE_SRSO, \
 			"call srso_safe_ret_alias", X86_FEATURE_SRSO_ALIAS
-	int3
+	ud2
 SYM_CODE_END(__x86_return_thunk)
 EXPORT_SYMBOL(__x86_return_thunk)
 
author maintainer
#175 lore raw

PATCH 175/194 x86/alternative: Make custom return thunk unconditional

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit 095b8303f3835c68ac4a8b6d754ca1c3b6230711 upstream.

There is infrastructure to rewrite return thunks to point to any random thunk one desires, unwrap that from CALL_THUNKS, which up to now was the sole user of that.

[ bp: Make the thunks visible on 32-bit and add ifdeffery for the

    32-bit builds. ]
---
 arch/x86/include/asm/nospec-branch.h |    5 +++++
 arch/x86/kernel/cpu/bugs.c           |    2 ++
 2 files changed, 7 insertions(+)
arch/x86/include/asm/nospec-branch.h +5 -0
@@ -210,7 +210,12 @@
 typedef u8 retpoline_thunk_t[RETPOLINE_THUNK_SIZE];
 extern retpoline_thunk_t __x86_indirect_thunk_array[];
 
+#ifdef CONFIG_RETHUNK
 extern void __x86_return_thunk(void);
+#else
+static inline void __x86_return_thunk(void) {}
+#endif
+
 extern void zen_untrain_ret(void);
 extern void srso_untrain_ret(void);
 extern void srso_untrain_ret_alias(void);
arch/x86/kernel/cpu/bugs.c +2 -0
@@ -62,6 +62,8 @@ EXPORT_SYMBOL_GPL(x86_pred_cmd);
 
 static DEFINE_MUTEX(spec_ctrl_mutex);
 
+void (*x86_return_thunk)(void) __ro_after_init = &__x86_return_thunk;
+
 /* Update SPEC_CTRL MSR and its cached copy unconditionally */
 static void update_spec_ctrl(u64 val)
 {
author maintainer
#176 lore raw

PATCH 176/194 x86/cpu: Clean up SRSO return thunk mess

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit d43490d0ab824023e11d0b57d0aeec17a6e0ca13 upstream.

Use the existing configurable return thunk. There is absolute no justification for having created this __x86_return_thunk alternative.

To clarify, the whole thing looks like:

Zen3/4 does:

srso_alias_untrain_ret:
nop2
lfence
jmp srso_alias_return_thunk
int3

srso_alias_safe_ret: // aliasses srso_alias_untrain_ret just so

	  add $8, %rsp
	  ret
	  int3

srso_alias_return_thunk:

	  call srso_alias_safe_ret
	  ud2

While Zen1/2 does:

srso_untrain_ret:
movabs $foo, %rax
lfence
call srso_safe_ret (jmp srso_return_thunk ?)
int3

srso_safe_ret: // embedded in movabs instruction

	  add $8,%rsp
          ret
          int3

srso_return_thunk:

	  call srso_safe_ret
	  ud2

While retbleed does:

zen_untrain_ret:

	  test $0xcc, %bl
	  lfence
	  jmp zen_return_thunk
          int3

zen_return_thunk: // embedded in the test instruction
ret
int3

Where Zen1/2 flush the BTB entry using the instruction decoder trick (test,movabs) Zen3/4 use BTB aliasing. SRSO adds a return sequence (srso_safe_ret()) which forces the function return instruction to speculate into a trap (UD2). This RET will then mispredict and execution will continue at the return site read from the top of the stack.

Pick one of three options at boot (evey function can only ever return once).

[ bp: Fixup commit message uarch details and add them in a comment in
the code too. Add a comment about the srso_select_mitigation() dependency on retbleed_select_mitigation(). Add moar ifdeffery for 32-bit builds. Add a dummy srso_untrain_ret_alias() definition for 32-bit alternatives needing the symbol. ]

Fixes fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
---
 arch/x86/include/asm/nospec-branch.h |    5 +++
 arch/x86/kernel/cpu/bugs.c           |   17 ++++++++--
 arch/x86/kernel/vmlinux.lds.S        |    4 +-
 arch/x86/lib/retpoline.S             |   58 +++++++++++++++++++++++++----------
 tools/objtool/arch/x86/decode.c      |    2 -
 5 files changed, 64 insertions(+), 22 deletions(-)
arch/x86/include/asm/nospec-branch.h +5 -0
@@ -216,9 +216,14 @@ extern void __x86_return_thunk(void);
 static inline void __x86_return_thunk(void) {}
 #endif
 
+extern void zen_return_thunk(void);
+extern void srso_return_thunk(void);
+extern void srso_alias_return_thunk(void);
+
 extern void zen_untrain_ret(void);
 extern void srso_untrain_ret(void);
 extern void srso_untrain_ret_alias(void);
+
 extern void entry_ibpb(void);
 
 #ifdef CONFIG_RETPOLINE
arch/x86/kernel/cpu/bugs.c +14 -3
@@ -166,8 +166,13 @@ void __init cpu_select_mitigations(void)
 	md_clear_select_mitigation();
 	srbds_select_mitigation();
 	l1d_flush_select_mitigation();
-	gds_select_mitigation();
+
+	/*
+	 * srso_select_mitigation() depends and must run after
+	 * retbleed_select_mitigation().
+	 */
 	srso_select_mitigation();
+	gds_select_mitigation();
 }
 
 /*
@@ -1015,6 +1020,9 @@ do_cmd_auto:
 		setup_force_cpu_cap(X86_FEATURE_RETHUNK);
 		setup_force_cpu_cap(X86_FEATURE_UNRET);
 
+		if (IS_ENABLED(CONFIG_RETHUNK))
+			x86_return_thunk = zen_return_thunk;
+
 		if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
 		    boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
 			pr_err(RETBLEED_UNTRAIN_MSG);
@@ -2422,10 +2430,13 @@ static void __init srso_select_mitigatio
 			 */
 			setup_force_cpu_cap(X86_FEATURE_RETHUNK);
 
-			if (boot_cpu_data.x86 == 0x19)
+			if (boot_cpu_data.x86 == 0x19) {
 				setup_force_cpu_cap(X86_FEATURE_SRSO_ALIAS);
-			else
+				x86_return_thunk = srso_alias_return_thunk;
+			} else {
 				setup_force_cpu_cap(X86_FEATURE_SRSO);
+				x86_return_thunk = srso_return_thunk;
+			}
 			srso_mitigation = SRSO_MITIGATION_SAFE_RET;
 		} else {
 			pr_err("WARNING: kernel not compiled with CPU_SRSO.\n");
arch/x86/kernel/vmlinux.lds.S +2 -2
@@ -507,8 +507,8 @@ INIT_PER_CPU(irq_stack_backing_store);
            "fixed_percpu_data is not at start of per-cpu area");
 #endif
 
- #ifdef CONFIG_RETHUNK
-. = ASSERT((__ret & 0x3f) == 0, "__ret not cacheline-aligned");
+#ifdef CONFIG_RETHUNK
+. = ASSERT((zen_return_thunk & 0x3f) == 0, "zen_return_thunk not cacheline-aligned");
 . = ASSERT((srso_safe_ret & 0x3f) == 0, "srso_safe_ret not cacheline-aligned");
 #endif
 
arch/x86/lib/retpoline.S +42 -16

140 lines not on this page · raw message

tools/objtool/arch/x86/decode.c +1 -1
@@ -799,5 +799,5 @@ bool arch_is_rethunk(struct symbol *sym)
 	return !strcmp(sym->name, "__x86_return_thunk") ||
 	       !strcmp(sym->name, "srso_untrain_ret") ||
 	       !strcmp(sym->name, "srso_safe_ret") ||
-	       !strcmp(sym->name, "__ret");
+	       !strcmp(sym->name, "zen_return_thunk");
 }
author maintainer
#177 lore raw

PATCH 177/194 x86/cpu: Rename original retbleed methods

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit d025b7bac07a6e90b6b98b487f88854ad9247c39 upstream.

Rename the original retbleed return thunk and untrain_ret to retbleed_return_thunk() and retbleed_untrain_ret().

No functional changes.

---
 arch/x86/include/asm/nospec-branch.h |    8 ++++----
 arch/x86/kernel/cpu/bugs.c           |    2 +-
 arch/x86/kernel/vmlinux.lds.S        |    2 +-
 arch/x86/lib/retpoline.S             |   30 +++++++++++++++---------------
 tools/objtool/arch/x86/decode.c      |    2 +-
 tools/objtool/check.c                |    2 +-
 6 files changed, 23 insertions(+), 23 deletions(-)
arch/x86/include/asm/nospec-branch.h +4 -4
@@ -168,7 +168,7 @@
 .endm
 
 #ifdef CONFIG_CPU_UNRET_ENTRY
-#define CALL_ZEN_UNTRAIN_RET	"call zen_untrain_ret"
+#define CALL_ZEN_UNTRAIN_RET	"call retbleed_untrain_ret"
 #else
 #define CALL_ZEN_UNTRAIN_RET	""
 #endif
@@ -178,7 +178,7 @@
  * return thunk isn't mapped into the userspace tables (then again, AMD
  * typically has NO_MELTDOWN).
  *
- * While zen_untrain_ret() doesn't clobber anything but requires stack,
+ * While retbleed_untrain_ret() doesn't clobber anything but requires stack,
  * entry_ibpb() will clobber AX, CX, DX.
  *
  * As such, this must be placed after every *SWITCH_TO_KERNEL_CR3 at a point
@@ -216,11 +216,11 @@ extern void __x86_return_thunk(void);
 static inline void __x86_return_thunk(void) {}
 #endif
 
-extern void zen_return_thunk(void);
+extern void retbleed_return_thunk(void);
 extern void srso_return_thunk(void);
 extern void srso_alias_return_thunk(void);
 
-extern void zen_untrain_ret(void);
+extern void retbleed_untrain_ret(void);
 extern void srso_untrain_ret(void);
 extern void srso_untrain_ret_alias(void);
 
arch/x86/kernel/cpu/bugs.c +1 -1
@@ -1021,7 +1021,7 @@ do_cmd_auto:
 		setup_force_cpu_cap(X86_FEATURE_UNRET);
 
 		if (IS_ENABLED(CONFIG_RETHUNK))
-			x86_return_thunk = zen_return_thunk;
+			x86_return_thunk = retbleed_return_thunk;
 
 		if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
 		    boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
arch/x86/kernel/vmlinux.lds.S +1 -1
@@ -508,7 +508,7 @@ INIT_PER_CPU(irq_stack_backing_store);
 #endif
 
 #ifdef CONFIG_RETHUNK
-. = ASSERT((zen_return_thunk & 0x3f) == 0, "zen_return_thunk not cacheline-aligned");
+. = ASSERT((retbleed_return_thunk & 0x3f) == 0, "retbleed_return_thunk not cacheline-aligned");
 . = ASSERT((srso_safe_ret & 0x3f) == 0, "srso_safe_ret not cacheline-aligned");
 #endif
 
arch/x86/lib/retpoline.S +15 -15
@@ -131,32 +131,32 @@ SYM_CODE_END(srso_alias_return_thunk)
 
 /*
  * Safety details here pertain to the AMD Zen{1,2} microarchitecture:
- * 1) The RET at zen_return_thunk must be on a 64 byte boundary, for
+ * 1) The RET at retbleed_return_thunk must be on a 64 byte boundary, for
  *    alignment within the BTB.
- * 2) The instruction at zen_untrain_ret must contain, and not
+ * 2) The instruction at retbleed_untrain_ret must contain, and not
  *    end with, the 0xc3 byte of the RET.
  * 3) STIBP must be enabled, or SMT disabled, to prevent the sibling thread
  *    from re-poisioning the BTB prediction.
  */
 	.align 64
-	.skip 64 - (zen_return_thunk - zen_untrain_ret), 0xcc
-SYM_START(zen_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
+	.skip 64 - (retbleed_return_thunk - retbleed_untrain_ret), 0xcc
+SYM_START(retbleed_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
 	ANNOTATE_NOENDBR
 	/*
-	 * As executed from zen_untrain_ret, this is:
+	 * As executed from retbleed_untrain_ret, this is:
 	 *
 	 *   TEST $0xcc, %bl
 	 *   LFENCE
-	 *   JMP zen_return_thunk
+	 *   JMP retbleed_return_thunk
 	 *
 	 * Executing the TEST instruction has a side effect of evicting any BTB
 	 * prediction (potentially attacker controlled) attached to the RET, as
-	 * zen_return_thunk + 1 isn't an instruction boundary at the moment.
+	 * retbleed_return_thunk + 1 isn't an instruction boundary at the moment.
 	 */
 	.byte	0xf6
 
 	/*
-	 * As executed from zen_return_thunk, this is a plain RET.
+	 * As executed from retbleed_return_thunk, this is a plain RET.
 	 *
 	 * As part of the TEST above, RET is the ModRM byte, and INT3 the imm8.
 	 *
@@ -168,13 +168,13 @@ SYM_START(zen_untrain_ret, SYM_L_GLOBAL,
 	 * With SMT enabled and STIBP active, a sibling thread cannot poison
 	 * RET's prediction to a type of its choice, but can evict the
 	 * prediction due to competitive sharing. If the prediction is
-	 * evicted, zen_return_thunk will suffer Straight Line Speculation
+	 * evicted, retbleed_return_thunk will suffer Straight Line Speculation
 	 * which will be contained safely by the INT3.
 	 */
-SYM_INNER_LABEL(zen_return_thunk, SYM_L_GLOBAL)
+SYM_INNER_LABEL(retbleed_return_thunk, SYM_L_GLOBAL)
 	ret
 	int3
-SYM_CODE_END(zen_return_thunk)
+SYM_CODE_END(retbleed_return_thunk)
 
 	/*
 	 * Ensure the TEST decoding / BTB invalidation is complete.
@@ -185,13 +185,13 @@ SYM_CODE_END(zen_return_thunk)
 	 * Jump back and execute the RET in the middle of the TEST instruction.
 	 * INT3 is for SLS protection.
 	 */
-	jmp zen_return_thunk
+	jmp retbleed_return_thunk
 	int3
-SYM_FUNC_END(zen_untrain_ret)
-__EXPORT_THUNK(zen_untrain_ret)
+SYM_FUNC_END(retbleed_untrain_ret)
+__EXPORT_THUNK(retbleed_untrain_ret)
 
 /*
- * SRSO untraining sequence for Zen1/2, similar to zen_untrain_ret()
+ * SRSO untraining sequence for Zen1/2, similar to retbleed_untrain_ret()
  * above. On kernel entry, srso_untrain_ret() is executed which is a
  *
  * movabs $0xccccccc308c48348,%rax
tools/objtool/arch/x86/decode.c +1 -1
@@ -799,5 +799,5 @@ bool arch_is_rethunk(struct symbol *sym)
 	return !strcmp(sym->name, "__x86_return_thunk") ||
 	       !strcmp(sym->name, "srso_untrain_ret") ||
 	       !strcmp(sym->name, "srso_safe_ret") ||
-	       !strcmp(sym->name, "zen_return_thunk");
+	       !strcmp(sym->name, "retbleed_return_thunk");
 }
tools/objtool/check.c +1 -1
@@ -1430,7 +1430,7 @@ static int add_jump_destinations(struct
 			struct symbol *sym = find_symbol_by_offset(dest_sec, dest_off);
 
 			/*
-			 * This is a special case for zen_untrain_ret().
+			 * This is a special case for retbleed_untrain_ret().
 			 * It jumps to __x86_return_thunk(), but objtool
 			 * can't find the thunk's starting RET
 			 * instruction, because the RET is also in the
author maintainer
#178 lore raw

PATCH 178/194 x86/cpu: Rename srso_(.*)_alias to srso_alias_\1

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit 42be649dd1f2eee6b1fb185f1a231b9494cf095f upstream.

For a more consistent namespace.

[ bp: Fixup names in the doc too. ]

---
 Documentation/admin-guide/hw-vuln/srso.rst |    4 ++--
 arch/x86/include/asm/nospec-branch.h       |    4 ++--
 arch/x86/kernel/vmlinux.lds.S              |    8 ++++----
 arch/x86/lib/retpoline.S                   |   26 +++++++++++++-------------
 4 files changed, 21 insertions(+), 21 deletions(-)
Documentation/admin-guide/hw-vuln/srso.rst +2 -2
@@ -124,8 +124,8 @@ sequence.
 To ensure the safety of this mitigation, the kernel must ensure that the
 safe return sequence is itself free from attacker interference.  In Zen3
 and Zen4, this is accomplished by creating a BTB alias between the
-untraining function srso_untrain_ret_alias() and the safe return
-function srso_safe_ret_alias() which results in evicting a potentially
+untraining function srso_alias_untrain_ret() and the safe return
+function srso_alias_safe_ret() which results in evicting a potentially
 poisoned BTB entry and using that safe one for all function returns.
 
 In older Zen1 and Zen2, this is accomplished using a reinterpretation
arch/x86/include/asm/nospec-branch.h +2 -2
@@ -195,7 +195,7 @@
 
 #ifdef CONFIG_CPU_SRSO
 	ALTERNATIVE_2 "", "call srso_untrain_ret", X86_FEATURE_SRSO, \
-			  "call srso_untrain_ret_alias", X86_FEATURE_SRSO_ALIAS
+			  "call srso_alias_untrain_ret", X86_FEATURE_SRSO_ALIAS
 #endif
 .endm
 
@@ -222,7 +222,7 @@ extern void srso_alias_return_thunk(void
 
 extern void retbleed_untrain_ret(void);
 extern void srso_untrain_ret(void);
-extern void srso_untrain_ret_alias(void);
+extern void srso_alias_untrain_ret(void);
 
 extern void entry_ibpb(void);
 
arch/x86/kernel/vmlinux.lds.S +4 -4
@@ -141,10 +141,10 @@ SECTIONS
 
 #ifdef CONFIG_CPU_SRSO
 		/*
-		 * See the comment above srso_untrain_ret_alias()'s
+		 * See the comment above srso_alias_untrain_ret()'s
 		 * definition.
 		 */
-		. = srso_untrain_ret_alias | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20);
+		. = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20);
 		*(.text.__x86.rethunk_safe)
 #endif
 		ALIGN_ENTRY_TEXT_END
@@ -523,8 +523,8 @@ INIT_PER_CPU(irq_stack_backing_store);
  * Instead do: (A | B) - (A & B) in order to compute the XOR
  * of the two function addresses:
  */
-. = ASSERT(((ABSOLUTE(srso_untrain_ret_alias) | srso_safe_ret_alias) -
-		(ABSOLUTE(srso_untrain_ret_alias) & srso_safe_ret_alias)) == ((1 << 2) | (1 << 8) | (1 << 14) | (1 << 20)),
+. = ASSERT(((ABSOLUTE(srso_alias_untrain_ret) | srso_alias_safe_ret) -
+		(ABSOLUTE(srso_alias_untrain_ret) & srso_alias_safe_ret)) == ((1 << 2) | (1 << 8) | (1 << 14) | (1 << 20)),
 		"SRSO function pair won't alias");
 #endif
 
arch/x86/lib/retpoline.S +13 -13
@@ -76,56 +76,56 @@ SYM_CODE_END(__x86_indirect_thunk_array)
 #ifdef CONFIG_RETHUNK
 
 /*
- * srso_untrain_ret_alias() and srso_safe_ret_alias() are placed at
+ * srso_alias_untrain_ret() and srso_alias_safe_ret() are placed at
  * special addresses:
  *
- * - srso_untrain_ret_alias() is 2M aligned
- * - srso_safe_ret_alias() is also in the same 2M page but bits 2, 8, 14
+ * - srso_alias_untrain_ret() is 2M aligned
+ * - srso_alias_safe_ret() is also in the same 2M page but bits 2, 8, 14
  * and 20 in its virtual address are set (while those bits in the
- * srso_untrain_ret_alias() function are cleared).
+ * srso_alias_untrain_ret() function are cleared).
  *
  * This guarantees that those two addresses will alias in the branch
  * target buffer of Zen3/4 generations, leading to any potential
  * poisoned entries at that BTB slot to get evicted.
  *
- * As a result, srso_safe_ret_alias() becomes a safe return.
+ * As a result, srso_alias_safe_ret() becomes a safe return.
  */
 #ifdef CONFIG_CPU_SRSO
 	.section .text.__x86.rethunk_untrain
 
-SYM_START(srso_untrain_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
+SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
 	UNWIND_HINT_FUNC
 	ANNOTATE_NOENDBR
 	ASM_NOP2
 	lfence
 	jmp srso_alias_return_thunk
-SYM_FUNC_END(srso_untrain_ret_alias)
-__EXPORT_THUNK(srso_untrain_ret_alias)
+SYM_FUNC_END(srso_alias_untrain_ret)
+__EXPORT_THUNK(srso_alias_untrain_ret)
 
 	.section .text.__x86.rethunk_safe
 #else
 /* dummy definition for alternatives */
-SYM_START(srso_untrain_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
+SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
 	ANNOTATE_UNRET_SAFE
 	ret
 	int3
-SYM_FUNC_END(srso_untrain_ret_alias)
+SYM_FUNC_END(srso_alias_untrain_ret)
 #endif
 
-SYM_START(srso_safe_ret_alias, SYM_L_GLOBAL, SYM_A_NONE)
+SYM_START(srso_alias_safe_ret, SYM_L_GLOBAL, SYM_A_NONE)
 	add $8, %_ASM_SP
 	UNWIND_HINT_FUNC
 	ANNOTATE_UNRET_SAFE
 	ret
 	int3
-SYM_FUNC_END(srso_safe_ret_alias)
+SYM_FUNC_END(srso_alias_safe_ret)
 
 	.section .text.__x86.return_thunk
 
 SYM_CODE_START(srso_alias_return_thunk)
 	UNWIND_HINT_FUNC
 	ANNOTATE_NOENDBR
-	call srso_safe_ret_alias
+	call srso_alias_safe_ret
 	ud2
 SYM_CODE_END(srso_alias_return_thunk)
 
author maintainer
#179 lore raw

PATCH 179/194 x86/cpu: Cleanup the untrain mess

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit e7c25c441e9e0fa75b4c83e0b26306b702cfe90d upstream.

Since there can only be one active return_thunk, there only needs be one (matching) untrain_ret. It fundamentally doesn't make sense to allow multiple untrain_ret at the same time.

Fold all the 3 different untrain methods into a single (temporary) helper stub.

Fixes fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
---
 arch/x86/include/asm/nospec-branch.h |   12 ++++--------
 arch/x86/kernel/cpu/bugs.c           |    1 +
 arch/x86/lib/retpoline.S             |    7 +++++++
 3 files changed, 12 insertions(+), 8 deletions(-)
arch/x86/include/asm/nospec-branch.h +4 -8
@@ -168,9 +168,9 @@
 .endm
 
 #ifdef CONFIG_CPU_UNRET_ENTRY
-#define CALL_ZEN_UNTRAIN_RET	"call retbleed_untrain_ret"
+#define CALL_UNTRAIN_RET	"call entry_untrain_ret"
 #else
-#define CALL_ZEN_UNTRAIN_RET	""
+#define CALL_UNTRAIN_RET	""
 #endif
 
 /*
@@ -189,14 +189,9 @@
 	defined(CONFIG_CPU_SRSO)
 	ANNOTATE_UNRET_END
 	ALTERNATIVE_2 "",						\
-	              CALL_ZEN_UNTRAIN_RET, X86_FEATURE_UNRET,		\
+		      CALL_UNTRAIN_RET, X86_FEATURE_UNRET,		\
 		      "call entry_ibpb", X86_FEATURE_ENTRY_IBPB
 #endif
-
-#ifdef CONFIG_CPU_SRSO
-	ALTERNATIVE_2 "", "call srso_untrain_ret", X86_FEATURE_SRSO, \
-			  "call srso_alias_untrain_ret", X86_FEATURE_SRSO_ALIAS
-#endif
 .endm
 
 #else /* __ASSEMBLY__ */
@@ -224,6 +219,7 @@ extern void retbleed_untrain_ret(void);
 extern void srso_untrain_ret(void);
 extern void srso_alias_untrain_ret(void);
 
+extern void entry_untrain_ret(void);
 extern void entry_ibpb(void);
 
 #ifdef CONFIG_RETPOLINE
arch/x86/kernel/cpu/bugs.c +1 -0
@@ -2429,6 +2429,7 @@ static void __init srso_select_mitigatio
 			 * like ftrace, static_call, etc.
 			 */
 			setup_force_cpu_cap(X86_FEATURE_RETHUNK);
+			setup_force_cpu_cap(X86_FEATURE_UNRET);
 
 			if (boot_cpu_data.x86 == 0x19) {
 				setup_force_cpu_cap(X86_FEATURE_SRSO_ALIAS);
arch/x86/lib/retpoline.S +7 -0
@@ -233,6 +233,13 @@ SYM_CODE_START(srso_return_thunk)
 	ud2
 SYM_CODE_END(srso_return_thunk)
 
+SYM_FUNC_START(entry_untrain_ret)
+	ALTERNATIVE_2 "jmp retbleed_untrain_ret", \
+		      "jmp srso_untrain_ret", X86_FEATURE_SRSO, \
+		      "jmp srso_alias_untrain_ret", X86_FEATURE_SRSO_ALIAS
+SYM_FUNC_END(entry_untrain_ret)
+__EXPORT_THUNK(entry_untrain_ret)
+
 SYM_CODE_START(__x86_return_thunk)
 	UNWIND_HINT_FUNC
 	ANNOTATE_NOENDBR
author maintainer
#180 lore raw

PATCH 180/194 x86/srso: Explain the untraining sequences a bit more

In reply to Greg Kroah-Hartman

From: Borislav Petkov (AMD) <[email protected]>

commit 9dbd23e42ff0b10c9b02c9e649c76e5228241a8e upstream.

The goal is to eventually have a proper documentation about all this.

---
 arch/x86/lib/retpoline.S |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
arch/x86/lib/retpoline.S +19 -0
@@ -130,6 +130,25 @@ SYM_CODE_START(srso_alias_return_thunk)
 SYM_CODE_END(srso_alias_return_thunk)
 
 /*
+ * Some generic notes on the untraining sequences:
+ *
+ * They are interchangeable when it comes to flushing potentially wrong
+ * RET predictions from the BTB.
+ *
+ * The SRSO Zen1/2 (MOVABS) untraining sequence is longer than the
+ * Retbleed sequence because the return sequence done there
+ * (srso_safe_ret()) is longer and the return sequence must fully nest
+ * (end before) the untraining sequence. Therefore, the untraining
+ * sequence must fully overlap the return sequence.
+ *
+ * Regarding alignment - the instructions which need to be untrained,
+ * must all start at a cacheline boundary for Zen1/2 generations. That
+ * is, instruction sequences starting at srso_safe_ret() and
+ * the respective instruction sequences at retbleed_return_thunk()
+ * must start at a cacheline boundary.
+ */
+
+/*
  * Safety details here pertain to the AMD Zen{1,2} microarchitecture:
  * 1) The RET at retbleed_return_thunk must be on a 64 byte boundary, for
  *    alignment within the BTB.
author maintainer
#181 lore raw

PATCH 181/194 x86/static_call: Fix __static_call_fixup()

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit 54097309620ef0dc2d7083783dc521c6a5fef957 upstream.

Christian reported spurious module load crashes after some of Song's module memory layout patches.

Turns out that if the very last instruction on the very last page of the module is a 'JMP __x86_return_thunk' then __static_call_fixup() will trip a fault and die.

And while the module rework made this slightly more likely to happen, it's always been possible.

---
 arch/x86/kernel/static_call.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)
arch/x86/kernel/static_call.c +13 -0
@@ -184,6 +184,19 @@ EXPORT_SYMBOL_GPL(arch_static_call_trans
  */
 bool __static_call_fixup(void *tramp, u8 op, void *dest)
 {
+	unsigned long addr = (unsigned long)tramp;
+	/*
+	 * Not all .return_sites are a static_call trampoline (most are not).
+	 * Check if the 3 bytes after the return are still kernel text, if not,
+	 * then this definitely is not a trampoline and we need not worry
+	 * further.
+	 *
+	 * This avoids the memcmp() below tripping over pagefaults etc..
+	 */
+	if (((addr >> PAGE_SHIFT) != ((addr + 7) >> PAGE_SHIFT)) &&
+	    !kernel_text_address(addr + 7))
+		return false;
+
 	if (memcmp(tramp+5, tramp_ud, 3)) {
 		/* Not a trampoline site, not our problem. */
 		return false;
author maintainer
#182 lore raw

PATCH 182/194 x86/retpoline: Dont clobber RFLAGS during srso_safe_ret()

In reply to Greg Kroah-Hartman

From: Sean Christopherson <[email protected]>

commit ba5ca5e5e6a1d55923e88b4a83da452166f5560e upstream.

Use LEA instead of ADD when adjusting %rsp in srso_safe_ret{,_alias}() so as to avoid clobbering flags. Drop one of the INT3 instructions to account for the LEA consuming one more byte than the ADD.

KVM's emulator makes indirect calls into a jump table of sorts, where the destination of each call is a small blob of code that performs fast emulation by executing the target instruction with fixed operands.

E.g. to emulate ADC, fastop() invokes adcb_al_dl():

adcb_al_dl:

    <+0>:  adc    %dl,%al
    <+2>:  jmp    <__x86_return_thunk>

A major motivation for doing fast emulation is to leverage the CPU to handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is both an input and output to the target of the call. fastop() collects the RFLAGS result by pushing RFLAGS onto the stack and popping them back into a variable (held in %rdi in this case):

asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"

  <+71>: mov    0xc0(%r8),%rdx
  <+78>: mov    0x100(%r8),%rcx
  <+85>: push   %rdi

<+86>: popf
<+87>: call *%rsi
<+89>: nop
<+90>: nop
<+91>: nop
<+92>: pushf
<+93>: pop %rdi

and then propagating the arithmetic flags into the vCPU's emulator state:

  ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
  <+64>:  and    $0xfffffffffffff72a,%r9
  <+94>:  and    $0x8d5,%edi
  <+109>: or     %rdi,%r9
  <+122>: mov    %r9,0x10(%r8)

The failures can be most easily reproduced by running the "emulator" test in KVM-Unit-Tests.

If you're feeling a bit of deja vu, see commit b63f20a778c8 ("x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386").

In addition, this breaks booting of clang-compiled guest on a gcc-compiled host where the host contains the %rsp-modifying SRSO mitigations.

[ bp: Massage commit message, extend, remove addresses. ]

---
 arch/x86/lib/retpoline.S |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
arch/x86/lib/retpoline.S +3 -4
@@ -113,7 +113,7 @@ SYM_FUNC_END(srso_alias_untrain_ret)
 #endif
 
 SYM_START(srso_alias_safe_ret, SYM_L_GLOBAL, SYM_A_NONE)
-	add $8, %_ASM_SP
+	lea 8(%_ASM_SP), %_ASM_SP
 	UNWIND_HINT_FUNC
 	ANNOTATE_UNRET_SAFE
 	ret
@@ -213,7 +213,7 @@ __EXPORT_THUNK(retbleed_untrain_ret)
  * SRSO untraining sequence for Zen1/2, similar to retbleed_untrain_ret()
  * above. On kernel entry, srso_untrain_ret() is executed which is a
  *
- * movabs $0xccccccc308c48348,%rax
+ * movabs $0xccccc30824648d48,%rax
  *
  * and when the return thunk executes the inner label srso_safe_ret()
  * later, it is a stack manipulation and a RET which is mispredicted and
@@ -232,11 +232,10 @@ SYM_START(srso_untrain_ret, SYM_L_GLOBAL
  * the stack.
  */
 SYM_INNER_LABEL(srso_safe_ret, SYM_L_GLOBAL)
-	add $8, %_ASM_SP
+	lea 8(%_ASM_SP), %_ASM_SP
 	ret
 	int3
 	int3
-	int3
 	/* end of movabs */
 	lfence
 	call srso_safe_ret
author maintainer
#183 lore raw

PATCH 183/194 x86/CPU/AMD: Fix the DIV(0) initial fix attempt

In reply to Greg Kroah-Hartman

From: Borislav Petkov (AMD) <[email protected]>

commit f58d6fbcb7c848b7f2469be339bc571f2e9d245b upstream.

Initially, it was thought that doing an innocuous division in the #DE handler would take care to prevent any leaking of old data from the divider but by the time the fault is raised, the speculation has already advanced too far and such data could already have been used by younger operations.

Therefore, do the innocuous division on every exit to userspace so that userspace doesn't see any potentially old data from integer divisions in kernel space.

Do the same before VMRUN too, to protect host data from leaking into the guest too.

Fixes 77245f1c3c64 ("x86/CPU/AMD: Do not leak quotient data after a division by 0")
---
 arch/x86/include/asm/entry-common.h |    1 +
 arch/x86/kernel/cpu/amd.c           |    1 +
 arch/x86/kernel/traps.c             |    2 --
 arch/x86/kvm/svm/svm.c              |    2 ++
 4 files changed, 4 insertions(+), 2 deletions(-)
arch/x86/include/asm/entry-common.h +1 -0
@@ -92,6 +92,7 @@ static inline void arch_exit_to_user_mod
 static __always_inline void arch_exit_to_user_mode(void)
 {
 	mds_user_clear_cpu_buffers();
+	amd_clear_divider();
 }
 #define arch_exit_to_user_mode arch_exit_to_user_mode
 
arch/x86/kernel/cpu/amd.c +1 -0
@@ -1295,3 +1295,4 @@ void noinstr amd_clear_divider(void)
 	asm volatile(ALTERNATIVE("", "div %2\n\t", X86_BUG_DIV0)
 		     :: "a" (0), "d" (0), "r" (1));
 }
+EXPORT_SYMBOL_GPL(amd_clear_divider);
arch/x86/kernel/traps.c +0 -2
@@ -206,8 +206,6 @@ DEFINE_IDTENTRY(exc_divide_error)
 {
 	do_error_trap(regs, 0, "divide error", X86_TRAP_DE, SIGFPE,
 		      FPE_INTDIV, error_get_trap_addr(regs));
-
-	amd_clear_divider();
 }
 
 DEFINE_IDTENTRY(exc_overflow)
arch/x86/kvm/svm/svm.c +2 -0
@@ -3947,6 +3947,8 @@ static noinstr void svm_vcpu_enter_exit(
 
 	guest_state_enter_irqoff();
 
+	amd_clear_divider();
+
 	if (sev_es_guest(vcpu->kvm))
 		__svm_sev_es_vcpu_run(svm, spec_ctrl_intercepted);
 	else
author maintainer
#184 lore raw

PATCH 184/194 x86/srso: Disable the mitigation on unaffected configurations

In reply to Greg Kroah-Hartman

From: Borislav Petkov (AMD) <[email protected]>

commit e9fbc47b818b964ddff5df5b2d5c0f5f32f4a147 upstream.

Skip the srso cmd line parsing which is not needed on Zen1/2 with SMT disabled and with the proper microcode applied (latter should be the case anyway) as those are not affected.

Fixes 5a15d8348881 ("x86/srso: Tie SBPB bit setting to microcode patch detection")
---
 arch/x86/kernel/cpu/bugs.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
arch/x86/kernel/cpu/bugs.c +6 -1
@@ -2399,8 +2399,10 @@ static void __init srso_select_mitigatio
 		 * IBPB microcode has been applied.
 		 */
 		if ((boot_cpu_data.x86 < 0x19) &&
-		    (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED)))
+		    (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) {
 			setup_force_cpu_cap(X86_FEATURE_SRSO_NO);
+			return;
+		}
 	}
 
 	if (retbleed_mitigation == RETBLEED_MITIGATION_IBPB) {
@@ -2686,6 +2688,9 @@ static ssize_t gds_show_state(char *buf)
 
 static ssize_t srso_show_state(char *buf)
 {
+	if (boot_cpu_has(X86_FEATURE_SRSO_NO))
+		return sysfs_emit(buf, "Not affected\n");
+
 	return sysfs_emit(buf, "%s%s\n",
 			  srso_strings[srso_mitigation],
 			  (cpu_has_ibpb_brtype_microcode() ? "" : ", no microcode"));
author maintainer
#185 lore raw

PATCH 185/194 x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG

In reply to Greg Kroah-Hartman

From: Petr Pavlu <[email protected]>

commit 79cd2a11224eab86d6673fe8a11d2046ae9d2757 upstream.

The linker script arch/x86/kernel/vmlinux.lds.S matches the thunk sections ".text.__x86.*" from arch/x86/lib/retpoline.S as follows:

  .text {
    [...]
    TEXT_TEXT
    [...]
    __indirect_thunk_start = .;
    *(.text.__x86.*)
    __indirect_thunk_end = .;
    [...]
  }

Macro TEXT_TEXT references TEXT_MAIN which normally expands to only ".text". However, with CONFIG_LTO_CLANG, TEXT_MAIN becomes ".text .text.[0-9a-zA-Z_]*" which wrongly matches also the thunk sections. The output layout is then different than expected. For instance, the currently defined range [__indirect_thunk_start, __indirect_thunk_end] becomes empty.

Prevent the problem by using ".." as the first separator, for example, ".text..__x86.indirect_thunk". This pattern is utilized by other explicit section names which start with one of the standard prefixes, such as ".text" or ".data", and that need to be individually selected in the linker script.

[ nathan: Fix conflicts with SRSO and fold in fix issue brought up by
Andrew Cooper in post-review:
https://lore.kernel.org/[email protected] ]

---
 arch/x86/kernel/vmlinux.lds.S |    8 ++++----
 arch/x86/lib/retpoline.S      |    8 ++++----
 tools/objtool/check.c         |    2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)
arch/x86/kernel/vmlinux.lds.S +4 -4
@@ -134,7 +134,7 @@ SECTIONS
 		KPROBES_TEXT
 		ALIGN_ENTRY_TEXT_BEGIN
 #ifdef CONFIG_CPU_SRSO
-		*(.text.__x86.rethunk_untrain)
+		*(.text..__x86.rethunk_untrain)
 #endif
 
 		ENTRY_TEXT
@@ -145,7 +145,7 @@ SECTIONS
 		 * definition.
 		 */
 		. = srso_alias_untrain_ret | (1 << 2) | (1 << 8) | (1 << 14) | (1 << 20);
-		*(.text.__x86.rethunk_safe)
+		*(.text..__x86.rethunk_safe)
 #endif
 		ALIGN_ENTRY_TEXT_END
 		SOFTIRQENTRY_TEXT
@@ -154,8 +154,8 @@ SECTIONS
 
 #ifdef CONFIG_RETPOLINE
 		__indirect_thunk_start = .;
-		*(.text.__x86.indirect_thunk)
-		*(.text.__x86.return_thunk)
+		*(.text..__x86.indirect_thunk)
+		*(.text..__x86.return_thunk)
 		__indirect_thunk_end = .;
 #endif
 	} :text =0xcccc
arch/x86/lib/retpoline.S +4 -4
@@ -11,7 +11,7 @@
 #include <asm/frame.h>
 #include <asm/nops.h>
 
-	.section .text.__x86.indirect_thunk
+	.section .text..__x86.indirect_thunk
 
 .macro RETPOLINE reg
 	ANNOTATE_INTRA_FUNCTION_CALL
@@ -91,7 +91,7 @@ SYM_CODE_END(__x86_indirect_thunk_array)
  * As a result, srso_alias_safe_ret() becomes a safe return.
  */
 #ifdef CONFIG_CPU_SRSO
-	.section .text.__x86.rethunk_untrain
+	.section .text..__x86.rethunk_untrain
 
 SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
 	UNWIND_HINT_FUNC
@@ -102,7 +102,7 @@ SYM_START(srso_alias_untrain_ret, SYM_L_
 SYM_FUNC_END(srso_alias_untrain_ret)
 __EXPORT_THUNK(srso_alias_untrain_ret)
 
-	.section .text.__x86.rethunk_safe
+	.section .text..__x86.rethunk_safe
 #else
 /* dummy definition for alternatives */
 SYM_START(srso_alias_untrain_ret, SYM_L_GLOBAL, SYM_A_NONE)
@@ -120,7 +120,7 @@ SYM_START(srso_alias_safe_ret, SYM_L_GLO
 	int3
 SYM_FUNC_END(srso_alias_safe_ret)
 
-	.section .text.__x86.return_thunk
+	.section .text..__x86.return_thunk
 
 SYM_CODE_START(srso_alias_return_thunk)
 	UNWIND_HINT_FUNC
tools/objtool/check.c +1 -1
@@ -379,7 +379,7 @@ static int decode_instructions(struct ob
 
 		if (!strcmp(sec->name, ".noinstr.text") ||
 		    !strcmp(sec->name, ".entry.text") ||
-		    !strncmp(sec->name, ".text.__x86.", 12))
+		    !strncmp(sec->name, ".text..__x86.", 13))
 			sec->noinstr = true;
 
 		for (offset = 0; offset < sec->sh.sh_size; offset += insn->len) {
author maintainer
#186 lore raw

PATCH 186/194 objtool/x86: Fixup frame-pointer vs rethunk

In reply to Greg Kroah-Hartman

From: Peter Zijlstra <[email protected]>

commit dbf46008775516f7f25c95b7760041c286299783 upstream.

For stack-validation of a frame-pointer build, objtool validates that every CALL instruction is preceded by a frame-setup. The new SRSO return thunks violate this with their RSB stuffing trickery.

Extend the __fentry__ exception to also cover the embedded_insn case used for this. This cures:

vmlinux.o: warning: objtool: srso_untrain_ret+0xd: call without frame pointer save/setup

---
 tools/objtool/check.c |   17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)
tools/objtool/check.c +11 -6
@@ -2450,12 +2450,17 @@ static int decode_sections(struct objtoo
 	return 0;
 }
 
-static bool is_fentry_call(struct instruction *insn)
+static bool is_special_call(struct instruction *insn)
 {
-	if (insn->type == INSN_CALL &&
-	    insn->call_dest &&
-	    insn->call_dest->fentry)
-		return true;
+	if (insn->type == INSN_CALL) {
+		struct symbol *dest = insn->call_dest;
+
+		if (!dest)
+			return false;
+
+		if (dest->fentry)
+			return true;
+	}
 
 	return false;
 }
@@ -3448,7 +3453,7 @@ static int validate_branch(struct objtoo
 			if (ret)
 				return ret;
 
-			if (opts.stackval && func && !is_fentry_call(insn) &&
+			if (opts.stackval && func && !is_special_call(insn) &&
 			    !has_valid_stack_frame(&state)) {
 				WARN_FUNC("call without frame pointer save/setup",
 					  sec, insn->offset);
author maintainer
#187 lore raw

PATCH 187/194 x86/srso: Correct the mitigation status when SMT is disabled

In reply to Greg Kroah-Hartman

From: Borislav Petkov (AMD) <[email protected]>

commit 6405b72e8d17bd1875a56ae52d23ec3cd51b9d66 upstream.

Specify how is SRSO mitigated when SMT is disabled. Also, correct the SMT check for that.

---
 arch/x86/kernel/cpu/bugs.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
arch/x86/kernel/cpu/bugs.c +2 -3
@@ -2398,8 +2398,7 @@ static void __init srso_select_mitigatio
 		 * Zen1/2 with SMT off aren't vulnerable after the right
 		 * IBPB microcode has been applied.
 		 */
-		if ((boot_cpu_data.x86 < 0x19) &&
-		    (!cpu_smt_possible() || (cpu_smt_control == CPU_SMT_DISABLED))) {
+		if (boot_cpu_data.x86 < 0x19 && !cpu_smt_possible()) {
 			setup_force_cpu_cap(X86_FEATURE_SRSO_NO);
 			return;
 		}
@@ -2689,7 +2688,7 @@ static ssize_t gds_show_state(char *buf)
 static ssize_t srso_show_state(char *buf)
 {
 	if (boot_cpu_has(X86_FEATURE_SRSO_NO))
-		return sysfs_emit(buf, "Not affected\n");
+		return sysfs_emit(buf, "Mitigation: SMT disabled\n");
 
 	return sysfs_emit(buf, "%s%s\n",
 			  srso_strings[srso_mitigation],
author maintainer
#188 lore raw

PATCH 188/194 arm64/ptrace: Ensure that SME is set up for target when writing SSVE state

In reply to Greg Kroah-Hartman

From: Mark Brown <[email protected]>

commit 5d0a8d2fba50e9c07cde4aad7fba28c008b07a5b upstream.

When we use NT_ARM_SSVE to either enable streaming mode or change the vector length for a process we do not currently do anything to ensure that there is storage allocated for the SME specific register state. If the task had not previously used SME or we changed the vector length then the task will not have had TIF_SME set or backing storage for ZA/ZT allocated, resulting in inconsistent register sizes when saving state and spurious traps which flush the newly set register state.

We should set TIF_SME to disable traps and ensure that storage is allocated for ZA and ZT if it is not already allocated. This requires modifying sme_alloc() to make the flush of any existing register state optional so we don't disturb existing state for ZA and ZT.

Fixes e12310a0d30f ("arm64/sme: Implement ptrace support for streaming mode SVE registers")
Cc <[email protected]> # 5.19.x
---
 arch/arm64/include/asm/fpsimd.h |    4 ++--
 arch/arm64/kernel/fpsimd.c      |    6 +++---
 arch/arm64/kernel/ptrace.c      |    9 ++++++++-
 arch/arm64/kernel/signal.c      |    2 +-
 4 files changed, 14 insertions(+), 7 deletions(-)
arch/arm64/include/asm/fpsimd.h +2 -2
@@ -339,7 +339,7 @@ static inline int sme_max_virtualisable_
 	return vec_max_virtualisable_vl(ARM64_VEC_SME);
 }
 
-extern void sme_alloc(struct task_struct *task);
+extern void sme_alloc(struct task_struct *task, bool flush);
 extern unsigned int sme_get_vl(void);
 extern int sme_set_current_vl(unsigned long arg);
 extern int sme_get_current_vl(void);
@@ -365,7 +365,7 @@ static inline void sme_smstart_sm(void)
 static inline void sme_smstop_sm(void) { }
 static inline void sme_smstop(void) { }
 
-static inline void sme_alloc(struct task_struct *task) { }
+static inline void sme_alloc(struct task_struct *task, bool flush) { }
 static inline void sme_setup(void) { }
 static inline unsigned int sme_get_vl(void) { return 0; }
 static inline int sme_max_vl(void) { return 0; }
arch/arm64/kernel/fpsimd.c +3 -3
@@ -1239,9 +1239,9 @@ void fpsimd_release_task(struct task_str
  * the interest of testability and predictability, the architecture
  * guarantees that when ZA is enabled it will be zeroed.
  */
-void sme_alloc(struct task_struct *task)
+void sme_alloc(struct task_struct *task, bool flush)
 {
-	if (task->thread.za_state) {
+	if (task->thread.za_state && flush) {
 		memset(task->thread.za_state, 0, za_state_size(task));
 		return;
 	}
@@ -1460,7 +1460,7 @@ void do_sme_acc(unsigned long esr, struc
 	}
 
 	sve_alloc(current, false);
-	sme_alloc(current);
+	sme_alloc(current, true);
 	if (!current->thread.sve_state || !current->thread.za_state) {
 		force_sig(SIGKILL);
 		return;
arch/arm64/kernel/ptrace.c +8 -1
@@ -886,6 +886,13 @@ static int sve_set_common(struct task_st
 			break;
 		case ARM64_VEC_SME:
 			target->thread.svcr |= SVCR_SM_MASK;
+
+			/*
+			 * Disable traps and ensure there is SME storage but
+			 * preserve any currently set values in ZA/ZT.
+			 */
+			sme_alloc(target, false);
+			set_tsk_thread_flag(target, TIF_SME);
 			break;
 		default:
 			WARN_ON_ONCE(1);
@@ -1107,7 +1114,7 @@ static int za_set(struct task_struct *ta
 	}
 
 	/* Allocate/reinit ZA storage */
-	sme_alloc(target);
+	sme_alloc(target, true);
 	if (!target->thread.za_state) {
 		ret = -ENOMEM;
 		goto out;
arch/arm64/kernel/signal.c +1 -1
@@ -430,7 +430,7 @@ static int restore_za_context(struct use
 	fpsimd_flush_task_state(current);
 	/* From now, fpsimd_thread_switch() won't touch thread.sve_state */
 
-	sme_alloc(current);
+	sme_alloc(current, true);
 	if (!current->thread.za_state) {
 		current->thread.svcr &= ~SVCR_ZA_MASK;
 		clear_thread_flag(TIF_SME);
author maintainer
#189 lore raw

PATCH 189/194 drm/amd/pm: skip the RLC stop when S0i3 suspend for SMU v13.0.4/11

In reply to Greg Kroah-Hartman

From: Tim Huang <[email protected]>

commit 730d44e1fa306a20746ad4a85da550662aed9daa upstream.

For SMU v13.0.4/11, driver does not need to stop RLC for S0i3, the firmwares will handle that properly.

---
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c +2 -2
@@ -1562,9 +1562,9 @@ static int smu_disable_dpms(struct smu_c
 
 	/*
 	 * For SMU 13.0.4/11, PMFW will handle the features disablement properly
-	 * for gpu reset case. Driver involvement is unnecessary.
+	 * for gpu reset and S0i3 cases. Driver involvement is unnecessary.
 	 */
-	if (amdgpu_in_reset(adev)) {
+	if (amdgpu_in_reset(adev) || adev->in_s0ix) {
 		switch (adev->ip_versions[MP1_HWIP][0]) {
 		case IP_VERSION(13, 0, 4):
 		case IP_VERSION(13, 0, 11):
author maintainer
#190 lore raw

PATCH 190/194 drm/amdgpu: keep irq count in amdgpu_irq_disable_all

In reply to Greg Kroah-Hartman

From: Guchun Chen <[email protected]>

commit 8ffd6f0442674f32c048ec8dffdbc5ec67829beb upstream.

This can clean up all irq warnings because of unbalanced amdgpu_irq_get/put when unplugging/unbinding device, and leave irq count decrease in each ip fini function.

---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c |    1 -
 1 file changed, 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c +0 -1
@@ -160,7 +160,6 @@ void amdgpu_irq_disable_all(struct amdgp
 				continue;
 
 			for (k = 0; k < src->num_types; ++k) {
-				atomic_set(&src->enabled_types[k], 0);
 				r = src->funcs->set(adev, src, k,
 						    AMDGPU_IRQ_STATE_DISABLE);
 				if (r)
author maintainer
#191 lore raw

PATCH 191/194 af_unix: Fix null-ptr-deref in unix_stream_sendpage().

In reply to Greg Kroah-Hartman

From: Kuniyuki Iwashima <[email protected]>

Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage() with detailed analysis and a nice repro.

unix_stream_sendpage() tries to add data to the last skb in the peer's recv queue without locking the queue.

If the peer's FD is passed to another socket and the socket's FD is passed to the peer, there is a loop between them. If we close both sockets without receiving FD, the sockets will be cleaned up by garbage collection.

The garbage collection iterates such sockets and unlinks skb with FD from the socket's receive queue under the queue's lock.

So, there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.

To avoid the issue, unix_stream_sendpage() must lock the peer's recv queue.

Note the issue does not exist in 6.5+ thanks to the recent sendpage() refactoring.

This patch is originally written by Linus Torvalds.

BUG: unable to handle page fault for address: ffff988004dd6870

PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
PREEMPT SMP PTI

CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0
Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44
RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246
RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284
RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0
RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003
R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00
R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8
FS:  00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0
PKRU: 55555554
Call Trace:
 <TASK>
 ? __die_body.cold+0x1a/0x1f
 ? page_fault_oops+0xa9/0x1e0
 ? fixup_exception+0x1d/0x310
 ? exc_page_fault+0xa8/0x150
 ? asm_exc_page_fault+0x22/0x30
 ? kmem_cache_alloc_node+0xa2/0x1e0
 ? __alloc_skb+0x16c/0x1e0
 __alloc_skb+0x16c/0x1e0
 alloc_skb_with_frags+0x48/0x1e0
 sock_alloc_send_pskb+0x234/0x270
 unix_stream_sendmsg+0x1f5/0x690
 sock_sendmsg+0x5d/0x60
 ____sys_sendmsg+0x210/0x260
 ___sys_sendmsg+0x83/0xd0
 ? kmem_cache_alloc+0xc6/0x1c0
 ? avc_disable+0x20/0x20
 ? percpu_counter_add_batch+0x53/0xc0
 ? alloc_empty_file+0x5d/0xb0
 ? alloc_file+0x91/0x170
 ? alloc_file_pseudo+0x94/0x100
 ? __fget_light+0x9f/0x120
 __sys_sendmsg+0x54/0xa0
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x69/0xd3
RIP: 0033:0x7f174d639a7d
Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48
RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d
RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007
RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff
R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28
R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000
 </TASK>
---
 net/unix/af_unix.c |    9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)
net/unix/af_unix.c +4 -5
@@ -2290,6 +2290,7 @@ static ssize_t unix_stream_sendpage(stru
 
 	if (false) {
 alloc_skb:
+		spin_unlock(&other->sk_receive_queue.lock);
 		unix_state_unlock(other);
 		mutex_unlock(&unix_sk(other)->iolock);
 		newskb = sock_alloc_send_pskb(sk, 0, 0, flags & MSG_DONTWAIT,
@@ -2329,6 +2330,7 @@ alloc_skb:
 		init_scm = false;
 	}
 
+	spin_lock(&other->sk_receive_queue.lock);
 	skb = skb_peek_tail(&other->sk_receive_queue);
 	if (tail && tail == skb) {
 		skb = newskb;
@@ -2359,14 +2361,11 @@ alloc_skb:
 	refcount_add(size, &sk->sk_wmem_alloc);
 
 	if (newskb) {
-		err = unix_scm_to_skb(&scm, skb, false);
-		if (err)
-			goto err_state_unlock;
-		spin_lock(&other->sk_receive_queue.lock);
+		unix_scm_to_skb(&scm, skb, false);
 		__skb_queue_tail(&other->sk_receive_queue, newskb);
-		spin_unlock(&other->sk_receive_queue.lock);
 	}
 
+	spin_unlock(&other->sk_receive_queue.lock);
 	unix_state_unlock(other);
 	mutex_unlock(&unix_sk(other)->iolock);
 
author maintainer
#192 lore raw

PATCH 192/194 drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

In reply to Greg Kroah-Hartman

From: Karol Herbst <[email protected]>

commit 1b254b791d7b7dea6e8adc887fbbd51746d8bb27 upstream.

We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first.

It might not fix all regressions from commit 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it fixes a memory corruption in error handling related to that commit.

---
 drivers/gpu/drm/nouveau/nouveau_connector.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_connector.c +6 -2
@@ -1407,8 +1407,7 @@ nouveau_connector_create(struct drm_devi
 		ret = nvif_conn_ctor(&disp->disp, nv_connector->base.name, nv_connector->index,
 				     &nv_connector->conn);
 		if (ret) {
-			kfree(nv_connector);
-			return ERR_PTR(ret);
+			goto drm_conn_err;
 		}
 	}
 
@@ -1470,4 +1469,9 @@ nouveau_connector_create(struct drm_devi
 
 	drm_connector_register(connector);
 	return connector;
+
+drm_conn_err:
+	drm_connector_cleanup(connector);
+	kfree(nv_connector);
+	return ERR_PTR(ret);
 }
author maintainer
#193 lore raw

PATCH 193/194 net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled

In reply to Greg Kroah-Hartman

From: Jason Xing <[email protected]>

commit e4dd0d3a2f64b8bd8029ec70f52bdbebd0644408 upstream.

In the real workload, I encountered an issue which could cause the RTO timer to retransmit the skb per 1ms with linear option enabled. The amount of lost-retransmitted skbs can go up to 1000+ instantly.

The root cause is that if the icsk_rto happens to be zero in the 6th round (which is the TCP_THIN_LINEAR_RETRIES value), then it will always be zero due to the changed calculation method in tcp_retransmit_timer() as follows:

icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);

Above line could be converted to
icsk->icsk_rto = min(0 << 1, TCP_RTO_MAX) = 0

Therefore, the timer expires so quickly without any doubt.

I read through the RFC 6298 and found that the RTO value can be rounded up to a certain value, in Linux, say TCP_RTO_MIN as default, which is regarded as the lower bound in this patch as suggested by Eric.

Fixes 36e31b0af587 ("net: TCP thin linear timeouts")
---
 net/ipv4/tcp_timer.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
net/ipv4/tcp_timer.c +3 -1
@@ -586,7 +586,9 @@ out_reset_timer:
 	    tcp_stream_is_thin(tp) &&
 	    icsk->icsk_retransmits <= TCP_THIN_LINEAR_RETRIES) {
 		icsk->icsk_backoff = 0;
-		icsk->icsk_rto = min(__tcp_set_rto(tp), TCP_RTO_MAX);
+		icsk->icsk_rto = clamp(__tcp_set_rto(tp),
+				       tcp_rto_min(sk),
+				       TCP_RTO_MAX);
 	} else {
 		/* Use normal (exponential) backoff */
 		icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
author maintainer
#194 lore raw

PATCH 194/194 mmc: f-sdh30: fix order of function calls in sdhci_f_sdh30_remove

In reply to Greg Kroah-Hartman

From: Yangtao Li <[email protected]>

commit 58abdd80b93b09023ca03007b608685c41e3a289 upstream.

The order of function calls in sdhci_f_sdh30_remove is wrong, let's call sdhci_pltfm_unregister first.

---
 drivers/mmc/host/sdhci_f_sdh30.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/mmc/host/sdhci_f_sdh30.c +5 -3
@@ -188,12 +188,14 @@ static int sdhci_f_sdh30_remove(struct p
 {
 	struct sdhci_host *host = platform_get_drvdata(pdev);
 	struct f_sdhost_priv *priv = sdhci_f_sdhost_priv(host);
-
-	clk_disable_unprepare(priv->clk_iface);
-	clk_disable_unprepare(priv->clk);
+	struct clk *clk_iface = priv->clk_iface;
+	struct clk *clk = priv->clk;
 
 	sdhci_pltfm_unregister(pdev);
 
+	clk_disable_unprepare(clk_iface);
+	clk_disable_unprepare(clk);
+
 	return 0;
 }
 
Tested-by on the v1 series
#195 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

For RCU,

thanks,

- Joel

Quoted 852 lines

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>

    Linux 6.1.47-rc1

Yangtao Li <[email protected]>
mmc: f-sdh30: fix order of function calls in sdhci_f_sdh30_remove

Jason Xing <[email protected]>
net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled

Karol Herbst <[email protected]>
drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create

Kuniyuki Iwashima <[email protected]>
af_unix: Fix null-ptr-deref in unix_stream_sendpage().

Guchun Chen <[email protected]>
drm/amdgpu: keep irq count in amdgpu_irq_disable_all

Tim Huang <[email protected]>
drm/amd/pm: skip the RLC stop when S0i3 suspend for SMU v13.0.4/11

Mark Brown <[email protected]>
arm64/ptrace: Ensure that SME is set up for target when writing SSVE state

Borislav Petkov (AMD) <[email protected]>
x86/srso: Correct the mitigation status when SMT is disabled

Peter Zijlstra <[email protected]>
objtool/x86: Fixup frame-pointer vs rethunk

Petr Pavlu <[email protected]>
x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG

Borislav Petkov (AMD) <[email protected]>
x86/srso: Disable the mitigation on unaffected configurations

Borislav Petkov (AMD) <[email protected]>
x86/CPU/AMD: Fix the DIV(0) initial fix attempt

Sean Christopherson <[email protected]>
x86/retpoline: Don't clobber RFLAGS during srso_safe_ret()

Peter Zijlstra <[email protected]>

    x86/static_call: Fix __static_call_fixup()

Borislav Petkov (AMD) <[email protected]>
x86/srso: Explain the untraining sequences a bit more

Peter Zijlstra <[email protected]>
x86/cpu: Cleanup the untrain mess

Peter Zijlstra <[email protected]>

    x86/cpu: Rename srso_(.*)_alias to srso_alias_\1

Peter Zijlstra <[email protected]>
x86/cpu: Rename original retbleed methods

Peter Zijlstra <[email protected]>
x86/cpu: Clean up SRSO return thunk mess

Peter Zijlstra <[email protected]>
x86/alternative: Make custom return thunk unconditional

Peter Zijlstra <[email protected]>

    x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()

Peter Zijlstra <[email protected]>
x86/cpu: Fix __x86_return_thunk symbol type

Xin Long <[email protected]>
netfilter: set default timeout to 3 secs for sctp shutdown send and recv state

Mike Kravetz <[email protected]>
hugetlb: do not clear hugetlb dtor until allocating vmemmap

Saaem Rizvi <[email protected]>
drm/amd/display: Implement workaround for writing to OTG_PIXEL_RATE_DIV register

Vincent Guittot <[email protected]>
sched/fair: Remove capacity inversion detection

Vincent Guittot <[email protected]>
sched/fair: unlink misfit task from cpu overutilized

Sergey Senozhatsky <[email protected]>
zsmalloc: allow only one active pool compaction context

Daniel Miess <[email protected]>
drm/amd/display: disable RCO for DCN314

Arnd Bergmann <[email protected]>
ASoC: amd: vangogh: select CONFIG_SND_AMD_ACP_CONFIG

Umio Yasuno <[email protected]>
drm/amdgpu/pm: fix throttle_status for other than MP1 11.0.7

Tim Huang <[email protected]>
drm/amdgpu: skip fence GFX interrupts disable/enable for S0ix

Mario Limonciello <[email protected]>
drm/amd: flush any delayed gfxoff on suspend entry

Jani Nikula <[email protected]>
drm/i915/sdvo: fix panel_type initialization

Wander Lairson Costa <[email protected]>
drm/qxl: fix UAF on handle creation

Yibin Ding <[email protected]>
mmc: block: Fix in_flight[issue_type] value error

Yang Yingliang <[email protected]>
mmc: wbsd: fix double mmc_free_host() in wbsd_init()

Sweet Tea Dorminy <[email protected]>
blk-crypto: dynamically allocate fallback profile

Yogesh Hegde <[email protected]>
arm64: dts: rockchip: Fix Wifi/Bluetooth on ROCK Pi 4 boards

Hawkins Jiawei <[email protected]>
virtio-net: Zero max_tx_vq field for VIRTIO_NET_CTRL_MQ_HASH_CONFIG case

Mingzheng Xing <[email protected]>
riscv: Handle zicsr/zifencei issue between gcc and binutils

Russell Harmon via samba-technical <[email protected]>
cifs: Release folio lock on fscache read hit.

dengxiang <[email protected]>
ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces.

Tony Lindgren <[email protected]>

    serial: 8250: Fix oops for port->pm on uart_change_pm()

Alexandre Ghiti <[email protected]>
riscv: uaccess: Return the number of bytes effectively not copied

Kailang Yang <[email protected]>
ALSA: hda/realtek - Remodified 3k pull low procedure

Jiasheng Jiang <[email protected]>
soc: aspeed: socinfo: Add kfree for kstrdup

Zev Weiss <[email protected]>
soc: aspeed: uart-routing: Use __sysfs_match_string

Stefan Binding <[email protected]>
ALSA: hda/realtek: Add quirks for HP G11 Laptops

Jerome Brunet <[email protected]>
ASoC: meson: axg-tdm-formatter: fix channel slot allocation

Zhang Shurong <[email protected]>
ASoC: rt5665: add missed regulator_bulk_disable

Alexander Stein <[email protected]>
arm64: dts: imx93: Fix anatop node size

Xiaolei Wang <[email protected]>
ARM: dts: imx: Set default tuning step for imx6sx usdhc

Fabio Estevam <[email protected]>
arm64: dts: imx8mm: Drop CSI1 PHY reference clock configuration

Andrej Picej <[email protected]>
ARM: dts: imx6: phytec: fix RTC interrupt level

Krzysztof Kozlowski <[email protected]>
ARM: dts: imx: align LED node names with dtschema

Christopher Obbard <[email protected]>
arm64: dts: rockchip: Disable HS400 for eMMC on ROCK 4C+

Christopher Obbard <[email protected]>
arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4

Dmitry Baryshkov <[email protected]>
arm64: dts: qcom: qrb5165-rb5: fix thermal zone conflict

Tony Lindgren <[email protected]>
bus: ti-sysc: Flush posted write on enable before reset

Marcin Szycik <[email protected]>
ice: Block switchdev mode when ADQ is active and vice versa

Manish Chopra <[email protected]>
qede: fix firmware halt over suspend and resume

Eric Dumazet <[email protected]>
net: do not allow gso_size to be set to GSO_BY_FRAGS

Abel Wu <[email protected]>
sock: Fix misuse of sk_under_memory_pressure()

Edward Cree <[email protected]>
sfc: don't unregister flow_indr if it was never registered

Alfred Lee <[email protected]>
net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset

Andrii Staikov <[email protected]>
i40e: fix misleading debug logs

Piotr Gardocki <[email protected]>
iavf: fix FDIR rule fields masks validation

Jakub Kicinski <[email protected]>
net: openvswitch: reject negative ifindex

Ziyang Xuan <[email protected]>
team: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves

Justin Chen <[email protected]>
net: phy: broadcom: stub c45 read/write for 54810

Pablo Neira Ayuso <[email protected]>
netfilter: nft_dynset: disallow object maps

Sishuai Gong <[email protected]>
ipvs: fix racy memcpy in proc_do_sync_threshold

Florian Westphal <[email protected]>
netfilter: nf_tables: deactivate catchall elements in next generation

Florian Westphal <[email protected]>
netfilter: nf_tables: fix false-positive lockdep splat

Michal Schmidt <[email protected]>
octeon_ep: cancel tx_timeout_task later in remove sequence

Radhey Shyam Pandey <[email protected]>
net: macb: In ZynqMP resume always configure PS GTR for non-wakeup source

Luca Ceresoli <[email protected]>
drm/panel: simple: Fix AUO G121EAN01 panel timings according to the docs

Petr Machata <[email protected]>
selftests: mirror_gre_changes: Tighten up the TTL test match

Russell King (Oracle) <[email protected]>
net: phy: fix IRQ-based wake-on-lan over hibernate / power off

Xiang Yang <[email protected]>
net: pcs: Add missing put_device call in miic_create

Jason Wang <[email protected]>
virtio-net: set queues after driver_ok

Laurent Vivier <[email protected]>
virtio_net: notify MAC address change on device initialization

Lin Ma <[email protected]>
xfrm: add forgotten nla_policy for XFRMA_MTIMER_THRESH

Lin Ma <[email protected]>
xfrm: add NULL check in xfrm_update_ae_params

Zhengchao Shao <[email protected]>
ip_vti: fix potential slab-use-after-free in decode_session6

Zhengchao Shao <[email protected]>
ip6_vti: fix slab-use-after-free in decode_session6

Zhengchao Shao <[email protected]>
xfrm: fix slab-use-after-free in decode_session6

Lin Ma <[email protected]>
net: xfrm: Amend XFRMA_SEC_CTX nla_policy structure

Lin Ma <[email protected]>
net: af_key: fix sadb_x_filter validation

Lin Ma <[email protected]>
net: xfrm: Fix xfrm_address_filter OOB read

Tam Nguyen <[email protected]>
i2c: designware: Handle invalid SMBus block data response length value

Quan Nguyen <[email protected]>
i2c: designware: Correct length byte validation logic

xiaoshoukui <[email protected]>
btrfs: fix BUG_ON condition in btrfs_cancel_balance

Josef Bacik <[email protected]>
btrfs: fix incorrect splitting in btrfs_drop_extent_map_range

Sherry Sun <[email protected]>
tty: serial: fsl_lpuart: Clear the error flags by writing 1 for lpuart32 platforms

Yi Yang <[email protected]>
tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux

Dragos Tatulea <[email protected]>
vdpa: Enable strict validation for netlinks ops

Lin Ma <[email protected]>
vdpa: Add max vqp attr to vdpa_nl_policy for nlattr length check

Lin Ma <[email protected]>
vdpa: Add queue index attr to vdpa_nl_policy for nlattr length check

Lin Ma <[email protected]>
vdpa: Add features attr to vdpa_nl_policy for nlattr length check

Nathan Lynch <[email protected]>
powerpc/rtas_flash: allow user copy to flash block cache objects

Yuanjun Gong <[email protected]>
fbdev: mmp: fix value check in mmphw_probe()

Parker Newman <[email protected]>
i2c: tegra: Fix i2c-tegra DMA config option processing

Yicong Yang <[email protected]>
i2c: hisi: Only handle the interrupt of the driver's transfer

Chengfeng Ye <[email protected]>
i2c: bcm-iproc: Fix bcm_iproc_i2c_isr deadlock issue

Steve French <[email protected]>
cifs: fix potential oops in cifs_oplock_break

Eugenio Pérez <[email protected]>
vdpa/mlx5: Delete control vq iotlb in destroy_mr only when necessary

Dragos Tatulea <[email protected]>

    vdpa/mlx5: Fix mr->initialized semantics

Maxime Coquelin <[email protected]>
vduse: Use proper spinlock for IRQ injection

Wolfram Sang <[email protected]>
virtio-mmio: don't break lifecycle of vm_dev

Filipe Manana <[email protected]>
btrfs: fix use-after-free of new block group that became unused

David Sterba <[email protected]>
btrfs: convert btrfs_block_group::seq_zone to runtime flag

David Sterba <[email protected]>
btrfs: convert btrfs_block_group::needs_free_space to runtime flag

Naohiro Aota <[email protected]>
btrfs: move out now unused BG from the reclaim list

Daniel Vetter <[email protected]>
video/aperture: Only remove sysfb on the default vga pci device

Thomas Zimmermann <[email protected]>
fbdev/hyperv-fb: Do not set struct fb_info.apertures

Xu Yang <[email protected]>
ARM: dts: nxp/imx6sll: fix wrong property name in usbphy node

Marc Zyngier <[email protected]>
KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemption

Hersen Wu <[email protected]>
drm/amd/display: fix access hdcp_workqueue assert

hersen wu <[email protected]>
drm/amd/display: phase3 mst hdcp for multiple displays

hersen wu <[email protected]>
drm/amd/display: save restore hdcp state when display is unplugged from mst hub

Song Yoong Siang <[email protected]>
igc: read before write to SRRCTL register

Chen Lin <[email protected]>
ring-buffer: Do not swap cpu_buffer during resize process

Andy Shevchenko <[email protected]>
Bluetooth: MGMT: Use correct address for memcpy()

Benjamin Gray <[email protected]>
powerpc/kasan: Disable KCOV in KASAN code

Luke D. Jones <[email protected]>
ALSA: hda/realtek: Add quirk for ASUS ROG GZ301V

Luke D. Jones <[email protected]>
ALSA: hda/realtek: Add quirk for ASUS ROG GA402X

Luke D. Jones <[email protected]>
ALSA: hda/realtek: Add quirk for ASUS ROG GX650P

Tuo Li <[email protected]>
ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()

dengxiang <[email protected]>
ALSA: hda/realtek: Add quirks for Unis H3C Desktop B760 & Q760

Konstantin Komarov <[email protected]>
fs/ntfs3: Mark ntfs dirty when on-disk struct is corrupted

Jia-Ju Bai <[email protected]>
fs: ntfs3: Fix possible null-pointer dereferences in mi_read()

Edward Lo <[email protected]>
fs/ntfs3: Enhance sanity check while generating attr_list

shanzhulig <[email protected]>
drm/amdgpu: Fix potential fence use-after-free v2

Xiubo Li <[email protected]>
ceph: try to dump the msgs when decoding fails

Matthew Anderson <[email protected]>
Bluetooth: btusb: Add MT7922 bluetooth ID for the Asus Ally

Zhengping Jiang <[email protected]>
Bluetooth: L2CAP: Fix use-after-free

Yuechao Zhao <[email protected]>
watchdog: sp5100_tco: support Hygon FCH/SCH (Server Controller Hub)

Zhang Shurong <[email protected]>
firewire: net: fix use after free in fwnet_finish_incoming_packet()

Mika Westerberg <[email protected]>
thunderbolt: Limit Intel Barlow Ridge USB3 bandwidth

Mika Westerberg <[email protected]>
thunderbolt: Add Intel Barlow Ridge PCI ID

Armin Wolf <[email protected]>
pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db()

Tuo Li <[email protected]>
gfs2: Fix possible data races in gfs2_show_options()

Xu Yang <[email protected]>
usb: chipidea: imx: add missing USB PHY DPDM wakeup setting

Xu Yang <[email protected]>
usb: chipidea: imx: don't request QoS for imx8ulp

Mika Westerberg <[email protected]>
thunderbolt: Read retimer NVM authentication status prior tb_retimer_set_inbound_sbtx()

Hans Verkuil <[email protected]>
media: platform: mediatek: vpu: fix NULL ptr dereference

Avichal Rakesh <[email protected]>
usb: gadget: uvc: queue empty isoc requests if no video buffer is available

Prashanth K <[email protected]>
usb: gadget: u_serial: Avoid spinlock recursion in __gs_console_push

Andrey Konovalov <[email protected]>
media: camss: set VFE bpl_alignment to 16 for sdm845 and sm8250

Yunfei Dong <[email protected]>
media: v4l2-mem2mem: add lock to protect parameter num_rdy

Lu Hongfei <[email protected]>
led: qcom-lpg: Fix resource leaks in for_each_available_child_of_node() loops

Uwe Kleine-König <[email protected]>
serial: stm32: Ignore return value of uart_remove_one_port() in .remove()

Winston Wen <[email protected]>
cifs: fix session state check in reconnect to avoid use-after-free issue

Paulo Alcantara <[email protected]>
smb: client: fix warning in cifs_smb3_do_mount()

Matthew Anderson <[email protected]>
ALSA: hda/realtek: Add quirks for ROG ALLY CS35l41 audio

Even Xu <[email protected]>
HID: intel-ish-hid: ipc: Add Arrow Lake PCI device ID

Peter Ujfalusi <[email protected]>
ASoC: SOF: core: Free the firmware trace before calling snd_sof_shutdown()

Daniel Miess <[email protected]>
drm/amd/display: Enable dcn314 DPP RCO

Nicholas Kazlauskas <[email protected]>
drm/amd/display: Skip DPP DTO update if root clock is gated

Patrisious Haddad <[email protected]>
RDMA/mlx5: Return the firmware result upon destroying QP/RQ

Alvin Lee <[email protected]>
drm/amd/display: Apply 60us prefetch for DCFCLK <= 300Mhz

Lang Yu <[email protected]>
drm/amdgpu: install stub fence into potential unused fence pointers

Suravee Suthikulpanit <[email protected]>
iommu/amd: Introduce Disable IRTE Caching Support

stuarthayhurst <[email protected]>
HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard

Ofir Bitton <[email protected]>
accel/habanalabs: add pci health check during heartbeat

gaoxu <[email protected]>
dma-remap: use kvmalloc_array/kvfree for larger dma memory remap

Pierre-Louis Bossart <[email protected]>
ASoC: SOF: Intel: fix SoundWire/HDaudio mutual exclusion

Geert Uytterhoeven <[email protected]>
iopoll: Call cpu_relax() in busy loops

Uday M Bhat <[email protected]>
ASoC: Intel: sof_sdw: Add support for Rex soundwire

Bard Liao <[email protected]>
ASoC: Intel: sof_sdw_rt_sdca_jack_common: test SOF_JACK_JDSRC in _exit

Oleksij Rempel <[email protected]>
ARM: dts: imx6dl: prtrvt, prtvt7, prti6q, prtwd2: fix USB related warnings

Venkata Prasad Potturu <[email protected]>
ASoC: amd: vangogh: Add check for acp config flags in vangogh platform

Wolfram Sang <[email protected]>
drm: rcar-du: remove R-Car H3 ES1.* workarounds

Raphael Gallais-Pou <[email protected]>
drm/stm: ltdc: fix late dereference check

Venkata Prasad Potturu <[email protected]>
ASoC: SOF: amd: Add pci revision id check

Sumit Gupta <[email protected]>
PCI: tegra194: Fix possible array out of bounds access

Peter Ujfalusi <[email protected]>
ASoC: Intel: sof_sdw: add quirk for LNL RVP

Bard Liao <[email protected]>
ASoC: Intel: sof_sdw: add quirk for MTL RVP

Jack Xiao <[email protected]>
drm/amdgpu: fix memory leak in mes self test

hackyzh002 <[email protected]>
drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1

Longlong Yao <[email protected]>
drm/amdgpu: fix calltrace warning in amddrm_buddy_fini

Li Yang <[email protected]>
net: phy: at803x: fix the wol setting functions

Christophe JAILLET <[email protected]>
net: phy: at803x: Use devm_regulator_get_enable_optional()

Gerd Bayer <[email protected]>
net/smc: Fix setsockopt and sysctl to specify same buffer size again

D. Wythe <[email protected]>
net/smc: replace mutex rmbs_lock and sndbufs_lock with rw_semaphore

Ido Schimmel <[email protected]>
selftests: forwarding: tc_actions: Use ncat instead of nc

Davide Caratti <[email protected]>
selftests: forwarding: tc_actions: cleanup temporary files when test is aborted

Andrew Yang <[email protected]>
zsmalloc: fix races between modifications of fullness and isolated

Nhat Pham <[email protected]>
zsmalloc: consolidate zs_pool's migrate_lock and size_class's locks

Maulik Shah <[email protected]>
cpuidle: psci: Move enabling OSI mode after power domains creation

Ulf Hansson <[email protected]>
cpuidle: psci: Extend information in log about OSI/PC mode

Kunihiko Hayashi <[email protected]>
mmc: sdhci-f-sdh30: Replace with sdhci_pltfm

-------------

Diffstat:

 Documentation/admin-guide/hw-vuln/srso.rst         |   4 +-
 Documentation/admin-guide/kernel-parameters.txt    |   1 +
 Makefile                                           |   4 +-
 arch/arm/boot/dts/imx50-kobo-aura.dts              |   2 +-
 arch/arm/boot/dts/imx53-cx9020.dts                 |  10 +-
 arch/arm/boot/dts/imx53-m53evk.dts                 |   4 +-
 arch/arm/boot/dts/imx53-m53menlo.dts               |   6 +-
 arch/arm/boot/dts/imx53-tx53.dtsi                  |   2 +-
 arch/arm/boot/dts/imx53-usbarmory.dts              |   2 +-
 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi              |   6 +-
 arch/arm/boot/dts/imx6dl-prtrvt.dts                |   4 +
 arch/arm/boot/dts/imx6dl-riotboard.dts             |   4 +-
 arch/arm/boot/dts/imx6dl-yapp4-common.dtsi         |   6 +-
 arch/arm/boot/dts/imx6q-gw5400-a.dts               |   6 +-
 arch/arm/boot/dts/imx6q-h100.dts                   |   6 +-
 arch/arm/boot/dts/imx6q-kp.dtsi                    |   4 +-
 arch/arm/boot/dts/imx6q-marsboard.dts              |   4 +-
 arch/arm/boot/dts/imx6q-tbs2910.dts                |   2 +-
 arch/arm/boot/dts/imx6qdl-emcon.dtsi               |   4 +-
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi              |   4 +-
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi              |   2 +-
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi              |   4 +-
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw5903.dtsi              |   2 +-
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw5907.dtsi              |   4 +-
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw5912.dtsi              |   6 +-
 arch/arm/boot/dts/imx6qdl-gw5913.dtsi              |   4 +-
 arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi           |  10 +-
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi       |   4 +-
 arch/arm/boot/dts/imx6qdl-phytec-mira.dtsi         |   8 +-
 arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi       |   4 +-
 arch/arm/boot/dts/imx6qdl-prti6q.dtsi              |  11 +-
 arch/arm/boot/dts/imx6qdl-rex.dtsi                 |   2 +-
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi           |   2 +-
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi             |   2 +-
 arch/arm/boot/dts/imx6qdl-ts7970.dtsi              |   4 +-
 arch/arm/boot/dts/imx6qdl-tx6.dtsi                 |   2 +-
 arch/arm/boot/dts/imx6sl-evk.dts                   |   2 +-
 arch/arm/boot/dts/imx6sll-evk.dts                  |   2 +-
 arch/arm/boot/dts/imx6sll.dtsi                     |   2 +-
 arch/arm/boot/dts/imx6sx-sabreauto.dts             |   2 +-
 arch/arm/boot/dts/imx6sx-udoo-neo.dtsi             |   4 +-
 arch/arm/boot/dts/imx6sx.dtsi                      |   6 +
 arch/arm/boot/dts/imx6ul-phytec-phycore-som.dtsi   |   2 +-
 arch/arm/boot/dts/imx6ul-tx6ul.dtsi                |   2 +-
 arch/arm64/boot/dts/freescale/imx8mm.dtsi          |   7 +-
 arch/arm64/boot/dts/freescale/imx93.dtsi           |   2 +-
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts           |   2 +-
 .../boot/dts/rockchip/rk3399-rock-4c-plus.dts      |   3 +-
 arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi |   6 +-
 arch/arm64/include/asm/fpsimd.h                    |   4 +-
 arch/arm64/include/asm/kvm_host.h                  |   2 +
 arch/arm64/kernel/fpsimd.c                         |   6 +-
 arch/arm64/kernel/ptrace.c                         |   9 +-
 arch/arm64/kernel/signal.c                         |   2 +-
 arch/arm64/kvm/arm.c                               |   6 +-
 arch/arm64/kvm/vgic/vgic-v3.c                      |   2 +-
 arch/arm64/kvm/vgic/vgic-v4.c                      |   7 +-
 arch/powerpc/kernel/rtas_flash.c                   |   6 +-
 arch/powerpc/mm/kasan/Makefile                     |   1 +
 arch/riscv/Kconfig                                 |  28 +--
 arch/riscv/kernel/compat_vdso/Makefile             |   8 +-
 arch/riscv/lib/uaccess.S                           |  11 +-
 arch/x86/include/asm/entry-common.h                |   1 +
 arch/x86/include/asm/nospec-branch.h               |  28 +--
 arch/x86/kernel/cpu/amd.c                          |   1 +
 arch/x86/kernel/cpu/bugs.c                         |  28 ++-
 arch/x86/kernel/static_call.c                      |  13 ++
 arch/x86/kernel/traps.c                            |   2 -
 arch/x86/kernel/vmlinux.lds.S                      |  20 +-
 arch/x86/kvm/svm/svm.c                             |   2 +
 arch/x86/lib/retpoline.S                           | 141 +++++++++-----
 block/blk-crypto-fallback.c                        |  36 ++--
 drivers/bluetooth/btusb.c                          |   3 +
 drivers/bus/ti-sysc.c                              |   2 +
 drivers/cpuidle/cpuidle-psci-domain.c              |  42 ++--
 drivers/firewire/net.c                             |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c             |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c         |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c          |  41 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c            |   9 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c            |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c            |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c           |   2 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c             |   6 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 211 +++++++++++++++++----
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.h |  14 ++
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c    |  30 +++
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dccg.h  |   3 +-
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_dccg.c  |   8 +
 .../gpu/drm/amd/display/dc/dcn314/dcn314_dccg.c    |   5 +
 .../drm/amd/display/dc/dcn314/dcn314_resource.c    |  20 ++
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.c  |  22 +++
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.h  |   3 +-
 drivers/gpu/drm/amd/display/dc/dcn32/dcn32_hwseq.c |   2 +-
 .../gpu/drm/amd/display/dc/dcn32/dcn32_resource.h  |   3 +-
 .../amd/display/dc/dml/dcn32/display_mode_vba_32.c |   4 +-
 .../amd/display/dc/dml/dcn32/display_mode_vba_32.h |   2 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/dccg.h       |   1 +
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c          |   4 +-
 .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c    |  14 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c          |   2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c        |   8 +-
 drivers/gpu/drm/panel/panel-simple.c               |  24 +--
 drivers/gpu/drm/qxl/qxl_drv.h                      |   2 +-
 drivers/gpu/drm/qxl/qxl_dumb.c                     |   5 +-
 drivers/gpu/drm/qxl/qxl_gem.c                      |  25 ++-
 drivers/gpu/drm/qxl/qxl_ioctl.c                    |   6 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c             |  37 +---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c              |  48 -----
 drivers/gpu/drm/rcar-du/rcar_du_drv.h              |   2 -
 drivers/gpu/drm/rcar-du/rcar_du_regs.h             |   3 +-
 drivers/gpu/drm/stm/ltdc.c                         |   4 +-
 drivers/hid/hid-logitech-hidpp.c                   |   4 +
 drivers/hid/intel-ish-hid/ipc/hw-ish.h             |   1 +
 drivers/hid/intel-ish-hid/ipc/pci-ish.c            |   1 +
 drivers/i2c/busses/i2c-bcm-iproc.c                 |  11 +-
 drivers/i2c/busses/i2c-designware-master.c         |  16 +-
 drivers/i2c/busses/i2c-hisi.c                      |   8 +
 drivers/i2c/busses/i2c-tegra.c                     |   2 +-
 drivers/infiniband/hw/mlx5/qpc.c                   |  10 +-
 drivers/iommu/amd/amd_iommu_types.h                |   4 +
 drivers/iommu/amd/init.c                           |  36 ++++
 drivers/leds/rgb/leds-qcom-lpg.c                   |   8 +-
 drivers/media/platform/mediatek/vpu/mtk_vpu.c      |   6 +-
 drivers/media/platform/qcom/camss/camss-vfe.c      |   6 +-
 drivers/misc/habanalabs/common/device.c            |  15 +-
 drivers/misc/habanalabs/common/habanalabs.h        |   2 +
 drivers/misc/habanalabs/common/habanalabs_drv.c    |   2 -
 drivers/mmc/core/block.c                           |   7 +-
 drivers/mmc/host/sdhci_f_sdh30.c                   |  66 +++----
 drivers/mmc/host/wbsd.c                            |   2 -
 drivers/net/dsa/mv88e6xxx/chip.c                   |   8 +
 drivers/net/ethernet/cadence/macb_main.c           |   9 +-
 drivers/net/ethernet/intel/i40e/i40e_nvm.c         |  16 +-
 drivers/net/ethernet/intel/iavf/iavf_ethtool.c     |  10 +
 drivers/net/ethernet/intel/iavf/iavf_fdir.c        |  77 +++++++-
 drivers/net/ethernet/intel/iavf/iavf_fdir.h        |   2 +
 drivers/net/ethernet/intel/ice/ice_eswitch.c       |   6 +
 drivers/net/ethernet/intel/ice/ice_main.c          |   5 +
 drivers/net/ethernet/intel/igc/igc_base.h          |  11 +-
 drivers/net/ethernet/intel/igc/igc_main.c          |   7 +-
 .../net/ethernet/marvell/octeon_ep/octep_main.c    |   2 +-
 drivers/net/ethernet/qlogic/qede/qede_main.c       |  10 +
 drivers/net/ethernet/sfc/tc.c                      |   2 +-
 drivers/net/pcs/pcs-rzn1-miic.c                    |  10 +-
 drivers/net/phy/at803x.c                           |  89 ++++-----
 drivers/net/phy/broadcom.c                         |  13 ++
 drivers/net/phy/phy_device.c                       |  13 +-
 drivers/net/team/team.c                            |   4 +-
 drivers/net/virtio_net.c                           |  26 ++-
 drivers/pci/controller/dwc/pcie-tegra194.c         |  13 +-
 drivers/pcmcia/rsrc_nonstatic.c                    |   2 +
 drivers/soc/aspeed/aspeed-socinfo.c                |   1 +
 drivers/soc/aspeed/aspeed-uart-routing.c           |   2 +-
 drivers/thunderbolt/nhi.c                          |   2 +
 drivers/thunderbolt/nhi.h                          |   4 +
 drivers/thunderbolt/quirks.c                       |   8 +
 drivers/thunderbolt/retimer.c                      |  29 ++-
 drivers/tty/n_gsm.c                                |   3 +-
 drivers/tty/serial/8250/8250_port.c                |   1 +
 drivers/tty/serial/fsl_lpuart.c                    |   4 +-
 drivers/tty/serial/stm32-usart.c                   |   5 +-
 drivers/usb/chipidea/ci_hdrc_imx.c                 |   5 +
 drivers/usb/chipidea/usbmisc_imx.c                 |   2 +-
 drivers/usb/gadget/function/u_serial.c             |   3 +
 drivers/usb/gadget/function/uvc_video.c            |  32 +++-
 drivers/vdpa/mlx5/core/mlx5_vdpa.h                 |   2 +
 drivers/vdpa/mlx5/core/mr.c                        | 105 +++++++---
 drivers/vdpa/mlx5/net/mlx5_vnet.c                  |   4 +-
 drivers/vdpa/vdpa.c                                |   9 +-
 drivers/vdpa/vdpa_user/vduse_dev.c                 |   8 +-
 drivers/video/aperture.c                           |   7 +-
 drivers/video/fbdev/hyperv_fb.c                    |  17 +-
 drivers/video/fbdev/mmp/hw/mmp_ctrl.c              |   4 +-
 drivers/virtio/virtio_mmio.c                       |   5 +-
 drivers/watchdog/sp5100_tco.c                      |   4 +-
 fs/btrfs/block-group.c                             |  14 +-
 fs/btrfs/block-group.h                             |  18 +-
 fs/btrfs/extent_map.c                              |   6 +-
 fs/btrfs/free-space-tree.c                         |  10 +-
 fs/btrfs/tests/free-space-tree-tests.c             |   2 +-
 fs/btrfs/volumes.c                                 |   3 +-
 fs/btrfs/zoned.c                                   |   7 +-
 fs/ceph/mds_client.c                               |   4 +
 fs/gfs2/super.c                                    |  26 +--
 fs/ntfs3/frecord.c                                 |  16 +-
 fs/ntfs3/fsntfs.c                                  |   2 +-
 fs/ntfs3/index.c                                   |   6 +
 fs/ntfs3/ntfs_fs.h                                 |   2 +
 fs/ntfs3/record.c                                  |  10 +-
 fs/smb/client/cifsfs.c                             |  28 +--
 fs/smb/client/file.c                               |  25 ++-
 fs/smb/client/smb2pdu.c                            |   6 +
 include/kvm/arm_vgic.h                             |   2 +-
 include/linux/iopoll.h                             |   2 +
 include/linux/virtio_net.h                         |   4 +
 include/media/v4l2-mem2mem.h                       |  18 +-
 include/net/sock.h                                 |   6 +
 kernel/dma/remap.c                                 |   4 +-
 kernel/sched/fair.c                                | 193 +++++++++----------
 kernel/sched/sched.h                               |  19 --
 kernel/trace/ring_buffer.c                         |  14 +-
 kernel/trace/trace.c                               |   3 +-
 mm/hugetlb.c                                       |  75 +++++---
 mm/zsmalloc.c                                      | 113 +++++------
 net/bluetooth/l2cap_core.c                         |   5 +
 net/bluetooth/mgmt.c                               |   2 +-
 net/core/sock.c                                    |   2 +-
 net/ipv4/ip_vti.c                                  |   4 +-
 net/ipv4/tcp_timer.c                               |   4 +-
 net/ipv6/ip6_vti.c                                 |   4 +-
 net/key/af_key.c                                   |   4 +-
 net/netfilter/ipvs/ip_vs_ctl.c                     |   4 +
 net/netfilter/nf_conntrack_proto_sctp.c            |   6 +-
 net/netfilter/nf_tables_api.c                      |   1 +
 net/netfilter/nft_dynset.c                         |   3 +
 net/netfilter/nft_set_pipapo.c                     |  13 +-
 net/openvswitch/datapath.c                         |   8 +-
 net/smc/af_smc.c                                   |   4 +-
 net/smc/smc.h                                      |   2 +-
 net/smc/smc_clc.c                                  |   4 +-
 net/smc/smc_core.c                                 |  80 ++++----
 net/smc/smc_core.h                                 |   4 +-
 net/smc/smc_llc.c                                  |  16 +-
 net/smc/smc_sysctl.c                               |  10 +-
 net/unix/af_unix.c                                 |   9 +-
 net/xfrm/xfrm_compat.c                             |   2 +-
 net/xfrm/xfrm_interface_core.c                     |   4 +-
 net/xfrm/xfrm_user.c                               |  14 +-
 sound/hda/hdac_regmap.c                            |   7 +-
 sound/pci/hda/patch_realtek.c                      |  91 ++++++++-
 sound/soc/amd/Kconfig                              |   1 +
 sound/soc/amd/vangogh/acp5x.h                      |   2 +
 sound/soc/amd/vangogh/pci-acp5x.c                  |   7 +-
 sound/soc/codecs/rt5665.c                          |   2 +
 sound/soc/intel/boards/sof_sdw.c                   |  25 +++
 sound/soc/intel/boards/sof_sdw_rt711_sdca.c        |   3 +
 sound/soc/meson/axg-tdm-formatter.c                |  42 ++--
 sound/soc/sof/amd/acp.h                            |   3 +
 sound/soc/sof/amd/pci-rmb.c                        |   3 +
 sound/soc/sof/amd/pci-rn.c                         |   3 +
 sound/soc/sof/core.c                               |   4 +-
 sound/soc/sof/intel/hda.c                          |  12 +-
 sound/usb/quirks-table.h                           |  29 +++
 tools/objtool/arch/x86/decode.c                    |   2 +-
 tools/objtool/check.c                              |  21 +-
 .../selftests/net/forwarding/mirror_gre_changes.sh |   3 +-
 .../testing/selftests/net/forwarding/tc_actions.sh |  18 +-
 255 files changed, 2074 insertions(+), 1100 deletions(-)
#196 lore raw
Quoted 15 lines · Joel Fernandes
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +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/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

Quoted 6 lines
Quoted 3 lines

thanks,

greg k-h

For RCU,

I am getting the following warning which started after my last successful 6.1.47-rc1 run. Looks like others already reported it, but I am just archiving my finding here:

Thanks.

[    2.169887] ------------[ cut here ]------------
[    2.170593] missing return thunk: __alt_instructions_end+0x2256/0x227c-srso_untrain_ret+0x0/0x2: e9 c7 a0 ed fe
[    2.171678] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:572 apply_returns+0x1fb/0x230
[    2.173592] Modules linked in:
[    2.174625] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.47-rc1-g9beeea9636e6 #299
[    2.175608] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[    2.176593] RIP: 0010:apply_returns+0x1fb/0x230
[    2.177592] Code: a5 01 00 0f 85 ef fe ff ff 49 89 d8 b9 05 00 00 00 4c 89 f2 48 89 de 48 c7 c7 60 3e 9d ad c6 05 fa 2c a5 01 01 e8 45 2d 04 00 <0f> 0b e9 c7 fe ff ff c7 84 24 89 00 00 00 cc cc cc cc 42 c7 84 04
[    2.179589] RSP: 0000:ffffffffadc03e28 EFLAGS: 00010286
[    2.180592] RAX: 0000000000000000 RBX: ffffffffae5292f2 RCX: 0000000000000000
[    2.181591] RDX: 0000000000000003 RSI: 0000000000000001 RDI: 00000000ffffffff
[    2.182595] RBP: 0000000000000000 R08: 00000000ffffdfff R09: 00000000ffffdfff
[    2.184589] R10: ffffffffadc574a0 R11: ffffffffadc574a0 R12: ffffffffadc03e40
[    2.185591] R13: ffffffffae520414 R14: ffffffffad4033be R15: ffffffffae5203f0
[    2.186650] FS:  0000000000000000(0000) GS:ffff953a5ca00000(0000) knlGS:0000000000000000
[    2.187637] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    2.188592] CR2: ffff953a5fa01000 CR3: 000000001ee0c000 CR4: 00000000000006f0
[    2.189639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    2.191589] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    2.192593] Call Trace:
[    2.194683]  <TASK>
[    2.195595]  ? __warn+0x78/0xc0
[    2.197592]  ? apply_returns+0x1fb/0x230
[    2.198593]  ? report_bug+0xe6/0x170
[    2.199592]  ? console_unlock+0x1a3/0x210
[    2.200594]  ? handle_bug+0x3c/0x70
[    2.201594]  ? exc_invalid_op+0x13/0x60
[    2.202594]  ? asm_exc_invalid_op+0x16/0x20
[    2.203595]  ? retbleed_return_thunk+0x7e/0x7e
[    2.205593]  ? apply_returns+0x1fb/0x230
[    2.206594]  ? apply_returns+0x1fb/0x230
[    2.207596]  alternative_instructions+0x43/0xf2
[    2.208672]  arch_cpu_finalize_init+0x28/0x47
[    2.210595]  start_kernel+0x5f9/0x6a5
[    2.211597]  secondary_startup_64_no_verify+0xe0/0xeb
[    2.213649]  </TASK>> 
Tested-by on the v1 series
#197 lore raw
In reply to Greg Kroah-Hartman

Hi Greg

Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +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/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

6.1.47-rc1 tested.

Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.

Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)

Thanks

Tested-by on the v1 series
#198 lore raw
In reply to Greg Kroah-Hartman
Quoted 5 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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.

Successfully compiled and installed bindeb-pkgs on my computer (Acer Aspire E15, Intel Core i3 Haswell). No noticeable regressions.

Signature · 1 line
An old man doll... just what I always wanted! - Clara
Tested-by Linux Kernel Functional Testing on the v1 series
#199 lore raw
In reply to Greg Kroah-Hartman
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

NOTE:
Kernel warnings noticed on x86_64 while booting the kernel. Paul E. McKenney reported this last week [1] and discussions email thread provided here.

[1] https://lore.kernel.org/lkml/4dc3d0ec-b827-4bce-8927-cfa5d837fd03@paulmck-laptop/T/

------------[ cut here ]------------
[    1.395392] missing return thunk: __ret+0x5/0x7e-__ret+0x0/0x7e: e9
f6 ff ff ff
[    1.395399] WARNING: CPU: 0 PID: 0 at
arch/x86/kernel/alternative.c:574 apply_returns+0x1c0/0x3d0
[    1.397391] Modules linked in:
[    1.398392] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.47-rc1 #1
[    1.399391] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[    1.400392] RIP: 0010:apply_returns+0x1c0/0x3d0

## Build
* kernel: 6.1.47-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.1.y
* git commit: 5165f4e9738c48a220a13b073c6ccc24824aeb74
* git describe: v6.1.46-195-g5165f4e9738c
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.46-195-g5165f4e9738c

## Test Regressions (compared to v6.1.46)

## Metric Regressions (compared to v6.1.46)

## Test Fixes (compared to v6.1.46)

## Metric Fixes (compared to v6.1.46)

## Test result summary
total: 150677, pass: 127511, fail: 4079, skip: 18915, xfail: 172

## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 147 total, 145 passed, 2 failed
* arm64: 49 total, 46 passed, 3 failed
* i386: 39 total, 37 passed, 2 failed
* mips: 30 total, 28 passed, 2 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 36 total, 34 passed, 2 failed
* riscv: 16 total, 13 passed, 3 failed
* s390: 16 total, 14 passed, 2 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 46 total, 44 passed, 2 failed

## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

#200 lore raw

Hi,

[Adding Peter Zijlstra to CC]

Quoted 27 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Quoted 6 lines

NOTE:
Kernel warnings noticed on x86_64 while booting the kernel. Paul E. McKenney reported this last week [1] and discussions email thread provided here.

[1] https://lore.kernel.org/lkml/4dc3d0ec-b827-4bce-8927-cfa5d837fd03@paulmck-laptop/T/

Seeing the same warning for the 6.1.47-rc1, which is missing 4ae68b26c3ab ("objtool/x86: Fix SRSO mess"). Unfortunately the commit will not apply cleanly to 6.1.y.

I guess we need at least as well dbcdbdfdf137 ("objtool: Rework instruction -> symbol mapping"), but not sure this is enough.

Peter, is this correct?

Regards,
Salvatore

author maintainer
#201 lore raw
Quoted 37 lines · Salvatore Bonaccorso

Hi,

[Adding Peter Zijlstra to CC]

Quoted 32 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

NOTE:
Kernel warnings noticed on x86_64 while booting the kernel. Paul E. McKenney reported this last week [1] and discussions email thread provided here.

Quoted 5 lines
Quoted 1 line

[1] https://lore.kernel.org/lkml/4dc3d0ec-b827-4bce-8927-cfa5d837fd03@paulmck-laptop/T/

Seeing the same warning for the 6.1.47-rc1, which is missing 4ae68b26c3ab ("objtool/x86: Fix SRSO mess"). Unfortunately the commit will not apply cleanly to 6.1.y.

I tried, and failed, let me try again...

Quoted 2 lines

I guess we need at least as well dbcdbdfdf137 ("objtool: Rework instruction -> symbol mapping"), but not sure this is enough.

That gets messy fast, I tried to backport all of the 6.4 objtool changes to 6.1, but ugh, the changes were highly intertwined with many other things.

greg k-h

author maintainer
#202 lore raw
Quoted 44 lines · Greg Kroah-Hartman
Quoted 37 lines · Salvatore Bonaccorso

Hi,

[Adding Peter Zijlstra to CC]

Quoted 32 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

NOTE:
Kernel warnings noticed on x86_64 while booting the kernel. Paul E. McKenney reported this last week [1] and discussions email thread provided here.

Quoted 5 lines
Quoted 1 line

[1] https://lore.kernel.org/lkml/4dc3d0ec-b827-4bce-8927-cfa5d837fd03@paulmck-laptop/T/

Seeing the same warning for the 6.1.47-rc1, which is missing 4ae68b26c3ab ("objtool/x86: Fix SRSO mess"). Unfortunately the commit will not apply cleanly to 6.1.y.

Quoted 8 lines

I tried, and failed, let me try again...

Quoted 2 lines

I guess we need at least as well dbcdbdfdf137 ("objtool: Rework instruction -> symbol mapping"), but not sure this is enough.

That gets messy fast, I tried to backport all of the 6.4 objtool changes to 6.1, but ugh, the changes were highly intertwined with many other things.

Hm, I applied that, but now I get build errors:

vmlinux.o: warning: objtool: retbleed_return_thunk(): can't find starting instruction

and

incomplete ORC unwind tables in file: vmlinux
Failed to sort kernel tables

Attached below is my backport, what did I get wrong?

thanks,

greg k-h

From 4ae68b26c3ab5a82aa271e6e9fc9b1a06e1d6b40 Mon Sep 17 00:00:00 2001
From: Peter Zijlstra <[email protected]>
Date: Mon, 14 Aug 2023 13:44:29 +0200
Subject: objtool/x86: Fix SRSO mess

From: Peter Zijlstra <[email protected]>

commit 4ae68b26c3ab5a82aa271e6e9fc9b1a06e1d6b40 upstream.

Objtool --rethunk does two things:

- it collects all (tail) call's of __x86_return_thunk and places them into .return_sites. These are typically compiler generated, but RET also emits this same.

- it fudges the validation of the __x86_return_thunk symbol; because this symbol is inside another instruction, it can't actually find the instruction pointed to by the symbol offset and gets upset.

Because these two things pertained to the same symbol, there was no pressing need to separate these two separate things.

However, alas, along comes SRSO and more crazy things to deal with appeared.

The SRSO patch itself added the following symbol names to identify as rethunk:

'srso_untrain_ret', 'srso_safe_ret' and '__ret'

Where '__ret' is the old retbleed return thunk, 'srso_safe_ret' is a new similarly embedded return thunk, and 'srso_untrain_ret' is completely unrelated to anything the above does (and was only included because of that INT3 vs UD2 issue fixed previous).

Clear things up by adding a second category for the embedded instruction thing.

Fixes fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
---
 tools/objtool/arch/x86/decode.c      |   11 +++++++----
 tools/objtool/check.c                |   24 ++++++++++++++++++++++--
 tools/objtool/include/objtool/arch.h |    1 +
 tools/objtool/include/objtool/elf.h  |    1 +
 4 files changed, 31 insertions(+), 6 deletions(-)
tools/objtool/arch/x86/decode.c +7 -4
@@ -796,8 +796,11 @@ bool arch_is_retpoline(struct symbol *sy
 
 bool arch_is_rethunk(struct symbol *sym)
 {
-	return !strcmp(sym->name, "__x86_return_thunk") ||
-	       !strcmp(sym->name, "srso_untrain_ret") ||
-	       !strcmp(sym->name, "srso_safe_ret") ||
-	       !strcmp(sym->name, "retbleed_return_thunk");
+	return !strcmp(sym->name, "__x86_return_thunk");
+}
+
+bool arch_is_embedded_insn(struct symbol *sym)
+{
+	return !strcmp(sym->name, "retbleed_return_thunk") ||
+	       !strcmp(sym->name, "srso_safe_ret");
 }
tools/objtool/check.c +22 -2
@@ -418,7 +418,7 @@ static int decode_instructions(struct ob
 		}
 
 		list_for_each_entry(func, &sec->symbol_list, list) {
-			if (func->type != STT_FUNC || func->alias != func)
+			if (func->embedded_insn || func->alias != func)
 				continue;
 
 			if (!find_insn(file, sec, func->offset)) {
@@ -1164,16 +1164,33 @@ static int add_ignore_alternatives(struc
 	return 0;
 }
 
+/*
+ * Symbols that replace INSN_CALL_DYNAMIC, every (tail) call to such a symbol
+ * will be added to the .retpoline_sites section.
+ */
 __weak bool arch_is_retpoline(struct symbol *sym)
 {
 	return false;
 }
 
+/*
+ * Symbols that replace INSN_RETURN, every (tail) call to such a symbol
+ * will be added to the .return_sites section.
+ */
 __weak bool arch_is_rethunk(struct symbol *sym)
 {
 	return false;
 }
 
+/*
+ * Symbols that are embedded inside other instructions, because sometimes crazy
+ * code exists. These are mostly ignored for validation purposes.
+ */
+__weak bool arch_is_embedded_insn(struct symbol *sym)
+{
+	return false;
+}
+
 #define NEGATIVE_RELOC	((void *)-1L)
 
 static struct reloc *insn_reloc(struct objtool_file *file, struct instruction *insn)
@@ -1437,7 +1454,7 @@ static int add_jump_destinations(struct
 			 * middle of another instruction.  Objtool only
 			 * knows about the outer instruction.
 			 */
-			if (sym && sym->return_thunk) {
+			if (sym && sym->embedded_insn) {
 				add_return_call(file, insn, false);
 				continue;
 			}
@@ -2327,6 +2344,9 @@ static int classify_symbols(struct objto
 			if (arch_is_rethunk(func))
 				func->return_thunk = true;
 
+			if (arch_is_embedded_insn(func))
+				func->embedded_insn = true;
+
 			if (!strcmp(func->name, "__fentry__"))
 				func->fentry = true;
 
tools/objtool/include/objtool/arch.h +1 -0
@@ -90,6 +90,7 @@ int arch_decode_hint_reg(u8 sp_reg, int
 
 bool arch_is_retpoline(struct symbol *sym);
 bool arch_is_rethunk(struct symbol *sym);
+bool arch_is_embedded_insn(struct symbol *sym);
 
 int arch_rewrite_retpolines(struct objtool_file *file);
 
tools/objtool/include/objtool/elf.h +1 -0
@@ -60,6 +60,7 @@ struct symbol {
 	u8 return_thunk      : 1;
 	u8 fentry            : 1;
 	u8 profiling_func    : 1;
+	u8 embedded_insn     : 1;
 	struct list_head pv_target;
 };
 
maintainer Tested-by on the v1 series
#203 lore raw
In reply to Greg Kroah-Hartman

Hello,

Quoted 5 lines · On Mon, 21 Aug 2023 21:39:39 +0200 Greg Kroah-Hartman…

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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.

Quoted 8 lines

Responses should be made by Wed, 23 Aug 2023 19:40:45 +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/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

# TODO: Cc [email protected]

This rc kernel passes DAMON functionality test[1] on my test machine. Attaching the test results summary below. Please note that I retrieved the kernel from linux-stable-rc tree[2].

[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 5165f4e9738c ("Linux 6.1.47-rc1")

Thanks,
SJ

[...]

---

# .config:1408:warning: override: reassigning to symbol CGROUPS ok 15 selftests: damon-tests: build_nomemcg.sh

# kselftest dir '/home/sjpark/damon-tests-cont/linux/tools/testing/selftests/damon-tests' is in dirty state.
# the log is at '/home/sjpark/log'.
 [32m
ok 1 selftests: damon: debugfs_attrs.sh
ok 2 selftests: damon: debugfs_schemes.sh
ok 3 selftests: damon: debugfs_target_ids.sh
ok 4 selftests: damon: debugfs_empty_targets.sh
ok 5 selftests: damon: debugfs_huge_count_read_write.sh
ok 6 selftests: damon: debugfs_duplicate_context_creation.sh
ok 7 selftests: damon: sysfs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh
ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_m68k.sh
ok 12 selftests: damon-tests: build_arm64.sh
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
 [33m
 [92mPASS [39m
_remote_run_corr.sh SUCCESS
Tested-by on the v1 series
#204 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +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/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

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

thanks,
-- Shuah

Tested-by on the v1 series
#205 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:

Signature · 1 line
Florian
Tested-by on the v1 series
#206 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.47-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-6.1.y
and the diffstat can be found below.

thanks,

greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).

#207 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

	total: 157 pass: 156 fail: 1
Failed builds:
	m68k:sun3_defconfig
Qemu test results:
	total: 521 pass: 519 fail: 2
Failed tests:
	arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
	arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

For x86 I get the same runtime warning as everyone else.

Guenter

author maintainer
#208 lore raw
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

	total: 157 pass: 156 fail: 1
Failed builds:
	m68k:sun3_defconfig
Qemu test results:
	total: 521 pass: 519 fail: 2
Failed tests:
	arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
	arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

thanks,

greg k-h

#209 lore raw
Quoted 34 lines · Greg Kroah-Hartman
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

      total: 157 pass: 156 fail: 1
Failed builds:
      m68k:sun3_defconfig
Qemu test results:
      total: 521 pass: 519 fail: 2
Failed tests:
      arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
      arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

Quoted 8 lines

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.

The Kconfigs are enabled with KFENCE.

I see this from lore
"
This is from overnight testing that hit this only in the KCSAN runs. The KASAN and non-debug runs had no trouble.

Thanx, Paul

"

steps to reproduce:
-------------------
tuxmake --runtime podman --target-arch x86_64 --toolchain gcc-13
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2UJAv99Wwi6YMltFjlQD5XRO5x4/config

Here is the links to details and build details,
[1]
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.46-195-g5165f4e9738c/testrun/19256276/suite/log-parser-boot/test/check-kernel-exception/details/

[2]
https://storage.tuxsuite.com/public/linaro/lkft/builds/2UJAv99Wwi6YMltFjlQD5XRO5x4/

[3]
https://storage.tuxsuite.com/public/linaro/lkft/builds/2UJAv99Wwi6YMltFjlQD5XRO5x4/config

- Naresh

Quoted 4 lines

thanks,

greg k-h

author maintainer
#210 lore raw
Quoted 50 lines · Naresh Kamboju
Quoted 34 lines · Greg Kroah-Hartman
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

      total: 157 pass: 156 fail: 1
Failed builds:
      m68k:sun3_defconfig
Qemu test results:
      total: 521 pass: 519 fail: 2
Failed tests:
      arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
      arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

Quoted 8 lines

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.

The Kconfigs are enabled with KFENCE.

Quoted 8 lines

I see this from lore
"
This is from overnight testing that hit this only in the KCSAN runs. The KASAN and non-debug runs had no trouble.

Thanx, Paul

"

Ok, that's good, it's not going to hit "normal" users... :)

Quoted 11 lines

steps to reproduce:
-------------------
tuxmake --runtime podman --target-arch x86_64 --toolchain gcc-13
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2UJAv99Wwi6YMltFjlQD5XRO5x4/config

Here is the links to details and build details,
[1]
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.46-195-g5165f4e9738c/testrun/19256276/suite/log-parser-boot/test/check-kernel-exception/details/

Quoted 5 lines

[2]
https://storage.tuxsuite.com/public/linaro/lkft/builds/2UJAv99Wwi6YMltFjlQD5XRO5x4/

[3]
https://storage.tuxsuite.com/public/linaro/lkft/builds/2UJAv99Wwi6YMltFjlQD5XRO5x4/config

You are going to force me to use tuxmake again, aren't you...

I'll dig into this after lunch.

greg k-h

#211 lore raw
In reply to Naresh Kamboju
Quoted 41 lines · Naresh Kamboju
Quoted 39 lines · Greg Kroah-Hartman
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

      total: 157 pass: 156 fail: 1
Failed builds:
      m68k:sun3_defconfig
Qemu test results:
      total: 521 pass: 519 fail: 2
Failed tests:
      arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
      arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Quoted 9 lines
Quoted 3 lines

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.

The Kconfigs are enabled with KFENCE.

I have KFENCE enabled as well, so it may well be that this triggers the warning. I don't see it in 6.4.y or upstream, though.

Guenter

author maintainer
#212 lore raw
Quoted 46 lines · Guenter Roeck
Quoted 45 lines · Naresh Kamboju
Quoted 42 lines · Greg Kroah-Hartman
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

      total: 157 pass: 156 fail: 1
Failed builds:
      m68k:sun3_defconfig
Qemu test results:
      total: 521 pass: 519 fail: 2
Failed tests:
      arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
      arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

Quoted 7 lines
Quoted 5 lines

It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.

The Kconfigs are enabled with KFENCE.

I have KFENCE enabled as well, so it may well be that this triggers the warning. I don't see it in 6.4.y or upstream, though.

Ok, let me rip out all the x86 and objtool patches from this release, get it out the door with the good things in there that everyone else needs, and then we can focus on this mess...

Maybe I'll just backport _all_ objtool changes to sync things up better, last time I tried that it was a maze of twisty passages, all coated in assembly...

thanks,

greg k-h

author maintainer
#213 lore raw
Quoted 55 lines · Greg Kroah-Hartman
Quoted 46 lines · Guenter Roeck
Quoted 45 lines · Naresh Kamboju
Quoted 42 lines · Greg Kroah-Hartman
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

      total: 157 pass: 156 fail: 1
Failed builds:
      m68k:sun3_defconfig
Qemu test results:
      total: 521 pass: 519 fail: 2
Failed tests:
      arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
      arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

Quoted 7 lines
Quoted 5 lines

It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.

The Kconfigs are enabled with KFENCE.

I have KFENCE enabled as well, so it may well be that this triggers the warning. I don't see it in 6.4.y or upstream, though.

Quoted 7 lines

Ok, let me rip out all the x86 and objtool patches from this release, get it out the door with the good things in there that everyone else needs, and then we can focus on this mess...

Maybe I'll just backport _all_ objtool changes to sync things up better, last time I tried that it was a maze of twisty passages, all coated in assembly...

I got lost in the maze again today, ick.

Anyway, I give up. I'm just going to push out a -rc1 with just these changes in it today, and if people are upset about the runtime warning, then they can provide a working backport of this objtool patch.

Ideally, the CPU vendor who is causing this mess will do that, as it's their issue we are spending all of this time on, not Linux's issue.

Also, oddly, I can not reproduce this problem here on my hardware at all. Maybe because it's an AMD processor? If so, makes sense, as the SRSO issue is only for Intel chips.

thanks,

greg k-h

#214 lore raw
Quoted 64 lines · Greg Kroah-Hartman
Quoted 55 lines · Greg Kroah-Hartman
Quoted 46 lines · Guenter Roeck
Quoted 45 lines · Naresh Kamboju
Quoted 42 lines · Greg Kroah-Hartman
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

      total: 157 pass: 156 fail: 1
Failed builds:
      m68k:sun3_defconfig
Qemu test results:
      total: 521 pass: 519 fail: 2
Failed tests:
      arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
      arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

Quoted 7 lines
Quoted 5 lines

It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.

The Kconfigs are enabled with KFENCE.

I have KFENCE enabled as well, so it may well be that this triggers the warning. I don't see it in 6.4.y or upstream, though.

Quoted 7 lines

Ok, let me rip out all the x86 and objtool patches from this release, get it out the door with the good things in there that everyone else needs, and then we can focus on this mess...

Maybe I'll just backport _all_ objtool changes to sync things up better, last time I tried that it was a maze of twisty passages, all coated in assembly...

Quoted 6 lines

I got lost in the maze again today, ick.

Anyway, I give up. I'm just going to push out a -rc1 with just these changes in it today, and if people are upset about the runtime warning, then they can provide a working backport of this objtool patch.

Or maybe just revert all srso patches.

Quoted 7 lines

Ideally, the CPU vendor who is causing this mess will do that, as it's their issue we are spending all of this time on, not Linux's issue.

Also, oddly, I can not reproduce this problem here on my hardware at all. Maybe because it's an AMD processor? If so, makes sense, as the SRSO issue is only for Intel chips.

Apparently I am lost in the maze as well. I am quite sure that SRSO only applies to AMD CPUs, and

arch/x86/Kconfig:config CPU_SRSO
arch/x86/Kconfig: Enable the SRSO mitigation needed on AMD Zen1-4 machines.

seems to confirm that. What am I missing ? Do you mean the warning that was supposed to be fixed with the objtool patch(es) is only seen on Intel chips ?

Thanks,
Guenter

author maintainer
#215 lore raw
Quoted 65 lines · Guenter Roeck
Quoted 64 lines · Greg Kroah-Hartman
Quoted 62 lines · Greg Kroah-Hartman
Quoted 46 lines · Guenter Roeck
Quoted 45 lines · Naresh Kamboju
Quoted 42 lines · Greg Kroah-Hartman
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build results:

      total: 157 pass: 156 fail: 1
Failed builds:
      m68k:sun3_defconfig
Qemu test results:
      total: 521 pass: 519 fail: 2
Failed tests:
      arm:fuji-bmc:aspeed_g5_defconfig:notests:mem1G:mtd128,0,8,1:net,nic:aspeed-bmc-facebook-fuji:f2fs
      arm:bletchley-bmc,fmc-model=mt25qu02g,spi-model=mt25qu02g:aspeed_g5_defconfig:notests:mem1G:mtd256:net,nic:aspeed-bmc-facebook-bletchley:f2fs

The m68k build failure is

Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaround

Quoted 6 lines

I already have KALLSYMS_EXTRA_PASS=1 enabled, so that doesn't help. Nothing to worry about. The f2fs crashes are still seen. They also happen for other architectures, so it is not just an arm problem. I'll probably just disable all f2fs testing going forward. If so I'll send a note clarifying that the lack of reported test failures doesn't mean that it works.

I'll look into this later this week, next week to resolve the f2fs stuff. I wanted to get to the other known bug fixes first.

Quoted 1 line

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

Quoted 7 lines
Quoted 5 lines

It is seen with gcc-13 and clang-17 with few extra configs. We are not booting defconfig.

The Kconfigs are enabled with KFENCE.

I have KFENCE enabled as well, so it may well be that this triggers the warning. I don't see it in 6.4.y or upstream, though.

Ok, let me rip out all the x86 and objtool patches from this release, get it out the door with the good things in there that everyone else needs, and then we can focus on this mess...

Maybe I'll just backport _all_ objtool changes to sync things up better, last time I tried that it was a maze of twisty passages, all coated in assembly...

Quoted 8 lines
Quoted 6 lines

I got lost in the maze again today, ick.

Anyway, I give up. I'm just going to push out a -rc1 with just these changes in it today, and if people are upset about the runtime warning, then they can provide a working backport of this objtool patch.

Or maybe just revert all srso patches.

Hah, I wish.

{sigh}

I've notified the patch authors about this, hopefully they can come up with something.

Quoted 11 lines
Quoted 7 lines

Ideally, the CPU vendor who is causing this mess will do that, as it's their issue we are spending all of this time on, not Linux's issue.

Also, oddly, I can not reproduce this problem here on my hardware at all. Maybe because it's an AMD processor? If so, makes sense, as the SRSO issue is only for Intel chips.

Apparently I am lost in the maze as well. I am quite sure that SRSO only applies to AMD CPUs, and

Quoted 6 lines

arch/x86/Kconfig:config CPU_SRSO
arch/x86/Kconfig: Enable the SRSO mitigation needed on AMD Zen1-4 machines.

seems to confirm that. What am I missing ? Do you mean the warning that was supposed to be fixed with the objtool patch(es) is only seen on Intel chips ?

Ah, sorry, my confusion (too many different cpu bugs lately)

This might be an issue on AMD chips, but for some reason, in running this kernel on my systems here, I have no boot warnings at all. I blamed it on them being only AMD chips. If that's not the issue then I really have no idea, sorry.

thanks,

greg k-h

#216 lore raw

On Thu, Aug 24, 2023 at 05:15:30PM +0200, Greg Kroah-Hartman wrote:
[ ... ]

Quoted 6 lines

This might be an issue on AMD chips, but for some reason, in running this kernel on my systems here, I have no boot warnings at all. I blamed it on them being only AMD chips. If that's not the issue then I really have no idea, sorry.

AFAIK it depends on the compiler used and on the enabled debug options. At some point I lost track about what exactly has to be enabled to see the problem. We see it a lot with our (ChromeOS) debug kernel testing which has various debug options enabled, to the point where we may temporarily remove the warning from the kernel to stop the noise.

Alternatively, as I had suggested earlier, we could revert all srso patches because they only seem to cause trouble. So far I have been resisting that because I am concerned that it would make things even worse (like one can not really revert a heart surgery without doing even more damage).

Guenter

author maintainer
#217 lore raw
Quoted 15 lines · Guenter Roeck

On Thu, Aug 24, 2023 at 05:15:30PM +0200, Greg Kroah-Hartman wrote:
[ ... ]

Quoted 6 lines

This might be an issue on AMD chips, but for some reason, in running this kernel on my systems here, I have no boot warnings at all. I blamed it on them being only AMD chips. If that's not the issue then I really have no idea, sorry.

AFAIK it depends on the compiler used and on the enabled debug options. At some point I lost track about what exactly has to be enabled to see the problem. We see it a lot with our (ChromeOS) debug kernel testing which has various debug options enabled, to the point where we may temporarily remove the warning from the kernel to stop the noise.

Quoted 4 lines

Alternatively, as I had suggested earlier, we could revert all srso patches because they only seem to cause trouble. So far I have been resisting that because I am concerned that it would make things even worse (like one can not really revert a heart surgery without doing even more damage).

If you don't want the feature, you can disable it at build time (I think), and I know you can disable it at runtime. But there are groups out that that "need" this, to solve a known security hole in some cpus, so it is required for them. To remove the code entirely would not be good for them, so I will say, if they are the ones that need this, they should help fix this warning, no one else should be seeing it :)

thanks,

greg k-h

#218 lore raw
In reply to Greg Kroah-Hartman
Quoted 7 lines · Greg Kroah-Hartman
Quoted 2 lines

For x86 I get the same runtime warning as everyone else.

Yeah, this is troubling...

Is it clang only? I'll dig into this today...

No, I build with gcc. More specifically, gcc 11.4.0 and binutils 2.40.

Guenter

Tested-by Sudip Mukherjee on the v1 series
#219 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build test (gcc version 12.3.1 20230625):
mips: 52 configs -> no failure
arm: 100 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure

Boot test:
x86_64: Booted on my test laptop. Warning on boot, already reported by others.
x86_64: Booted on qemu. Warning on boot, already reported by others. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]

[1]. https://openqa.qa.codethink.co.uk/tests/4765
[2]. https://openqa.qa.codethink.co.uk/tests/4773
[3]. https://openqa.qa.codethink.co.uk/tests/4772

Signature · 2 lines
Regards
Sudip
author maintainer
#220 lore raw
Quoted 29 lines · Sudip Mukherjee (Codethink)

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build test (gcc version 12.3.1 20230625):
mips: 52 configs -> no failure
arm: 100 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure

Boot test:
x86_64: Booted on my test laptop. Warning on boot, already reported by others.
x86_64: Booted on qemu. Warning on boot, already reported by others. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]

Quoted 9 lines

[1]. https://openqa.qa.codethink.co.uk/tests/4765
[2]. https://openqa.qa.codethink.co.uk/tests/4773
[3]. https://openqa.qa.codethink.co.uk/tests/4772

Signature · 2 lines
Regards
Sudip

One question about the warning on boot, all still works afterward, right? Or does the system not work?

thanks,

greg k-h

#221 lore raw
Quoted 35 lines · Greg Kroah-Hartman
Quoted 33 lines · Sudip Mukherjee (Codethink)

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build test (gcc version 12.3.1 20230625):
mips: 52 configs -> no failure
arm: 100 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure

Boot test:
x86_64: Booted on my test laptop. Warning on boot, already reported by others.
x86_64: Booted on qemu. Warning on boot, already reported by others. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]

[1]. https://openqa.qa.codethink.co.uk/tests/4765
[2]. https://openqa.qa.codethink.co.uk/tests/4773
[3]. https://openqa.qa.codethink.co.uk/tests/4772

Quoted 8 lines
Quoted 5 lines

--
Regards
Sudip

One question about the warning on boot, all still works afterward, right? Or does the system not work?

The warning while booting and root login successful and LTP and other test runs are successful.

- Naresh

#222 lore raw
Quoted 43 lines · Naresh Kamboju
Quoted 41 lines · Greg Kroah-Hartman
Quoted 38 lines · Sudip Mukherjee (Codethink)

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build test (gcc version 12.3.1 20230625):
mips: 52 configs -> no failure
arm: 100 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure

Boot test:
x86_64: Booted on my test laptop. Warning on boot, already reported by others.
x86_64: Booted on qemu. Warning on boot, already reported by others. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]

[1]. https://openqa.qa.codethink.co.uk/tests/4765
[2]. https://openqa.qa.codethink.co.uk/tests/4773
[3]. https://openqa.qa.codethink.co.uk/tests/4772

--
Regards
Sudip

Quoted 6 lines
Quoted 2 lines

One question about the warning on boot, all still works afterward, right? Or does the system not work?

The warning while booting and root login successful and LTP and other test runs are successful.

Same here.

Guenter

#223 lore raw
In reply to Greg Kroah-Hartman
Quoted 35 lines · Greg Kroah-Hartman
Quoted 33 lines · Sudip Mukherjee (Codethink)

Hi Greg,

Quoted 7 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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 Wed, 23 Aug 2023 19:40:45 +0000. Anything received after that time might be too late.

Build test (gcc version 12.3.1 20230625):
mips: 52 configs -> no failure
arm: 100 configs -> no failure
arm64: 3 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure

Boot test:
x86_64: Booted on my test laptop. Warning on boot, already reported by others.
x86_64: Booted on qemu. Warning on boot, already reported by others. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]

[1]. https://openqa.qa.codethink.co.uk/tests/4765
[2]. https://openqa.qa.codethink.co.uk/tests/4773
[3]. https://openqa.qa.codethink.co.uk/tests/4772

Quoted 8 lines
Quoted 5 lines

--
Regards
Sudip

One question about the warning on boot, all still works afterward, right? Or does the system not work?

I did not notice any problem in testing after boot. Only the warning.

Signature · 2 lines
Regards
Sudip
#224 lore raw
In reply to Greg Kroah-Hartman
Quoted 4 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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.

Fails to build for me with gcc-11/binutils 2.37 on RISC-V. The problematic patch is "riscv: Handle zicsr/zifencei issue between gcc and binutils". Can you drop that please, probably from all of your branches. It certainly affects 6.4 too & I don't personally test anything older than 6.1.

Thanks,
Conor.

#225 lore raw
Quoted 6 lines · Conor Dooley
Quoted 4 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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.

Quoted 6 lines

Fails to build for me with gcc-11/binutils 2.37 on RISC-V. The problematic patch is "riscv: Handle zicsr/zifencei issue between gcc and binutils". Can you drop that please, probably from all of your branches. It certainly affects 6.4 too & I don't personally test anything older than 6.1.

If I recall correctly, I had to be careful with combining gcc versions and binutils versions. gcc 11.4.0 combined with binutils 2.40 works fine for me. Note that this doesn't just affect riscv. loongarch and ppc are quite notorious for that as well.

Guenter

author maintainer
#226 lore raw
In reply to Conor Dooley
Quoted 11 lines · Conor Dooley
Quoted 4 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.1.47 release. There are 194 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.

Fails to build for me with gcc-11/binutils 2.37 on RISC-V. The problematic patch is "riscv: Handle zicsr/zifencei issue between gcc and binutils". Can you drop that please, probably from all of your branches. It certainly affects 6.4 too & I don't personally test anything older than 6.1.

I've dropped that patch now from all trees, thanks.

greg k-h