--- /dev/null
+From d96e8f2b4910f5af3d11dd37cb19459bda141e09 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 1 Nov 2021 19:36:30 -0500
+Subject: ARM: socfpga: dts: fix qspi node compatible
+
+From: Dinh Nguyen <dinguyen@kernel.org>
+
+[ Upstream commit cb25b11943cbcc5a34531129952870420f8be858 ]
+
+The QSPI flash node needs to have the required "jedec,spi-nor" in the
+compatible string.
+
+Fixes: 1df99da8953 ("ARM: dts: socfpga: Enable QSPI in Arria10 devkit")
+Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts | 2 +-
+ arch/arm/boot/dts/socfpga_arria5_socdk.dts | 2 +-
+ arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 2 +-
+ arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 2 +-
+ arch/arm/boot/dts/socfpga_cyclone5_socrates.dts | 2 +-
+ arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 2 +-
+ arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts | 4 ++--
+ 7 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts b/arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts
+index 2b645642b9352..2a745522404d6 100644
+--- a/arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts
++++ b/arch/arm/boot/dts/socfpga_arria10_socdk_qspi.dts
+@@ -12,7 +12,7 @@ &qspi {
+ flash0: n25q00@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q00aa";
++ compatible = "micron,mt25qu02g", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+
+diff --git a/arch/arm/boot/dts/socfpga_arria5_socdk.dts b/arch/arm/boot/dts/socfpga_arria5_socdk.dts
+index 90e676e7019f2..1b02d46496a85 100644
+--- a/arch/arm/boot/dts/socfpga_arria5_socdk.dts
++++ b/arch/arm/boot/dts/socfpga_arria5_socdk.dts
+@@ -119,7 +119,7 @@ &qspi {
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q256a";
++ compatible = "micron,n25q256a", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+
+diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+index 6f138b2b26163..51bb436784e24 100644
+--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
++++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+@@ -124,7 +124,7 @@ &qspi {
+ flash0: n25q00@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q00";
++ compatible = "micron,mt25qu02g", "jedec,spi-nor";
+ reg = <0>; /* chip select */
+ spi-max-frequency = <100000000>;
+
+diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+index c155ff02eb6e0..cae9ddd5ed38b 100644
+--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
++++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+@@ -169,7 +169,7 @@ &qspi {
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q00";
++ compatible = "micron,mt25qu02g", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+
+diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts b/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts
+index 8d5d3996f6f27..ca18b959e6559 100644
+--- a/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts
++++ b/arch/arm/boot/dts/socfpga_cyclone5_socrates.dts
+@@ -80,7 +80,7 @@ &qspi {
+ flash: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q256a";
++ compatible = "micron,n25q256a", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+ m25p,fast-read;
+diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
+index 99a71757cdf46..3f7aa7bf0863a 100644
+--- a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
++++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
+@@ -116,7 +116,7 @@ &qspi {
+ flash0: n25q512a@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q512a";
++ compatible = "micron,n25q512a", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+
+diff --git a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+index a060718758b67..25874e1b9c829 100644
+--- a/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
++++ b/arch/arm/boot/dts/socfpga_cyclone5_vining_fpga.dts
+@@ -224,7 +224,7 @@ &qspi {
+ n25q128@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q128";
++ compatible = "micron,n25q128", "jedec,spi-nor";
+ reg = <0>; /* chip select */
+ spi-max-frequency = <100000000>;
+ m25p,fast-read;
+@@ -241,7 +241,7 @@ n25q128@0 {
+ n25q00@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+- compatible = "n25q00";
++ compatible = "micron,mt25qu02g", "jedec,spi-nor";
+ reg = <1>; /* chip select */
+ spi-max-frequency = <100000000>;
+ m25p,fast-read;
+--
+2.33.0
+
--- /dev/null
+From 8db384e8991cd679ad009d636b4be78a5f9f149f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 27 Oct 2021 16:37:25 +0200
+Subject: arm64: dts: rockchip: fix audio-supply for Rock Pi 4
+
+From: Alex Bee <knaerzche@gmail.com>
+
+[ Upstream commit 8240e87f16d17a9592c9d67857a3dcdbcb98f10d ]
+
+As stated in the schematics [1] and [2] P5 the APIO5 domain is supplied
+by RK808-D Buck4, which in our case vcc1v8_codec - i.e. a 1.8 V regulator.
+
+Currently only white noise comes from the ES8316's output, which - for
+whatever reason - came up only after the the correct switch from i2s0_8ch_bus
+to i2s0_2ch_bus for i2s0's pinctrl was done.
+
+Fix this by setting the correct regulator for audio-supply.
+
+[1] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi4_v13_sch_20181112.pdf
+[2] https://dl.radxa.com/rockpi4/docs/hw/rockpi4/rockpi_4c_v12_sch_20200620.pdf
+
+Fixes: 1b5715c602fd ("arm64: dts: rockchip: add ROCK Pi 4 DTS support")
+Signed-off-by: Alex Bee <knaerzche@gmail.com>
+Link: https://lore.kernel.org/r/20211027143726.165809-1-knaerzche@gmail.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+index 678a336010bf8..f121203081b97 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi
+@@ -459,7 +459,7 @@ &io_domains {
+ status = "okay";
+
+ bt656-supply = <&vcc_3v0>;
+- audio-supply = <&vcc_3v0>;
++ audio-supply = <&vcc1v8_codec>;
+ sdmmc-supply = <&vcc_sdio>;
+ gpio1830-supply = <&vcc_3v0>;
+ };
+--
+2.33.0
+
--- /dev/null
+From 602dff9a80cef80c07020aa92b801c2a0e7d3780 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Nov 2021 18:29:07 +0000
+Subject: arm64: dts: rockchip: fix rk3308-roc-cc vcc-sd supply
+
+From: John Keeping <john@metanate.com>
+
+[ Upstream commit 772fb46109f635dd75db20c86b7eaf48efa46cef ]
+
+Correct a typo in the vin-supply property. The input supply is
+always-on, so this mistake doesn't affect whether the supply is actually
+enabled correctly.
+
+Fixes: 4403e1237be3 ("arm64: dts: rockchip: Add devicetree for board roc-rk3308-cc")
+Signed-off-by: John Keeping <john@metanate.com>
+Link: https://lore.kernel.org/r/20211102182908.3409670-2-john@metanate.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts
+index bce6f8b7db436..fbcb9531cc70d 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3308-roc-cc.dts
+@@ -91,7 +91,7 @@ vcc_sd: vcc-sd {
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+- vim-supply = <&vcc_io>;
++ vin-supply = <&vcc_io>;
+ };
+
+ vdd_core: vdd-core {
+--
+2.33.0
+
--- /dev/null
+From d82d148b49d1dc1b20a97b548569ea0ceddae7b1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Nov 2021 18:29:08 +0000
+Subject: arm64: dts: rockchip: fix rk3399-leez-p710 vcc3v3-lan supply
+
+From: John Keeping <john@metanate.com>
+
+[ Upstream commit 2b454a90e2ccdd6e03f88f930036da4df577be76 ]
+
+Correct a typo in the vin-supply property. The input supply is
+always-on, so this mistake doesn't affect whether the supply is actually
+enabled correctly.
+
+Fixes: fc702ed49a86 ("arm64: dts: rockchip: Add dts for Leez RK3399 P710 SBC")
+Signed-off-by: John Keeping <john@metanate.com>
+Link: https://lore.kernel.org/r/20211102182908.3409670-3-john@metanate.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
+index 1fa80ac15464b..88984b5e67b6e 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-leez-p710.dts
+@@ -49,7 +49,7 @@ vcc3v3_lan: vcc3v3-lan {
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+- vim-supply = <&vcc3v3_sys>;
++ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+--
+2.33.0
+
--- /dev/null
+From 6bee14ed4d52233aea0b0333cafeabb900c68504 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 15 Nov 2021 16:33:21 +0800
+Subject: arm64: dts: rockchip: remove mmc-hs400-enhanced-strobe from
+ rk3399-khadas-edge
+
+From: Artem Lapkin <email2tema@gmail.com>
+
+[ Upstream commit 6dd0053683804427529ef3523f7872f473440a19 ]
+
+Remove mmc-hs400-enhanced-strobe from the rk3399-khadas-edge dts to
+improve compatibility with a wider range of eMMC chips.
+
+Before (BJTD4R 29.1 GiB):
+
+[ 7.001493] mmc2: CQHCI version 5.10
+[ 7.027971] mmc2: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA
+.......
+[ 7.207086] mmc2: mmc_select_hs400es failed, error -110
+[ 7.207129] mmc2: error -110 whilst initialising MMC card
+[ 7.308893] mmc2: mmc_select_hs400es failed, error -110
+[ 7.308921] mmc2: error -110 whilst initialising MMC card
+[ 7.427524] mmc2: mmc_select_hs400es failed, error -110
+[ 7.427546] mmc2: error -110 whilst initialising MMC card
+[ 7.590993] mmc2: mmc_select_hs400es failed, error -110
+[ 7.591012] mmc2: error -110 whilst initialising MMC card
+
+After:
+
+[ 6.960785] mmc2: CQHCI version 5.10
+[ 6.984672] mmc2: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA
+[ 7.175021] mmc2: Command Queue Engine enabled
+[ 7.175053] mmc2: new HS400 MMC card at address 0001
+[ 7.175808] mmcblk2: mmc2:0001 BJTD4R 29.1 GiB
+[ 7.176033] mmcblk2boot0: mmc2:0001 BJTD4R 4.00 MiB
+[ 7.176245] mmcblk2boot1: mmc2:0001 BJTD4R 4.00 MiB
+[ 7.176495] mmcblk2rpmb: mmc2:0001 BJTD4R 4.00 MiB, chardev (242:0)
+
+Fixes: c2aacceedc86 ("arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards")
+Signed-off-by: Artem Lapkin <art@khadas.com>
+Link: https://lore.kernel.org/r/20211115083321.2627461-1-art@khadas.com
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
+index 635afdd99122f..2c644ac1f84b9 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399-khadas-edge.dtsi
+@@ -699,7 +699,6 @@ &sdmmc {
+ &sdhci {
+ bus-width = <8>;
+ mmc-hs400-1_8v;
+- mmc-hs400-enhanced-strobe;
+ non-removable;
+ status = "okay";
+ };
+--
+2.33.0
+
--- /dev/null
+From 46393a2f3428058e67df2837453375ab4bcc77c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 16 Dec 2021 11:16:30 -0800
+Subject: bpf, selftests: Fix racing issue in btf_skc_cls_ingress test
+
+From: Martin KaFai Lau <kafai@fb.com>
+
+[ Upstream commit c2fcbf81c332b42382a0c439bfe2414a241e4f5b ]
+
+The libbpf CI reported occasional failure in btf_skc_cls_ingress:
+
+ test_syncookie:FAIL:Unexpected syncookie states gen_cookie:80326634 recv_cookie:0
+ bpf prog error at line 97
+
+"error at line 97" means the bpf prog cannot find the listening socket
+when the final ack is received. It then skipped processing
+the syncookie in the final ack which then led to "recv_cookie:0".
+
+The problem is the userspace program did not do accept() and went
+ahead to close(listen_fd) before the kernel (and the bpf prog) had
+a chance to process the final ack.
+
+The fix is to add accept() call so that the userspace will wait for
+the kernel to finish processing the final ack first before close()-ing
+everything.
+
+Fixes: 9a856cae2217 ("bpf: selftest: Add test_btf_skc_cls_ingress")
+Reported-by: Andrii Nakryiko <andrii@kernel.org>
+Signed-off-by: Martin KaFai Lau <kafai@fb.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Link: https://lore.kernel.org/bpf/20211216191630.466151-1-kafai@fb.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../bpf/prog_tests/btf_skc_cls_ingress.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/tools/testing/selftests/bpf/prog_tests/btf_skc_cls_ingress.c b/tools/testing/selftests/bpf/prog_tests/btf_skc_cls_ingress.c
+index 86ccf37e26b3f..d16fd888230a5 100644
+--- a/tools/testing/selftests/bpf/prog_tests/btf_skc_cls_ingress.c
++++ b/tools/testing/selftests/bpf/prog_tests/btf_skc_cls_ingress.c
+@@ -90,7 +90,7 @@ static void print_err_line(void)
+
+ static void test_conn(void)
+ {
+- int listen_fd = -1, cli_fd = -1, err;
++ int listen_fd = -1, cli_fd = -1, srv_fd = -1, err;
+ socklen_t addrlen = sizeof(srv_sa6);
+ int srv_port;
+
+@@ -112,6 +112,10 @@ static void test_conn(void)
+ if (CHECK_FAIL(cli_fd == -1))
+ goto done;
+
++ srv_fd = accept(listen_fd, NULL, NULL);
++ if (CHECK_FAIL(srv_fd == -1))
++ goto done;
++
+ if (CHECK(skel->bss->listen_tp_sport != srv_port ||
+ skel->bss->req_sk_sport != srv_port,
+ "Unexpected sk src port",
+@@ -134,11 +138,13 @@ static void test_conn(void)
+ close(listen_fd);
+ if (cli_fd != -1)
+ close(cli_fd);
++ if (srv_fd != -1)
++ close(srv_fd);
+ }
+
+ static void test_syncookie(void)
+ {
+- int listen_fd = -1, cli_fd = -1, err;
++ int listen_fd = -1, cli_fd = -1, srv_fd = -1, err;
+ socklen_t addrlen = sizeof(srv_sa6);
+ int srv_port;
+
+@@ -161,6 +167,10 @@ static void test_syncookie(void)
+ if (CHECK_FAIL(cli_fd == -1))
+ goto done;
+
++ srv_fd = accept(listen_fd, NULL, NULL);
++ if (CHECK_FAIL(srv_fd == -1))
++ goto done;
++
+ if (CHECK(skel->bss->listen_tp_sport != srv_port,
+ "Unexpected tp src port",
+ "listen_tp_sport:%u expected:%u\n",
+@@ -188,6 +198,8 @@ static void test_syncookie(void)
+ close(listen_fd);
+ if (cli_fd != -1)
+ close(cli_fd);
++ if (srv_fd != -1)
++ close(srv_fd);
+ }
+
+ struct test {
+--
+2.33.0
+
--- /dev/null
+From 77339a6a9a6f5f8e10c4bcf8c6f2df3d63837a7c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Nov 2021 22:22:12 +0800
+Subject: ceph: fix duplicate increment of opened_inodes metric
+
+From: Hu Weiwen <sehuww@mail.scut.edu.cn>
+
+[ Upstream commit 973e5245637accc4002843f6b888495a6a7762bc ]
+
+opened_inodes is incremented twice when the same inode is opened twice
+with O_RDONLY and O_WRONLY respectively.
+
+To reproduce, run this python script, then check the metrics:
+
+import os
+for _ in range(10000):
+ fd_r = os.open('a', os.O_RDONLY)
+ fd_w = os.open('a', os.O_WRONLY)
+ os.close(fd_r)
+ os.close(fd_w)
+
+Fixes: 1dd8d4708136 ("ceph: metrics for opened files, pinned caps and opened inodes")
+Signed-off-by: Hu Weiwen <sehuww@mail.scut.edu.cn>
+Reviewed-by: Xiubo Li <xiubli@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/ceph/caps.c | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
+index 676f551953060..d3f67271d3c72 100644
+--- a/fs/ceph/caps.c
++++ b/fs/ceph/caps.c
+@@ -4359,7 +4359,7 @@ void ceph_get_fmode(struct ceph_inode_info *ci, int fmode, int count)
+ {
+ struct ceph_mds_client *mdsc = ceph_sb_to_mdsc(ci->vfs_inode.i_sb);
+ int bits = (fmode << 1) | 1;
+- bool is_opened = false;
++ bool already_opened = false;
+ int i;
+
+ if (count == 1)
+@@ -4367,19 +4367,19 @@ void ceph_get_fmode(struct ceph_inode_info *ci, int fmode, int count)
+
+ spin_lock(&ci->i_ceph_lock);
+ for (i = 0; i < CEPH_FILE_MODE_BITS; i++) {
+- if (bits & (1 << i))
+- ci->i_nr_by_mode[i] += count;
+-
+ /*
+- * If any of the mode ref is larger than 1,
++ * If any of the mode ref is larger than 0,
+ * that means it has been already opened by
+ * others. Just skip checking the PIN ref.
+ */
+- if (i && ci->i_nr_by_mode[i] > 1)
+- is_opened = true;
++ if (i && ci->i_nr_by_mode[i])
++ already_opened = true;
++
++ if (bits & (1 << i))
++ ci->i_nr_by_mode[i] += count;
+ }
+
+- if (!is_opened)
++ if (!already_opened)
+ percpu_counter_inc(&mdsc->metric.opened_inodes);
+ spin_unlock(&ci->i_ceph_lock);
+ }
+--
+2.33.0
+
--- /dev/null
+From 6be3cb4834b11bf358927277c3addb130bcedce2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 30 Nov 2021 19:20:34 +0800
+Subject: ceph: initialize pathlen variable in reconnect_caps_cb
+
+From: Xiubo Li <xiubli@redhat.com>
+
+[ Upstream commit ee2a095d3b24f300a5e11944d208801e928f108c ]
+
+The smatch static checker warned about an uninitialized symbol usage in
+this function, in the case where ceph_mdsc_build_path returns an error.
+
+It turns out that that case is harmless, but it just looks sketchy.
+Initialize the variable at declaration time, and remove the unneeded
+setting of it later.
+
+Fixes: a33f6432b3a6 ("ceph: encode inodes' parent/d_name in cap reconnect message")
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Xiubo Li <xiubli@redhat.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/ceph/mds_client.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
+index 76e347a8cf088..981a915906314 100644
+--- a/fs/ceph/mds_client.c
++++ b/fs/ceph/mds_client.c
+@@ -3696,7 +3696,7 @@ static int reconnect_caps_cb(struct inode *inode, struct ceph_cap *cap,
+ struct ceph_pagelist *pagelist = recon_state->pagelist;
+ struct dentry *dentry;
+ char *path;
+- int pathlen, err;
++ int pathlen = 0, err;
+ u64 pathbase;
+ u64 snap_follows;
+
+@@ -3716,7 +3716,6 @@ static int reconnect_caps_cb(struct inode *inode, struct ceph_cap *cap,
+ }
+ } else {
+ path = NULL;
+- pathlen = 0;
+ pathbase = 0;
+ }
+
+--
+2.33.0
+
--- /dev/null
+From dd6b711dd4cf6245a8a70839f2f88dac219ad915 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 8 Nov 2021 20:34:38 -0800
+Subject: clk: Don't parent clks until the parent is fully registered
+
+From: Mike Tipton <quic_mdtipton@quicinc.com>
+
+[ Upstream commit 54baf56eaa40aa5cdcd02b3c20d593e4e1211220 ]
+
+Before commit fc0c209c147f ("clk: Allow parents to be specified without
+string names") child clks couldn't find their parent until the parent
+clk was added to a list in __clk_core_init(). After that commit, child
+clks can reference their parent clks directly via a clk_hw pointer, or
+they can lookup that clk_hw pointer via DT if the parent clk is
+registered with an OF clk provider.
+
+The common clk framework treats hw->core being non-NULL as "the clk is
+registered" per the logic within clk_core_fill_parent_index():
+
+ parent = entry->hw->core;
+ /*
+ * We have a direct reference but it isn't registered yet?
+ * Orphan it and let clk_reparent() update the orphan status
+ * when the parent is registered.
+ */
+ if (!parent)
+
+Therefore we need to be extra careful to not set hw->core until the clk
+is fully registered with the clk framework. Otherwise we can get into a
+situation where a child finds a parent clk and we move the child clk off
+the orphan list when the parent isn't actually registered, wrecking our
+enable accounting and breaking critical clks.
+
+Consider the following scenario:
+
+ CPU0 CPU1
+ ---- ----
+ struct clk_hw clkBad;
+ struct clk_hw clkA;
+
+ clkA.init.parent_hws = { &clkBad };
+
+ clk_hw_register(&clkA) clk_hw_register(&clkBad)
+ ... __clk_register()
+ hw->core = core
+ ...
+ __clk_register()
+ __clk_core_init()
+ clk_prepare_lock()
+ __clk_init_parent()
+ clk_core_get_parent_by_index()
+ clk_core_fill_parent_index()
+ if (entry->hw) {
+ parent = entry->hw->core;
+
+At this point, 'parent' points to clkBad even though clkBad hasn't been
+fully registered yet. Ouch! A similar problem can happen if a clk
+controller registers orphan clks that are referenced in the DT node of
+another clk controller.
+
+Let's fix all this by only setting the hw->core pointer underneath the
+clk prepare lock in __clk_core_init(). This way we know that
+clk_core_fill_parent_index() can't see hw->core be non-NULL until the
+clk is fully registered.
+
+Fixes: fc0c209c147f ("clk: Allow parents to be specified without string names")
+Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
+Link: https://lore.kernel.org/r/20211109043438.4639-1-quic_mdtipton@quicinc.com
+[sboyd@kernel.org: Reword commit text, update comment]
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clk/clk.c | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
+index 61c78714c0957..515ef39c4610c 100644
+--- a/drivers/clk/clk.c
++++ b/drivers/clk/clk.c
+@@ -3389,6 +3389,14 @@ static int __clk_core_init(struct clk_core *core)
+
+ clk_prepare_lock();
+
++ /*
++ * Set hw->core after grabbing the prepare_lock to synchronize with
++ * callers of clk_core_fill_parent_index() where we treat hw->core
++ * being NULL as the clk not being registered yet. This is crucial so
++ * that clks aren't parented until their parent is fully registered.
++ */
++ core->hw->core = core;
++
+ ret = clk_pm_runtime_get(core);
+ if (ret)
+ goto unlock;
+@@ -3557,8 +3565,10 @@ static int __clk_core_init(struct clk_core *core)
+ out:
+ clk_pm_runtime_put(core);
+ unlock:
+- if (ret)
++ if (ret) {
+ hlist_del_init(&core->child_node);
++ core->hw->core = NULL;
++ }
+
+ clk_prepare_unlock();
+
+@@ -3804,7 +3814,6 @@ __clk_register(struct device *dev, struct device_node *np, struct clk_hw *hw)
+ core->num_parents = init->num_parents;
+ core->min_rate = 0;
+ core->max_rate = ULONG_MAX;
+- hw->core = core;
+
+ ret = clk_core_populate_parent_map(core, init);
+ if (ret)
+@@ -3822,7 +3831,7 @@ __clk_register(struct device *dev, struct device_node *np, struct clk_hw *hw)
+ goto fail_create_clk;
+ }
+
+- clk_core_link_consumer(hw->core, hw->clk);
++ clk_core_link_consumer(core, hw->clk);
+
+ ret = __clk_core_init(core);
+ if (!ret)
+--
+2.33.0
+
--- /dev/null
+From eb4001794b13ee0c4a2473b7f80c9b36050337c2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 25 Nov 2021 15:44:38 +0000
+Subject: dmaengine: st_fdma: fix MODULE_ALIAS
+
+From: Alyssa Ross <hi@alyssa.is>
+
+[ Upstream commit 822c9f2b833c53fc67e8adf6f63ecc3ea24d502c ]
+
+modprobe can't handle spaces in aliases.
+
+Fixes: 6b4cd727eaf1 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support")
+Signed-off-by: Alyssa Ross <hi@alyssa.is>
+Link: https://lore.kernel.org/r/20211125154441.2626214-1-hi@alyssa.is
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/dma/st_fdma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
+index 962b6e05287b5..d95c421877fb7 100644
+--- a/drivers/dma/st_fdma.c
++++ b/drivers/dma/st_fdma.c
+@@ -874,4 +874,4 @@ MODULE_LICENSE("GPL v2");
+ MODULE_DESCRIPTION("STMicroelectronics FDMA engine driver");
+ MODULE_AUTHOR("Ludovic.barre <Ludovic.barre@st.com>");
+ MODULE_AUTHOR("Peter Griffin <peter.griffin@linaro.org>");
+-MODULE_ALIAS("platform: " DRIVER_NAME);
++MODULE_ALIAS("platform:" DRIVER_NAME);
+--
+2.33.0
+
--- /dev/null
+From 97087926209b87c5cbbeceadd5cdbce4413d0d84 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Dec 2021 15:25:54 +0800
+Subject: drm/amd/pm: fix a potential gpu_metrics_table memory leak
+
+From: Lang Yu <lang.yu@amd.com>
+
+[ Upstream commit aa464957f7e660abd554f2546a588f6533720e21 ]
+
+Memory is allocated for gpu_metrics_table in renoir_init_smc_tables(),
+but not freed in int smu_v12_0_fini_smc_tables(). Free it!
+
+Fixes: 95868b85764a ("drm/amd/powerplay: add Renoir support for gpu metrics export")
+
+Signed-off-by: Lang Yu <lang.yu@amd.com>
+Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c
+index 7907c9e0b5dec..b938fd12da4d5 100644
+--- a/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c
++++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/smu_v12_0.c
+@@ -187,6 +187,9 @@ int smu_v12_0_fini_smc_tables(struct smu_context *smu)
+ kfree(smu_table->watermarks_table);
+ smu_table->watermarks_table = NULL;
+
++ kfree(smu_table->gpu_metrics_table);
++ smu_table->gpu_metrics_table = NULL;
++
+ return 0;
+ }
+
+--
+2.33.0
+
--- /dev/null
+From c54e0e5065d7c4bd0f697ae3c10ec1741496fc64 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Dec 2021 09:41:26 +0800
+Subject: drm/ast: potential dereference of null pointer
+
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+
+[ Upstream commit fea3fdf975dd9f3e5248afaab8fe023db313f005 ]
+
+The return value of kzalloc() needs to be checked.
+To avoid use of null pointer '&ast_state->base' in case of the
+failure of alloc.
+
+Fixes: f0adbc382b8b ("drm/ast: Allocate initial CRTC state of the correct size")
+Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20211214014126.2211535-1-jiasheng@iscas.ac.cn
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/ast/ast_mode.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
+index a3c2f76668abe..d27f2840b9555 100644
+--- a/drivers/gpu/drm/ast/ast_mode.c
++++ b/drivers/gpu/drm/ast/ast_mode.c
+@@ -857,7 +857,10 @@ static void ast_crtc_reset(struct drm_crtc *crtc)
+ if (crtc->state)
+ crtc->funcs->atomic_destroy_state(crtc, crtc->state);
+
+- __drm_atomic_helper_crtc_reset(crtc, &ast_state->base);
++ if (ast_state)
++ __drm_atomic_helper_crtc_reset(crtc, &ast_state->base);
++ else
++ __drm_atomic_helper_crtc_reset(crtc, NULL);
+ }
+
+ static struct drm_crtc_state *
+--
+2.33.0
+
--- /dev/null
+From 21debc4a09821e73bf37118f6a4a584dc958a540 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Dec 2021 15:46:04 +0100
+Subject: flow_offload: return EOPNOTSUPP for the unsupported mpls action type
+
+From: Baowen Zheng <baowen.zheng@corigine.com>
+
+[ Upstream commit 166b6a46b78bf8b9559a6620c3032f9fe492e082 ]
+
+We need to return EOPNOTSUPP for the unsupported mpls action type when
+setup the flow action.
+
+In the original implement, we will return 0 for the unsupported mpls
+action type, actually we do not setup it and the following actions
+to the flow action entry.
+
+Fixes: 9838b20a7fb2 ("net: sched: take rtnl lock in tc_setup_flow_action()")
+Signed-off-by: Baowen Zheng <baowen.zheng@corigine.com>
+Signed-off-by: Simon Horman <simon.horman@corigine.com>
+Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/cls_api.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
+index 8073657a0fd25..cb1331b357451 100644
+--- a/net/sched/cls_api.c
++++ b/net/sched/cls_api.c
+@@ -3703,6 +3703,7 @@ int tc_setup_flow_action(struct flow_action *flow_action,
+ entry->mpls_mangle.ttl = tcf_mpls_ttl(act);
+ break;
+ default:
++ err = -EOPNOTSUPP;
+ goto err_out_locked;
+ }
+ } else if (is_tcf_skbedit_ptype(act)) {
+--
+2.33.0
+
--- /dev/null
+From 6f2eb39d91898382c1367659805a14f28a5dbc8a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 25 Nov 2021 18:33:16 -0800
+Subject: hv: utils: add PTP_1588_CLOCK to Kconfig to fix build
+
+From: Randy Dunlap <rdunlap@infradead.org>
+
+[ Upstream commit 1dc2f2b81a6a9895da59f3915760f6c0c3074492 ]
+
+The hyperv utilities use PTP clock interfaces and should depend a
+a kconfig symbol such that they will be built as a loadable module or
+builtin so that linker errors do not happen.
+
+Prevents these build errors:
+
+ld: drivers/hv/hv_util.o: in function `hv_timesync_deinit':
+hv_util.c:(.text+0x37d): undefined reference to `ptp_clock_unregister'
+ld: drivers/hv/hv_util.o: in function `hv_timesync_init':
+hv_util.c:(.text+0x738): undefined reference to `ptp_clock_register'
+
+Fixes: 3716a49a81ba ("hv_utils: implement Hyper-V PTP source")
+Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
+Reported-by: kernel test robot <lkp@intel.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: "K. Y. Srinivasan" <kys@microsoft.com>
+Cc: Haiyang Zhang <haiyangz@microsoft.com>
+Cc: Stephen Hemminger <sthemmin@microsoft.com>
+Cc: Wei Liu <wei.liu@kernel.org>
+Cc: Dexuan Cui <decui@microsoft.com>
+Cc: linux-hyperv@vger.kernel.org
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Reviewed-by: Michael Kelley <mikelley@microsoft.com>
+Link: https://lore.kernel.org/r/20211126023316.25184-1-rdunlap@infradead.org
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hv/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
+index 79e5356a737a2..210e532ac277f 100644
+--- a/drivers/hv/Kconfig
++++ b/drivers/hv/Kconfig
+@@ -17,6 +17,7 @@ config HYPERV_TIMER
+ config HYPERV_UTILS
+ tristate "Microsoft Hyper-V Utilities driver"
+ depends on HYPERV && CONNECTOR && NLS
++ depends on PTP_1588_CLOCK_OPTIONAL
+ help
+ Select this option to enable the Hyper-V Utilities.
+
+--
+2.33.0
+
--- /dev/null
+From 0b02d1ab17439caf14b108e49fc669eb269a6192 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 31 Aug 2021 13:16:35 +0200
+Subject: igb: Fix removal of unicast MAC filters of VFs
+
+From: Karen Sornek <karen.sornek@intel.com>
+
+[ Upstream commit 584af82154f56e6b2740160fcc84a2966d969e15 ]
+
+Move checking condition of VF MAC filter before clearing
+or adding MAC filter to VF to prevent potential blackout caused
+by removal of necessary and working VF's MAC filter.
+
+Fixes: 1b8b062a99dc ("igb: add VF trust infrastructure")
+Signed-off-by: Karen Sornek <karen.sornek@intel.com>
+Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/igb/igb_main.c | 28 +++++++++++------------
+ 1 file changed, 14 insertions(+), 14 deletions(-)
+
+diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
+index d5432d1448c05..1662c0985eca4 100644
+--- a/drivers/net/ethernet/intel/igb/igb_main.c
++++ b/drivers/net/ethernet/intel/igb/igb_main.c
+@@ -7654,6 +7654,20 @@ static int igb_set_vf_mac_filter(struct igb_adapter *adapter, const int vf,
+ struct vf_mac_filter *entry = NULL;
+ int ret = 0;
+
++ if ((vf_data->flags & IGB_VF_FLAG_PF_SET_MAC) &&
++ !vf_data->trusted) {
++ dev_warn(&pdev->dev,
++ "VF %d requested MAC filter but is administratively denied\n",
++ vf);
++ return -EINVAL;
++ }
++ if (!is_valid_ether_addr(addr)) {
++ dev_warn(&pdev->dev,
++ "VF %d attempted to set invalid MAC filter\n",
++ vf);
++ return -EINVAL;
++ }
++
+ switch (info) {
+ case E1000_VF_MAC_FILTER_CLR:
+ /* remove all unicast MAC filters related to the current VF */
+@@ -7667,20 +7681,6 @@ static int igb_set_vf_mac_filter(struct igb_adapter *adapter, const int vf,
+ }
+ break;
+ case E1000_VF_MAC_FILTER_ADD:
+- if ((vf_data->flags & IGB_VF_FLAG_PF_SET_MAC) &&
+- !vf_data->trusted) {
+- dev_warn(&pdev->dev,
+- "VF %d requested MAC filter but is administratively denied\n",
+- vf);
+- return -EINVAL;
+- }
+- if (!is_valid_ether_addr(addr)) {
+- dev_warn(&pdev->dev,
+- "VF %d attempted to set invalid MAC filter\n",
+- vf);
+- return -EINVAL;
+- }
+-
+ /* try to find empty slot in the list */
+ list_for_each(pos, &adapter->vf_macs.l) {
+ entry = list_entry(pos, struct vf_mac_filter, l);
+--
+2.33.0
+
--- /dev/null
+From 498402ab183fa69db42df4a841c433fcc92ee61a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 13 Nov 2021 11:42:34 +0800
+Subject: igbvf: fix double free in `igbvf_probe`
+
+From: Letu Ren <fantasquex@gmail.com>
+
+[ Upstream commit b6d335a60dc624c0d279333b22c737faa765b028 ]
+
+In `igbvf_probe`, if register_netdev() fails, the program will go to
+label err_hw_init, and then to label err_ioremap. In free_netdev() which
+is just below label err_ioremap, there is `list_for_each_entry_safe` and
+`netif_napi_del` which aims to delete all entries in `dev->napi_list`.
+The program has added an entry `adapter->rx_ring->napi` which is added by
+`netif_napi_add` in igbvf_alloc_queues(). However, adapter->rx_ring has
+been freed below label err_hw_init. So this a UAF.
+
+In terms of how to patch the problem, we can refer to igbvf_remove() and
+delete the entry before `adapter->rx_ring`.
+
+The KASAN logs are as follows:
+
+[ 35.126075] BUG: KASAN: use-after-free in free_netdev+0x1fd/0x450
+[ 35.127170] Read of size 8 at addr ffff88810126d990 by task modprobe/366
+[ 35.128360]
+[ 35.128643] CPU: 1 PID: 366 Comm: modprobe Not tainted 5.15.0-rc2+ #14
+[ 35.129789] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
+[ 35.131749] Call Trace:
+[ 35.132199] dump_stack_lvl+0x59/0x7b
+[ 35.132865] print_address_description+0x7c/0x3b0
+[ 35.133707] ? free_netdev+0x1fd/0x450
+[ 35.134378] __kasan_report+0x160/0x1c0
+[ 35.135063] ? free_netdev+0x1fd/0x450
+[ 35.135738] kasan_report+0x4b/0x70
+[ 35.136367] free_netdev+0x1fd/0x450
+[ 35.137006] igbvf_probe+0x121d/0x1a10 [igbvf]
+[ 35.137808] ? igbvf_vlan_rx_add_vid+0x100/0x100 [igbvf]
+[ 35.138751] local_pci_probe+0x13c/0x1f0
+[ 35.139461] pci_device_probe+0x37e/0x6c0
+[ 35.165526]
+[ 35.165806] Allocated by task 366:
+[ 35.166414] ____kasan_kmalloc+0xc4/0xf0
+[ 35.167117] foo_kmem_cache_alloc_trace+0x3c/0x50 [igbvf]
+[ 35.168078] igbvf_probe+0x9c5/0x1a10 [igbvf]
+[ 35.168866] local_pci_probe+0x13c/0x1f0
+[ 35.169565] pci_device_probe+0x37e/0x6c0
+[ 35.179713]
+[ 35.179993] Freed by task 366:
+[ 35.180539] kasan_set_track+0x4c/0x80
+[ 35.181211] kasan_set_free_info+0x1f/0x40
+[ 35.181942] ____kasan_slab_free+0x103/0x140
+[ 35.182703] kfree+0xe3/0x250
+[ 35.183239] igbvf_probe+0x1173/0x1a10 [igbvf]
+[ 35.184040] local_pci_probe+0x13c/0x1f0
+
+Fixes: d4e0fe01a38a0 (igbvf: add new driver to support 82576 virtual functions)
+Reported-by: Zheyu Ma <zheyuma97@gmail.com>
+Signed-off-by: Letu Ren <fantasquex@gmail.com>
+Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/igbvf/netdev.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
+index 07c9e9e0546f5..fe8c0a26b7201 100644
+--- a/drivers/net/ethernet/intel/igbvf/netdev.c
++++ b/drivers/net/ethernet/intel/igbvf/netdev.c
+@@ -2873,6 +2873,7 @@ static int igbvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+ return 0;
+
+ err_hw_init:
++ netif_napi_del(&adapter->rx_ring->napi);
+ kfree(adapter->tx_ring);
+ kfree(adapter->rx_ring);
+ err_sw_init:
+--
+2.33.0
+
--- /dev/null
+From 89266a7b4a871ee9440451ba963d18f7213de9d6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 2 Nov 2021 09:20:06 +0200
+Subject: igc: Fix typo in i225 LTR functions
+
+From: Sasha Neftin <sasha.neftin@intel.com>
+
+[ Upstream commit 0182d1f3fa640888a2ed7e3f6df2fdb10adee7c8 ]
+
+The LTR maximum value was incorrectly written using the scale from
+the LTR minimum value. This would cause incorrect values to be sent,
+in cases where the initial calculation lead to different min/max scales.
+
+Fixes: 707abf069548 ("igc: Add initial LTR support")
+Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
+Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
+Tested-by: Nechama Kraus <nechamax.kraus@linux.intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/igc/igc_i225.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/igc/igc_i225.c b/drivers/net/ethernet/intel/igc/igc_i225.c
+index 7ec04e48860c6..553d6bc78e6bd 100644
+--- a/drivers/net/ethernet/intel/igc/igc_i225.c
++++ b/drivers/net/ethernet/intel/igc/igc_i225.c
+@@ -636,7 +636,7 @@ s32 igc_set_ltr_i225(struct igc_hw *hw, bool link)
+ ltrv = rd32(IGC_LTRMAXV);
+ if (ltr_max != (ltrv & IGC_LTRMAXV_LTRV_MASK)) {
+ ltrv = IGC_LTRMAXV_LSNP_REQ | ltr_max |
+- (scale_min << IGC_LTRMAXV_SCALE_SHIFT);
++ (scale_max << IGC_LTRMAXV_SCALE_SHIFT);
+ wr32(IGC_LTRMAXV, ltrv);
+ }
+ }
+--
+2.33.0
+
--- /dev/null
+From 9fe2849e248973d719913c779a33c4f3571e0063 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 9 Dec 2021 10:50:58 -0800
+Subject: inet_diag: fix kernel-infoleak for UDP sockets
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 71ddeac8cd1d217744a0e060ff520e147c9328d1 ]
+
+KMSAN reported a kernel-infoleak [1], that can exploited
+by unpriv users.
+
+After analysis it turned out UDP was not initializing
+r->idiag_expires. Other users of inet_sk_diag_fill()
+might make the same mistake in the future, so fix this
+in inet_sk_diag_fill().
+
+[1]
+BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]
+BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]
+BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
+ instrument_copy_to_user include/linux/instrumented.h:121 [inline]
+ copyout lib/iov_iter.c:156 [inline]
+ _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670
+ copy_to_iter include/linux/uio.h:155 [inline]
+ simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519
+ __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425
+ skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533
+ skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]
+ netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974
+ sock_recvmsg_nosec net/socket.c:944 [inline]
+ sock_recvmsg net/socket.c:962 [inline]
+ sock_read_iter+0x5a9/0x630 net/socket.c:1035
+ call_read_iter include/linux/fs.h:2156 [inline]
+ new_sync_read fs/read_write.c:400 [inline]
+ vfs_read+0x1631/0x1980 fs/read_write.c:481
+ ksys_read+0x28c/0x520 fs/read_write.c:619
+ __do_sys_read fs/read_write.c:629 [inline]
+ __se_sys_read fs/read_write.c:627 [inline]
+ __x64_sys_read+0xdb/0x120 fs/read_write.c:627
+ do_syscall_x64 arch/x86/entry/common.c:51 [inline]
+ do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Uninit was created at:
+ slab_post_alloc_hook mm/slab.h:524 [inline]
+ slab_alloc_node mm/slub.c:3251 [inline]
+ __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
+ kmalloc_reserve net/core/skbuff.c:354 [inline]
+ __alloc_skb+0x545/0xf90 net/core/skbuff.c:426
+ alloc_skb include/linux/skbuff.h:1126 [inline]
+ netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245
+ __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370
+ netlink_dump_start include/linux/netlink.h:254 [inline]
+ inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343
+ sock_diag_rcv_msg+0x24a/0x620
+ netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491
+ sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276
+ netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
+ netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345
+ netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916
+ sock_sendmsg_nosec net/socket.c:704 [inline]
+ sock_sendmsg net/socket.c:724 [inline]
+ sock_write_iter+0x594/0x690 net/socket.c:1057
+ do_iter_readv_writev+0xa7f/0xc70
+ do_iter_write+0x52c/0x1500 fs/read_write.c:851
+ vfs_writev fs/read_write.c:924 [inline]
+ do_writev+0x63f/0xe30 fs/read_write.c:967
+ __do_sys_writev fs/read_write.c:1040 [inline]
+ __se_sys_writev fs/read_write.c:1037 [inline]
+ __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
+ do_syscall_x64 arch/x86/entry/common.c:51 [inline]
+ do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+
+Bytes 68-71 of 312 are uninitialized
+Memory access of size 312 starts at ffff88812ab54000
+Data copied to user address 0000000020001440
+
+CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+
+Fixes: 3c4d05c80567 ("inet_diag: Introduce the inet socket dumping routine")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Link: https://lore.kernel.org/r/20211209185058.53917-1-eric.dumazet@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv4/inet_diag.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
+index 93474b1bea4e0..fa9f1de58df46 100644
+--- a/net/ipv4/inet_diag.c
++++ b/net/ipv4/inet_diag.c
+@@ -261,6 +261,7 @@ int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
+ r->idiag_state = sk->sk_state;
+ r->idiag_timer = 0;
+ r->idiag_retrans = 0;
++ r->idiag_expires = 0;
+
+ if (inet_diag_msg_attrs_fill(sk, skb, r, ext,
+ sk_user_ns(NETLINK_CB(cb->skb).sk),
+@@ -314,9 +315,6 @@ int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
+ r->idiag_retrans = icsk->icsk_probes_out;
+ r->idiag_expires =
+ jiffies_delta_to_msecs(sk->sk_timer.expires - jiffies);
+- } else {
+- r->idiag_timer = 0;
+- r->idiag_expires = 0;
+ }
+
+ if ((ext & (1 << (INET_DIAG_INFO - 1))) && handler->idiag_info_size) {
+--
+2.33.0
+
--- /dev/null
+From bd7b9c06368ab266738fe58db96dda78c15fbcbf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 26 Oct 2021 02:24:48 +0200
+Subject: ixgbe: Document how to enable NBASE-T support
+
+From: Robert Schlabbach <robert_s@gmx.net>
+
+[ Upstream commit 271225fd57c2f1e0b3f8826df51be6c634affefe ]
+
+Commit a296d665eae1 ("ixgbe: Add ethtool support to enable 2.5 and 5.0
+Gbps support") introduced suppression of the advertisement of NBASE-T
+speeds by default, according to Todd Fujinaka to accommodate customers
+with network switches which could not cope with advertised NBASE-T
+speeds, as posted in the E1000-devel mailing list:
+
+https://sourceforge.net/p/e1000/mailman/message/37106269/
+
+However, the suppression was not documented at all, nor was how to
+enable NBASE-T support.
+
+Properly document the NBASE-T suppression and how to enable NBASE-T
+support.
+
+Fixes: a296d665eae1 ("ixgbe: Add ethtool support to enable 2.5 and 5.0 Gbps support")
+Reported-by: Robert Schlabbach <robert_s@gmx.net>
+Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../device_drivers/ethernet/intel/ixgbe.rst | 16 ++++++++++++++++
+ drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++++
+ 2 files changed, 20 insertions(+)
+
+diff --git a/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst
+index f1d5233e5e510..0a233b17c664e 100644
+--- a/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst
++++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst
+@@ -440,6 +440,22 @@ NOTE: For 82599-based network connections, if you are enabling jumbo frames in
+ a virtual function (VF), jumbo frames must first be enabled in the physical
+ function (PF). The VF MTU setting cannot be larger than the PF MTU.
+
++NBASE-T Support
++---------------
++The ixgbe driver supports NBASE-T on some devices. However, the advertisement
++of NBASE-T speeds is suppressed by default, to accommodate broken network
++switches which cannot cope with advertised NBASE-T speeds. Use the ethtool
++command to enable advertising NBASE-T speeds on devices which support it::
++
++ ethtool -s eth? advertise 0x1800000001028
++
++On Linux systems with INTERFACES(5), this can be specified as a pre-up command
++in /etc/network/interfaces so that the interface is always brought up with
++NBASE-T support, e.g.::
++
++ iface eth? inet dhcp
++ pre-up ethtool -s eth? advertise 0x1800000001028 || true
++
+ Generic Receive Offload, aka GRO
+ --------------------------------
+ The driver supports the in-kernel software implementation of GRO. GRO has
+diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+index ffe322136c584..a3a02e2f92f64 100644
+--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
++++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+@@ -5532,6 +5532,10 @@ static int ixgbe_non_sfp_link_config(struct ixgbe_hw *hw)
+ if (!speed && hw->mac.ops.get_link_capabilities) {
+ ret = hw->mac.ops.get_link_capabilities(hw, &speed,
+ &autoneg);
++ /* remove NBASE-T speeds from default autonegotiation
++ * to accommodate broken network switches in the field
++ * which cannot cope with advertised NBASE-T speeds
++ */
+ speed &= ~(IXGBE_LINK_SPEED_5GB_FULL |
+ IXGBE_LINK_SPEED_2_5GB_FULL);
+ }
+--
+2.33.0
+
--- /dev/null
+From eda5a17f58d998da666787d439e9d071438a04c9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 1 Nov 2021 18:39:36 -0700
+Subject: ixgbe: set X550 MDIO speed before talking to PHY
+
+From: Cyril Novikov <cnovikov@lynx.com>
+
+[ Upstream commit bf0a375055bd1afbbf02a0ef45f7655da7b71317 ]
+
+The MDIO bus speed must be initialized before talking to the PHY the first
+time in order to avoid talking to it using a speed that the PHY doesn't
+support.
+
+This fixes HW initialization error -17 (IXGBE_ERR_PHY_ADDR_INVALID) on
+Denverton CPUs (a.k.a. the Atom C3000 family) on ports with a 10Gb network
+plugged in. On those devices, HLREG0[MDCSPD] resets to 1, which combined
+with the 10Gb network results in a 24MHz MDIO speed, which is apparently
+too fast for the connected PHY. PHY register reads over MDIO bus return
+garbage, leading to initialization failure.
+
+Reproduced with Linux kernel 4.19 and 5.15-rc7. Can be reproduced using
+the following setup:
+
+* Use an Atom C3000 family system with at least one X552 LAN on the SoC
+* Disable PXE or other BIOS network initialization if possible
+ (the interface must not be initialized before Linux boots)
+* Connect a live 10Gb Ethernet cable to an X550 port
+* Power cycle (not reset, doesn't always work) the system and boot Linux
+* Observe: ixgbe interfaces w/ 10GbE cables plugged in fail with error -17
+
+Fixes: e84db7272798 ("ixgbe: Introduce function to control MDIO speed")
+Signed-off-by: Cyril Novikov <cnovikov@lynx.com>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+index 5e339afa682a6..37f2bc6de4b65 100644
+--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
++++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c
+@@ -3405,6 +3405,9 @@ static s32 ixgbe_reset_hw_X550em(struct ixgbe_hw *hw)
+ /* flush pending Tx transactions */
+ ixgbe_clear_tx_pending(hw);
+
++ /* set MDIO speed before talking to the PHY in case it's the 1st time */
++ ixgbe_set_mdio_speed(hw);
++
+ /* PHY ops must be identified and initialized prior to reset */
+ status = hw->phy.ops.init(hw);
+ if (status == IXGBE_ERR_SFP_NOT_SUPPORTED ||
+--
+2.33.0
+
--- /dev/null
+From 581a73a8c4c6803cb47cfd0caa61488e374aed36 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 2 Dec 2021 15:26:25 +0200
+Subject: mac80211: agg-tx: don't schedule_and_wake_txq() under sta->lock
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+[ Upstream commit 06c41bda0ea14aa7fba932a9613c4ee239682cf0 ]
+
+When we call ieee80211_agg_start_txq(), that will in turn call
+schedule_and_wake_txq(). Called from ieee80211_stop_tx_ba_cb()
+this is done under sta->lock, which leads to certain circular
+lock dependencies, as reported by Chris Murphy:
+https://lore.kernel.org/r/CAJCQCtSXJ5qA4bqSPY=oLRMbv-irihVvP7A2uGutEbXQVkoNaw@mail.gmail.com
+
+In general, ieee80211_agg_start_txq() is usually not called
+with sta->lock held, only in this one place. But it's always
+called with sta->ampdu_mlme.mtx held, and that's therefore
+clearly sufficient.
+
+Change ieee80211_stop_tx_ba_cb() to also call it without the
+sta->lock held, by factoring it out of ieee80211_remove_tid_tx()
+(which is only called in this one place).
+
+This breaks the locking chain and makes it less likely that
+we'll have similar locking chain problems in the future.
+
+Fixes: ba8c3d6f16a1 ("mac80211: add an intermediate software queue implementation")
+Reported-by: Chris Murphy <lists@colorremedies.com>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Link: https://lore.kernel.org/r/iwlwifi.20211202152554.f519884c8784.I555fef8e67d93fff3d9a304886c4a9f8b322e591@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/agg-tx.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
+index 407765ad9cc92..190f300d8923c 100644
+--- a/net/mac80211/agg-tx.c
++++ b/net/mac80211/agg-tx.c
+@@ -9,7 +9,7 @@
+ * Copyright 2007, Michael Wu <flamingice@sourmilk.net>
+ * Copyright 2007-2010, Intel Corporation
+ * Copyright(c) 2015-2017 Intel Deutschland GmbH
+- * Copyright (C) 2018 - 2020 Intel Corporation
++ * Copyright (C) 2018 - 2021 Intel Corporation
+ */
+
+ #include <linux/ieee80211.h>
+@@ -213,6 +213,8 @@ ieee80211_agg_start_txq(struct sta_info *sta, int tid, bool enable)
+ struct ieee80211_txq *txq = sta->sta.txq[tid];
+ struct txq_info *txqi;
+
++ lockdep_assert_held(&sta->ampdu_mlme.mtx);
++
+ if (!txq)
+ return;
+
+@@ -290,7 +292,6 @@ static void ieee80211_remove_tid_tx(struct sta_info *sta, int tid)
+ ieee80211_assign_tid_tx(sta, tid, NULL);
+
+ ieee80211_agg_splice_finish(sta->sdata, tid);
+- ieee80211_agg_start_txq(sta, tid, false);
+
+ kfree_rcu(tid_tx, rcu_head);
+ }
+@@ -889,6 +890,7 @@ void ieee80211_stop_tx_ba_cb(struct sta_info *sta, int tid,
+ {
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool send_delba = false;
++ bool start_txq = false;
+
+ ht_dbg(sdata, "Stopping Tx BA session for %pM tid %d\n",
+ sta->sta.addr, tid);
+@@ -906,10 +908,14 @@ void ieee80211_stop_tx_ba_cb(struct sta_info *sta, int tid,
+ send_delba = true;
+
+ ieee80211_remove_tid_tx(sta, tid);
++ start_txq = true;
+
+ unlock_sta:
+ spin_unlock_bh(&sta->lock);
+
++ if (start_txq)
++ ieee80211_agg_start_txq(sta, tid, false);
++
+ if (send_delba)
+ ieee80211_send_delba(sdata, sta->sta.addr, tid,
+ WLAN_BACK_INITIATOR, WLAN_REASON_QSTA_NOT_USE);
+--
+2.33.0
+
--- /dev/null
+From 8318739d9ea2e9267667a3ab5c2f64473d1a9239 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 29 Nov 2021 15:32:46 +0200
+Subject: mac80211: fix lookup when adding AddBA extension element
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+[ Upstream commit 511ab0c1dfb260a6b17b8771109e8d63474473a7 ]
+
+We should be doing the HE capabilities lookup based on the full
+interface type so if P2P doesn't have HE but client has it doesn't
+get confused. Fix that.
+
+Fixes: 2ab45876756f ("mac80211: add support for the ADDBA extension element")
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
+Link: https://lore.kernel.org/r/iwlwifi.20211129152938.010fc1d61137.If3a468145f29d670cb00a693bed559d8290ba693@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/agg-rx.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
+index cd4cf84a7f99f..6ef8ded4ec764 100644
+--- a/net/mac80211/agg-rx.c
++++ b/net/mac80211/agg-rx.c
+@@ -9,7 +9,7 @@
+ * Copyright 2007, Michael Wu <flamingice@sourmilk.net>
+ * Copyright 2007-2010, Intel Corporation
+ * Copyright(c) 2015-2017 Intel Deutschland GmbH
+- * Copyright (C) 2018-2020 Intel Corporation
++ * Copyright (C) 2018-2021 Intel Corporation
+ */
+
+ /**
+@@ -191,7 +191,8 @@ static void ieee80211_add_addbaext(struct ieee80211_sub_if_data *sdata,
+ sband = ieee80211_get_sband(sdata);
+ if (!sband)
+ return;
+- he_cap = ieee80211_get_he_iftype_cap(sband, sdata->vif.type);
++ he_cap = ieee80211_get_he_iftype_cap(sband,
++ ieee80211_vif_type_p2p(&sdata->vif));
+ if (!he_cap)
+ return;
+
+--
+2.33.0
+
--- /dev/null
+From 80f1bcfe957c51c304518929b770a8585aae160e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 22 Nov 2021 12:47:40 +0100
+Subject: mac80211: track only QoS data frames for admission control
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+[ Upstream commit d5e568c3a4ec2ddd23e7dc5ad5b0c64e4f22981a ]
+
+For admission control, obviously all of that only works for
+QoS data frames, otherwise we cannot even access the QoS
+field in the header.
+
+Syzbot reported (see below) an uninitialized value here due
+to a status of a non-QoS nullfunc packet, which isn't even
+long enough to contain the QoS header.
+
+Fix this to only do anything for QoS data packets.
+
+Reported-by: syzbot+614e82b88a1a4973e534@syzkaller.appspotmail.com
+Fixes: 02219b3abca5 ("mac80211: add WMM admission control support")
+Link: https://lore.kernel.org/r/20211122124737.dad29e65902a.Ieb04587afacb27c14e0de93ec1bfbefb238cc2a0@changeid
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/mlme.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
+index 32bc30ec50ec9..7bd42827540ae 100644
+--- a/net/mac80211/mlme.c
++++ b/net/mac80211/mlme.c
+@@ -2493,11 +2493,18 @@ static void ieee80211_sta_tx_wmm_ac_notify(struct ieee80211_sub_if_data *sdata,
+ u16 tx_time)
+ {
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+- u16 tid = ieee80211_get_tid(hdr);
+- int ac = ieee80211_ac_from_tid(tid);
+- struct ieee80211_sta_tx_tspec *tx_tspec = &ifmgd->tx_tspec[ac];
++ u16 tid;
++ int ac;
++ struct ieee80211_sta_tx_tspec *tx_tspec;
+ unsigned long now = jiffies;
+
++ if (!ieee80211_is_data_qos(hdr->frame_control))
++ return;
++
++ tid = ieee80211_get_tid(hdr);
++ ac = ieee80211_ac_from_tid(tid);
++ tx_tspec = &ifmgd->tx_tspec[ac];
++
+ if (likely(!tx_tspec->admitted_time))
+ return;
+
+--
+2.33.0
+
--- /dev/null
+From 087ed4d98900ce65de91e62fac42ee3a4542c9c5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Dec 2021 15:16:02 -0800
+Subject: mptcp: clear 'kern' flag from fallback sockets
+
+From: Florian Westphal <fw@strlen.de>
+
+[ Upstream commit d6692b3b97bdc165d150f4c1505751a323a80717 ]
+
+The mptcp ULP extension relies on sk->sk_sock_kern being set correctly:
+It prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); from
+working for plain tcp sockets (any userspace-exposed socket).
+
+But in case of fallback, accept() can return a plain tcp sk.
+In such case, sk is still tagged as 'kernel' and setsockopt will work.
+
+This will crash the kernel, The subflow extension has a NULL ctx->conn
+mptcp socket:
+
+BUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0
+Call Trace:
+ tcp_data_ready+0xf8/0x370
+ [..]
+
+Fixes: cf7da0d66cc1 ("mptcp: Create SUBFLOW socket for incoming connections")
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mptcp/protocol.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
+index 3ca8b359e399a..8123c79e27913 100644
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -2149,7 +2149,7 @@ static struct sock *mptcp_accept(struct sock *sk, int flags, int *err,
+ */
+ if (WARN_ON_ONCE(!new_mptcp_sock)) {
+ tcp_sk(newsk)->is_mptcp = 0;
+- return newsk;
++ goto out;
+ }
+
+ /* acquire the 2nd reference for the owning socket */
+@@ -2174,6 +2174,8 @@ static struct sock *mptcp_accept(struct sock *sk, int flags, int *err,
+ MPTCP_MIB_MPCAPABLEPASSIVEFALLBACK);
+ }
+
++out:
++ newsk->sk_kern_sock = kern;
+ return newsk;
+ }
+
+--
+2.33.0
+
--- /dev/null
+From bc255c55e6d62704a148ddfd37394aa4372912d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 16 Dec 2021 11:28:25 +0200
+Subject: net: Fix double 0x prefix print in SKB dump
+
+From: Gal Pressman <gal@nvidia.com>
+
+[ Upstream commit 8a03ef676ade55182f9b05115763aeda6dc08159 ]
+
+When printing netdev features %pNF already takes care of the 0x prefix,
+remove the explicit one.
+
+Fixes: 6413139dfc64 ("skbuff: increase verbosity when dumping skb data")
+Signed-off-by: Gal Pressman <gal@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/skbuff.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/core/skbuff.c b/net/core/skbuff.c
+index 825e6b9880030..0215ae898e836 100644
+--- a/net/core/skbuff.c
++++ b/net/core/skbuff.c
+@@ -769,7 +769,7 @@ void skb_dump(const char *level, const struct sk_buff *skb, bool full_pkt)
+ ntohs(skb->protocol), skb->pkt_type, skb->skb_iif);
+
+ if (dev)
+- printk("%sdev name=%s feat=0x%pNF\n",
++ printk("%sdev name=%s feat=%pNF\n",
+ level, dev->name, &dev->features);
+ if (sk)
+ printk("%ssk family=%hu type=%u proto=%u\n",
+--
+2.33.0
+
--- /dev/null
+From 8a9e27ff4ef77775a6493fbcd796c35450b8a544 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 10 Dec 2021 21:09:33 +0800
+Subject: net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg
+
+From: Jie Wang <wangjie125@huawei.com>
+
+[ Upstream commit 27cbf64a766e86f068ce6214f04c00ceb4db1af4 ]
+
+Currently, the hns3_remove function firstly uninstall client instance,
+and then uninstall acceletion engine device. The netdevice is freed in
+client instance uninstall process, but acceletion engine device uninstall
+process still use it to trace runtime information. This causes a use after
+free problem.
+
+So fixes it by check the instance register state to avoid use after free.
+
+Fixes: d8355240cf8f ("net: hns3: add trace event support for PF/VF mailbox")
+Signed-off-by: Jie Wang <wangjie125@huawei.com>
+Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
+index 5b2dcd97c1078..b8e5ca6700ed5 100644
+--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
++++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
+@@ -109,7 +109,8 @@ int hclgevf_send_mbx_msg(struct hclgevf_dev *hdev,
+
+ memcpy(&req->msg, send_msg, sizeof(struct hclge_vf_to_pf_msg));
+
+- trace_hclge_vf_mbx_send(hdev, req);
++ if (test_bit(HCLGEVF_STATE_NIC_REGISTERED, &hdev->state))
++ trace_hclge_vf_mbx_send(hdev, req);
+
+ /* synchronous send */
+ if (need_resp) {
+--
+2.33.0
+
--- /dev/null
+From f8d785f9fc3be4694e6818cddab5414fa8eb8fa8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Dec 2021 09:39:37 -0500
+Subject: net/packet: rx_owner_map depends on pg_vec
+
+From: Willem de Bruijn <willemb@google.com>
+
+[ Upstream commit ec6af094ea28f0f2dda1a6a33b14cd57e36a9755 ]
+
+Packet sockets may switch ring versions. Avoid misinterpreting state
+between versions, whose fields share a union. rx_owner_map is only
+allocated with a packet ring (pg_vec) and both are swapped together.
+If pg_vec is NULL, meaning no packet ring was allocated, then neither
+was rx_owner_map. And the field may be old state from a tpacket_v3.
+
+Fixes: 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race condition")
+Reported-by: Syzbot <syzbot+1ac0994a0a0c55151121@syzkaller.appspotmail.com>
+Signed-off-by: Willem de Bruijn <willemb@google.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20211215143937.106178-1-willemdebruijn.kernel@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/packet/af_packet.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
+index 08144559eed56..f78097aa403a8 100644
+--- a/net/packet/af_packet.c
++++ b/net/packet/af_packet.c
+@@ -4461,9 +4461,10 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
+ }
+
+ out_free_pg_vec:
+- bitmap_free(rx_owner_map);
+- if (pg_vec)
++ if (pg_vec) {
++ bitmap_free(rx_owner_map);
+ free_pg_vec(pg_vec, order, req->tp_block_nr);
++ }
+ out:
+ return err;
+ }
+--
+2.33.0
+
--- /dev/null
+From 4dde7fbefc01f645509496c747ced23f9faf6561 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 10 Dec 2021 17:42:47 +0100
+Subject: net/sched: sch_ets: don't remove idle classes from the round-robin
+ list
+
+From: Davide Caratti <dcaratti@redhat.com>
+
+[ Upstream commit c062f2a0b04d86c5b8c9d973bea43493eaca3d32 ]
+
+Shuang reported that the following script:
+
+ 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bands 8 strict 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
+ 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a own -b 00:c1:a0:c1:a0:00 -t udp &
+ 3) tc qdisc change dev ddd0 handle 10: ets bands 4 strict 2 quanta 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
+
+crashes systematically when line 2) is commented:
+
+ list_del corruption, ffff8e028404bd30->next is LIST_POISON1 (dead000000000100)
+ ------------[ cut here ]------------
+ kernel BUG at lib/list_debug.c:47!
+ invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+ CPU: 0 PID: 954 Comm: tc Not tainted 5.16.0-rc4+ #478
+ Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
+ RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47
+ Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe
+ RSP: 0018:ffffae46807a3888 EFLAGS: 00010246
+ RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202
+ RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff
+ RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff
+ R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800
+ R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400
+ FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0
+ Call Trace:
+ <TASK>
+ ets_qdisc_change+0x58b/0xa70 [sch_ets]
+ tc_modify_qdisc+0x323/0x880
+ rtnetlink_rcv_msg+0x169/0x4a0
+ netlink_rcv_skb+0x50/0x100
+ netlink_unicast+0x1a5/0x280
+ netlink_sendmsg+0x257/0x4d0
+ sock_sendmsg+0x5b/0x60
+ ____sys_sendmsg+0x1f2/0x260
+ ___sys_sendmsg+0x7c/0xc0
+ __sys_sendmsg+0x57/0xa0
+ do_syscall_64+0x3a/0x80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+ RIP: 0033:0x7efdc8031338
+ Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55
+ RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
+ RAX: ffffffffffffffda RBX: 0000000061b37a97 RCX: 00007efdc8031338
+ RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003
+ RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940
+ R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001
+ R13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000
+ </TASK>
+ Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev pcspkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: sch_ets]
+ ---[ end trace f35878d1912655c2 ]---
+ RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47
+ Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff <0f> 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe
+ RSP: 0018:ffffae46807a3888 EFLAGS: 00010246
+ RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202
+ RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff
+ RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff
+ R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800
+ R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400
+ FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0
+ Kernel panic - not syncing: Fatal exception in interrupt
+ Kernel Offset: 0x4e00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
+ ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
+
+we can remove 'q->classes[i].alist' only if DRR class 'i' was part of the
+active list. In the ETS scheduler DRR classes belong to that list only if
+the queue length is greater than zero: we need to test for non-zero value
+of 'q->classes[i].qdisc->q.qlen' before removing from the list, similarly
+to what has been done elsewhere in the ETS code.
+
+Fixes: de6d25924c2a ("net/sched: sch_ets: don't peek at classes beyond 'nbands'")
+Reported-by: Shuang Li <shuali@redhat.com>
+Signed-off-by: Davide Caratti <dcaratti@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/sch_ets.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/sched/sch_ets.c b/net/sched/sch_ets.c
+index c34cb6e81d855..9c224872ef035 100644
+--- a/net/sched/sch_ets.c
++++ b/net/sched/sch_ets.c
+@@ -668,9 +668,9 @@ static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt,
+ }
+ }
+ for (i = q->nbands; i < oldbands; i++) {
+- qdisc_tree_flush_backlog(q->classes[i].qdisc);
+- if (i >= q->nstrict)
++ if (i >= q->nstrict && q->classes[i].qdisc->q.qlen)
+ list_del(&q->classes[i].alist);
++ qdisc_tree_flush_backlog(q->classes[i].qdisc);
+ }
+ q->nstrict = nstrict;
+ memcpy(q->prio2band, priomap, sizeof(priomap));
+--
+2.33.0
+
--- /dev/null
+From db54a90a05ddc7fd5f07a8292f4c0f61a6493838 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Dec 2021 20:29:21 +0800
+Subject: net/smc: Prevent smc_release() from long blocking
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: D. Wythe <alibuda@linux.alibaba.com>
+
+[ Upstream commit 5c15b3123f65f8fbb1b445d9a7e8812e0e435df2 ]
+
+In nginx/wrk benchmark, there's a hung problem with high probability
+on case likes that: (client will last several minutes to exit)
+
+server: smc_run nginx
+
+client: smc_run wrk -c 10000 -t 1 http://server
+
+Client hangs with the following backtrace:
+
+0 [ffffa7ce8Of3bbf8] __schedule at ffffffff9f9eOd5f
+1 [ffffa7ce8Of3bc88] schedule at ffffffff9f9eløe6
+2 [ffffa7ce8Of3bcaO] schedule_timeout at ffffffff9f9e3f3c
+3 [ffffa7ce8Of3bd2O] wait_for_common at ffffffff9f9el9de
+4 [ffffa7ce8Of3bd8O] __flush_work at ffffffff9fOfeOl3
+5 [ffffa7ce8øf3bdfO] smc_release at ffffffffcO697d24 [smc]
+6 [ffffa7ce8Of3be2O] __sock_release at ffffffff9f8O2e2d
+7 [ffffa7ce8Of3be4ø] sock_close at ffffffff9f8ø2ebl
+8 [ffffa7ce8øf3be48] __fput at ffffffff9f334f93
+9 [ffffa7ce8Of3be78] task_work_run at ffffffff9flOlff5
+10 [ffffa7ce8Of3beaO] do_exit at ffffffff9fOe5Ol2
+11 [ffffa7ce8Of3bflO] do_group_exit at ffffffff9fOe592a
+12 [ffffa7ce8Of3bf38] __x64_sys_exit_group at ffffffff9fOe5994
+13 [ffffa7ce8Of3bf4O] do_syscall_64 at ffffffff9f9d4373
+14 [ffffa7ce8Of3bfsO] entry_SYSCALL_64_after_hwframe at ffffffff9fa0007c
+
+This issue dues to flush_work(), which is used to wait for
+smc_connect_work() to finish in smc_release(). Once lots of
+smc_connect_work() was pending or all executing work dangling,
+smc_release() has to block until one worker comes to free, which
+is equivalent to wait another smc_connnect_work() to finish.
+
+In order to fix this, There are two changes:
+
+1. For those idle smc_connect_work(), cancel it from the workqueue; for
+ executing smc_connect_work(), waiting for it to finish. For that
+ purpose, replace flush_work() with cancel_work_sync().
+
+2. Since smc_connect() hold a reference for passive closing, if
+ smc_connect_work() has been cancelled, release the reference.
+
+Fixes: 24ac3a08e658 ("net/smc: rebuild nonblocking connect")
+Reported-by: Tony Lu <tonylu@linux.alibaba.com>
+Tested-by: Dust Li <dust.li@linux.alibaba.com>
+Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
+Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
+Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
+Acked-by: Karsten Graul <kgraul@linux.ibm.com>
+Link: https://lore.kernel.org/r/1639571361-101128-1-git-send-email-alibuda@linux.alibaba.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/smc/af_smc.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
+index d324a12c26cd9..99b902e410c49 100644
+--- a/net/smc/af_smc.c
++++ b/net/smc/af_smc.c
+@@ -191,7 +191,9 @@ static int smc_release(struct socket *sock)
+ /* cleanup for a dangling non-blocking connect */
+ if (smc->connect_nonblock && sk->sk_state == SMC_INIT)
+ tcp_abort(smc->clcsock->sk, ECONNABORTED);
+- flush_work(&smc->connect_work);
++
++ if (cancel_work_sync(&smc->connect_work))
++ sock_put(&smc->sk); /* sock_hold in smc_connect for passive closing */
+
+ if (sk->sk_state == SMC_LISTEN)
+ /* smc_close_non_accepted() is called and acquires
+--
+2.33.0
+
--- /dev/null
+From 68c4d1052b428464c40d31e3e2bc9ccd45866105 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Dec 2021 12:24:49 -0800
+Subject: net: systemport: Add global locking for descriptor lifecycle
+
+From: Florian Fainelli <f.fainelli@gmail.com>
+
+[ Upstream commit 8b8e6e782456f1ce02a7ae914bbd5b1053f0b034 ]
+
+The descriptor list is a shared resource across all of the transmit queues, and
+the locking mechanism used today only protects concurrency across a given
+transmit queue between the transmit and reclaiming. This creates an opportunity
+for the SYSTEMPORT hardware to work on corrupted descriptors if we have
+multiple producers at once which is the case when using multiple transmit
+queues.
+
+This was particularly noticeable when using multiple flows/transmit queues and
+it showed up in interesting ways in that UDP packets would get a correct UDP
+header checksum being calculated over an incorrect packet length. Similarly TCP
+packets would get an equally correct checksum computed by the hardware over an
+incorrect packet length.
+
+The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges
+when the driver produces a new descriptor anytime it writes to the
+WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to
+re-organize its descriptors and it is possible that concurrent TX queues
+eventually break this internal allocation scheme to the point where the
+length/status part of the descriptor gets used for an incorrect data buffer.
+
+The fix is to impose a global serialization for all TX queues in the short
+section where we are writing to the WRITE_PORT_{HI,LO} registers which solves
+the corruption even with multiple concurrent TX queues being used.
+
+Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
+Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
+Link: https://lore.kernel.org/r/20211215202450.4086240-1-f.fainelli@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/bcmsysport.c | 5 ++++-
+ drivers/net/ethernet/broadcom/bcmsysport.h | 1 +
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
+index 0404aafd5ce56..1a703b95208b0 100644
+--- a/drivers/net/ethernet/broadcom/bcmsysport.c
++++ b/drivers/net/ethernet/broadcom/bcmsysport.c
+@@ -1304,11 +1304,11 @@ static netdev_tx_t bcm_sysport_xmit(struct sk_buff *skb,
+ struct bcm_sysport_priv *priv = netdev_priv(dev);
+ struct device *kdev = &priv->pdev->dev;
+ struct bcm_sysport_tx_ring *ring;
++ unsigned long flags, desc_flags;
+ struct bcm_sysport_cb *cb;
+ struct netdev_queue *txq;
+ u32 len_status, addr_lo;
+ unsigned int skb_len;
+- unsigned long flags;
+ dma_addr_t mapping;
+ u16 queue;
+ int ret;
+@@ -1368,8 +1368,10 @@ static netdev_tx_t bcm_sysport_xmit(struct sk_buff *skb,
+ ring->desc_count--;
+
+ /* Ports are latched, so write upper address first */
++ spin_lock_irqsave(&priv->desc_lock, desc_flags);
+ tdma_writel(priv, len_status, TDMA_WRITE_PORT_HI(ring->index));
+ tdma_writel(priv, addr_lo, TDMA_WRITE_PORT_LO(ring->index));
++ spin_unlock_irqrestore(&priv->desc_lock, desc_flags);
+
+ /* Check ring space and update SW control flow */
+ if (ring->desc_count == 0)
+@@ -2008,6 +2010,7 @@ static int bcm_sysport_open(struct net_device *dev)
+ }
+
+ /* Initialize both hardware and software ring */
++ spin_lock_init(&priv->desc_lock);
+ for (i = 0; i < dev->num_tx_queues; i++) {
+ ret = bcm_sysport_init_tx_ring(priv, i);
+ if (ret) {
+diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h b/drivers/net/ethernet/broadcom/bcmsysport.h
+index 3a5cb6f128f57..1276e330e9d03 100644
+--- a/drivers/net/ethernet/broadcom/bcmsysport.h
++++ b/drivers/net/ethernet/broadcom/bcmsysport.h
+@@ -742,6 +742,7 @@ struct bcm_sysport_priv {
+ int wol_irq;
+
+ /* Transmit rings */
++ spinlock_t desc_lock;
+ struct bcm_sysport_tx_ring *tx_rings;
+
+ /* Receive queue */
+--
+2.33.0
+
--- /dev/null
+From f184e3b03f699bc4f1f7de6cb57d2dbc95d2ace6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Dec 2021 19:15:30 +0800
+Subject: netdevsim: Zero-initialize memory for new map's value in function
+ nsim_bpf_map_alloc
+
+From: Haimin Zhang <tcs.kernel@gmail.com>
+
+[ Upstream commit 481221775d53d6215a6e5e9ce1cce6d2b4ab9a46 ]
+
+Zero-initialize memory for new map's value in function nsim_bpf_map_alloc
+since it may cause a potential kernel information leak issue, as follows:
+1. nsim_bpf_map_alloc calls nsim_map_alloc_elem to allocate elements for
+a new map.
+2. nsim_map_alloc_elem uses kmalloc to allocate map's value, but doesn't
+zero it.
+3. A user application can use IOCTL BPF_MAP_LOOKUP_ELEM to get specific
+element's information in the map.
+4. The kernel function map_lookup_elem will call bpf_map_copy_value to get
+the information allocated at step-2, then use copy_to_user to copy to the
+user buffer.
+This can only leak information for an array map.
+
+Fixes: 395cacb5f1a0 ("netdevsim: bpf: support fake map offload")
+Suggested-by: Jakub Kicinski <kuba@kernel.org>
+Acked-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Haimin Zhang <tcs.kernel@gmail.com>
+Link: https://lore.kernel.org/r/20211215111530.72103-1-tcs.kernel@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/netdevsim/bpf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/netdevsim/bpf.c b/drivers/net/netdevsim/bpf.c
+index 90aafb56f1409..a438202129323 100644
+--- a/drivers/net/netdevsim/bpf.c
++++ b/drivers/net/netdevsim/bpf.c
+@@ -514,6 +514,7 @@ nsim_bpf_map_alloc(struct netdevsim *ns, struct bpf_offloaded_map *offmap)
+ goto err_free;
+ key = nmap->entry[i].key;
+ *key = i;
++ memset(nmap->entry[i].value, 0, offmap->map.value_size);
+ }
+ }
+
+--
+2.33.0
+
--- /dev/null
+From f66dbab5ab0657fdaf64f9ac523ecb32fc8319a2 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Dec 2021 18:46:59 +0800
+Subject: rds: memory leak in __rds_conn_create()
+
+From: Hangyu Hua <hbh25y@gmail.com>
+
+[ Upstream commit 5f9562ebe710c307adc5f666bf1a2162ee7977c0 ]
+
+__rds_conn_create() did not release conn->c_path when loop_trans != 0 and
+trans->t_prefer_loopback != 0 and is_outgoing == 0.
+
+Fixes: aced3ce57cd3 ("RDS tcp loopback connection can hang")
+Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
+Reviewed-by: Sharath Srinivasan <sharath.srinivasan@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/rds/connection.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/rds/connection.c b/net/rds/connection.c
+index a3bc4b54d4910..b4cc699c5fad3 100644
+--- a/net/rds/connection.c
++++ b/net/rds/connection.c
+@@ -253,6 +253,7 @@ static struct rds_connection *__rds_conn_create(struct net *net,
+ * should end up here, but if it
+ * does, reset/destroy the connection.
+ */
++ kfree(conn->c_path);
+ kmem_cache_free(rds_conn_slab, conn);
+ conn = ERR_PTR(-EOPNOTSUPP);
+ goto out;
+--
+2.33.0
+
--- /dev/null
+From e33ec44747a184594224bf872e8f1236ced513d3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 8 Dec 2021 14:07:41 +0100
+Subject: s390/kexec_file: fix error handling when applying relocations
+
+From: Philipp Rudo <prudo@redhat.com>
+
+[ Upstream commit 41967a37b8eedfee15b81406a9f3015be90d3980 ]
+
+arch_kexec_apply_relocations_add currently ignores all errors returned
+by arch_kexec_do_relocs. This means that every unknown relocation is
+silently skipped causing unpredictable behavior while the relocated code
+runs. Fix this by checking for errors and fail kexec_file_load if an
+unknown relocation type is encountered.
+
+The problem was found after gcc changed its behavior and used
+R_390_PLT32DBL relocations for brasl instruction and relied on ld to
+resolve the relocations in the final link in case direct calls are
+possible. As the purgatory code is only linked partially (option -r)
+ld didn't resolve the relocations leaving them for arch_kexec_do_relocs.
+But arch_kexec_do_relocs doesn't know how to handle R_390_PLT32DBL
+relocations so they were silently skipped. This ultimately caused an
+endless loop in the purgatory as the brasl instructions kept branching
+to itself.
+
+Fixes: 71406883fd35 ("s390/kexec_file: Add kexec_file_load system call")
+Reported-by: Tao Liu <ltao@redhat.com>
+Signed-off-by: Philipp Rudo <prudo@redhat.com>
+Link: https://lore.kernel.org/r/20211208130741.5821-3-prudo@redhat.com
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/s390/kernel/machine_kexec_file.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/arch/s390/kernel/machine_kexec_file.c b/arch/s390/kernel/machine_kexec_file.c
+index e7435f3a3d2d2..76cd09879eaf4 100644
+--- a/arch/s390/kernel/machine_kexec_file.c
++++ b/arch/s390/kernel/machine_kexec_file.c
+@@ -277,6 +277,7 @@ int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
+ {
+ Elf_Rela *relas;
+ int i, r_type;
++ int ret;
+
+ relas = (void *)pi->ehdr + relsec->sh_offset;
+
+@@ -311,7 +312,11 @@ int arch_kexec_apply_relocations_add(struct purgatory_info *pi,
+ addr = section->sh_addr + relas[i].r_offset;
+
+ r_type = ELF64_R_TYPE(relas[i].r_info);
+- arch_kexec_do_relocs(r_type, loc, val, addr);
++ ret = arch_kexec_do_relocs(r_type, loc, val, addr);
++ if (ret) {
++ pr_err("Unknown rela relocation: %d\n", r_type);
++ return -ENOEXEC;
++ }
+ }
+ return 0;
+ }
+--
+2.33.0
+
--- /dev/null
+From 226eba8d2989090bc5a8a0bf7d08b163a81aba67 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 10 Dec 2021 06:20:46 -0800
+Subject: sch_cake: do not call cake_destroy() from cake_init()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit ab443c53916730862cec202078d36fd4008bea79 ]
+
+qdiscs are not supposed to call their own destroy() method
+from init(), because core stack already does that.
+
+syzbot was able to trigger use after free:
+
+DEBUG_LOCKS_WARN_ON(lock->magic != lock)
+WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]
+WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
+Modules linked in:
+CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]
+RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
+Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff <0f> 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8
+RSP: 0018:ffffc9000627f290 EFLAGS: 00010282
+RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
+RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44
+RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000
+R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000
+R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000
+FS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0
+Call Trace:
+ <TASK>
+ tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810
+ tcf_block_put_ext net/sched/cls_api.c:1381 [inline]
+ tcf_block_put_ext net/sched/cls_api.c:1376 [inline]
+ tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394
+ cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695
+ qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293
+ tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660
+ rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571
+ netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496
+ netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
+ netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345
+ netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921
+ sock_sendmsg_nosec net/socket.c:704 [inline]
+ sock_sendmsg+0xcf/0x120 net/socket.c:724
+ ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
+ ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
+ __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
+ do_syscall_x64 arch/x86/entry/common.c:50 [inline]
+ do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+RIP: 0033:0x7f1bb06badb9
+Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.
+RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
+RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9
+RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003
+RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003
+R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688
+R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2
+ </TASK>
+
+Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
+Link: https://lore.kernel.org/r/20211210142046.698336-1-eric.dumazet@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/sch_cake.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
+index c2c37ffd94f22..c580139fcedec 100644
+--- a/net/sched/sch_cake.c
++++ b/net/sched/sch_cake.c
+@@ -2736,7 +2736,7 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt,
+ q->tins = kvcalloc(CAKE_MAX_TINS, sizeof(struct cake_tin_data),
+ GFP_KERNEL);
+ if (!q->tins)
+- goto nomem;
++ return -ENOMEM;
+
+ for (i = 0; i < CAKE_MAX_TINS; i++) {
+ struct cake_tin_data *b = q->tins + i;
+@@ -2766,10 +2766,6 @@ static int cake_init(struct Qdisc *sch, struct nlattr *opt,
+ q->min_netlen = ~0;
+ q->min_adjlen = ~0;
+ return 0;
+-
+-nomem:
+- cake_destroy(sch);
+- return -ENOMEM;
+ }
+
+ static int cake_dump(struct Qdisc *sch, struct sk_buff *skb)
+--
+2.33.0
+
--- /dev/null
+From 8f7a50d14a1f69b3ca9fbcd309d7310643507b2c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Dec 2021 16:36:00 +0800
+Subject: selftest/net/forwarding: declare NETIFS p9 p10
+
+From: Hangbin Liu <liuhangbin@gmail.com>
+
+[ Upstream commit 71da1aec215290e249d09c44c768df859f3a3bba ]
+
+The recent GRE selftests defined NUM_NETIFS=10. If the users copy
+forwarding.config.sample to forwarding.config directly, they will get
+error "Command line is not complete" when run the GRE tests, because
+create_netif_veth() failed with no interface name defined.
+
+Fix it by extending the NETIFS with p9 and p10.
+
+Fixes: 2800f2485417 ("selftests: forwarding: Test multipath hashing on inner IP pkts for GRE tunnel")
+Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
+Reviewed-by: Ido Schimmel <idosch@nvidia.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/forwarding/forwarding.config.sample | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/tools/testing/selftests/net/forwarding/forwarding.config.sample b/tools/testing/selftests/net/forwarding/forwarding.config.sample
+index e5e2fbeca22ec..e51def39fd801 100644
+--- a/tools/testing/selftests/net/forwarding/forwarding.config.sample
++++ b/tools/testing/selftests/net/forwarding/forwarding.config.sample
+@@ -13,6 +13,8 @@ NETIFS[p5]=veth4
+ NETIFS[p6]=veth5
+ NETIFS[p7]=veth6
+ NETIFS[p8]=veth7
++NETIFS[p9]=veth8
++NETIFS[p10]=veth9
+
+ # Port that does not have a cable connected.
+ NETIF_NO_CABLE=eth8
+--
+2.33.0
+
--- /dev/null
+From 45219688a3dd49dad7b4f6db3eb81d5ae94abb24 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Dec 2021 10:11:30 -0700
+Subject: selftests: Add duplicate config only for MD5 VRF tests
+
+From: David Ahern <dsahern@kernel.org>
+
+[ Upstream commit 7e0147592b5c4f9e2eb8c54a7857a56d4863f74e ]
+
+Commit referenced below added configuration in the default VRF that
+duplicates a VRF to check MD5 passwords are properly used and fail
+when expected. That config should not be added all the time as it
+can cause tests to pass that should not (by matching on default VRF
+setup when it should not). Move the duplicate setup to a function
+that is only called for the MD5 tests and add a cleanup function
+to remove it after the MD5 tests.
+
+Fixes: 5cad8bce26e0 ("fcnal-test: Add TCP MD5 tests for VRF")
+Signed-off-by: David Ahern <dsahern@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fcnal-test.sh | 26 +++++++++++++++++------
+ 1 file changed, 20 insertions(+), 6 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh
+index a830358ba2496..9f771f7e57450 100755
+--- a/tools/testing/selftests/net/fcnal-test.sh
++++ b/tools/testing/selftests/net/fcnal-test.sh
+@@ -446,6 +446,22 @@ cleanup()
+ ip netns del ${NSC} >/dev/null 2>&1
+ }
+
++cleanup_vrf_dup()
++{
++ ip link del ${NSA_DEV2} >/dev/null 2>&1
++ ip netns pids ${NSC} | xargs kill 2>/dev/null
++ ip netns del ${NSC} >/dev/null 2>&1
++}
++
++setup_vrf_dup()
++{
++ # some VRF tests use ns-C which has the same config as
++ # ns-B but for a device NOT in the VRF
++ create_ns ${NSC} "-" "-"
++ connect_ns ${NSA} ${NSA_DEV2} ${NSA_IP}/24 ${NSA_IP6}/64 \
++ ${NSC} ${NSC_DEV} ${NSB_IP}/24 ${NSB_IP6}/64
++}
++
+ setup()
+ {
+ local with_vrf=${1}
+@@ -475,12 +491,6 @@ setup()
+
+ ip -netns ${NSB} ro add ${VRF_IP}/32 via ${NSA_IP} dev ${NSB_DEV}
+ ip -netns ${NSB} -6 ro add ${VRF_IP6}/128 via ${NSA_IP6} dev ${NSB_DEV}
+-
+- # some VRF tests use ns-C which has the same config as
+- # ns-B but for a device NOT in the VRF
+- create_ns ${NSC} "-" "-"
+- connect_ns ${NSA} ${NSA_DEV2} ${NSA_IP}/24 ${NSA_IP6}/64 \
+- ${NSC} ${NSC_DEV} ${NSB_IP}/24 ${NSB_IP6}/64
+ else
+ ip -netns ${NSA} ro add ${NSB_LO_IP}/32 via ${NSB_IP} dev ${NSA_DEV}
+ ip -netns ${NSA} ro add ${NSB_LO_IP6}/128 via ${NSB_IP6} dev ${NSA_DEV}
+@@ -1177,7 +1187,9 @@ ipv4_tcp_vrf()
+ log_test_addr ${a} $? 1 "Global server, local connection"
+
+ # run MD5 tests
++ setup_vrf_dup
+ ipv4_tcp_md5
++ cleanup_vrf_dup
+
+ #
+ # enable VRF global server
+@@ -2656,7 +2668,9 @@ ipv6_tcp_vrf()
+ log_test_addr ${a} $? 1 "Global server, local connection"
+
+ # run MD5 tests
++ setup_vrf_dup
+ ipv6_tcp_md5
++ cleanup_vrf_dup
+
+ #
+ # enable VRF global server
+--
+2.33.0
+
--- /dev/null
+From 96dd0e772e7b64e46961d20efef0cbd2653ed180 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Dec 2021 11:26:16 -0700
+Subject: selftests: Fix IPv6 address bind tests
+
+From: David Ahern <dsahern@kernel.org>
+
+[ Upstream commit 28a2686c185e84b6aa6a4d9c9a972360eb7ca266 ]
+
+IPv6 allows binding a socket to a device then binding to an address
+not on the device (__inet6_bind -> ipv6_chk_addr with strict flag
+not set). Update the bind tests to reflect legacy behavior.
+
+Fixes: 34d0302ab861 ("selftests: Add ipv6 address bind tests to fcnal-test")
+Reported-by: Li Zhijian <lizhijian@fujitsu.com>
+Signed-off-by: David Ahern <dsahern@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fcnal-test.sh | 18 +++++++++++++-----
+ 1 file changed, 13 insertions(+), 5 deletions(-)
+
+diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh
+index dd67004a1d83a..ace976d891252 100755
+--- a/tools/testing/selftests/net/fcnal-test.sh
++++ b/tools/testing/selftests/net/fcnal-test.sh
+@@ -3366,11 +3366,14 @@ ipv6_addr_bind_novrf()
+ run_cmd nettest -6 -s -l ${a} -d ${NSA_DEV} -t1 -b
+ log_test_addr ${a} $? 0 "TCP socket bind to local address after device bind"
+
++ # Sadly, the kernel allows binding a socket to a device and then
++ # binding to an address not on the device. So this test passes
++ # when it really should not
+ a=${NSA_LO_IP6}
+ log_start
+- show_hint "Should fail with 'Cannot assign requested address'"
+- run_cmd nettest -6 -s -l ${a} -d ${NSA_DEV} -t1 -b
+- log_test_addr ${a} $? 1 "TCP socket bind to out of scope local address"
++ show_hint "Tecnically should fail since address is not on device but kernel allows"
++ run_cmd nettest -6 -s -l ${a} -I ${NSA_DEV} -t1 -b
++ log_test_addr ${a} $? 0 "TCP socket bind to out of scope local address"
+ }
+
+ ipv6_addr_bind_vrf()
+@@ -3411,10 +3414,15 @@ ipv6_addr_bind_vrf()
+ run_cmd nettest -6 -s -l ${a} -d ${NSA_DEV} -t1 -b
+ log_test_addr ${a} $? 0 "TCP socket bind to local address with device bind"
+
++ # Sadly, the kernel allows binding a socket to a device and then
++ # binding to an address not on the device. The only restriction
++ # is that the address is valid in the L3 domain. So this test
++ # passes when it really should not
+ a=${VRF_IP6}
+ log_start
+- run_cmd nettest -6 -s -l ${a} -d ${NSA_DEV} -t1 -b
+- log_test_addr ${a} $? 1 "TCP socket bind to VRF address with device bind"
++ show_hint "Tecnically should fail since address is not on device but kernel allows"
++ run_cmd nettest -6 -s -l ${a} -I ${NSA_DEV} -t1 -b
++ log_test_addr ${a} $? 0 "TCP socket bind to VRF address with device bind"
+
+ a=${NSA_LO_IP6}
+ log_start
+--
+2.33.0
+
--- /dev/null
+From 3780b2dbf5c42bbbea305d8e4b7ec64a38f1346f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 11 Dec 2021 10:21:08 -0700
+Subject: selftests: Fix raw socket bind tests with VRF
+
+From: David Ahern <dsahern@kernel.org>
+
+[ Upstream commit 0f108ae4452025fef529671998f6c7f1c4526790 ]
+
+Commit referenced below added negative socket bind tests for VRF. The
+socket binds should fail since the address to bind to is in a VRF yet
+the socket is not bound to the VRF or a device within it. Update the
+expected return code to check for 1 (bind failure) so the test passes
+when the bind fails as expected. Add a 'show_hint' comment to explain
+why the bind is expected to fail.
+
+Fixes: 75b2b2b3db4c ("selftests: Add ipv4 address bind tests to fcnal-test")
+Reported-by: Li Zhijian <lizhijian@fujitsu.com>
+Signed-off-by: David Ahern <dsahern@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fcnal-test.sh | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh
+index 9f771f7e57450..dd67004a1d83a 100755
+--- a/tools/testing/selftests/net/fcnal-test.sh
++++ b/tools/testing/selftests/net/fcnal-test.sh
+@@ -1747,8 +1747,9 @@ ipv4_addr_bind_vrf()
+ for a in ${NSA_IP} ${VRF_IP}
+ do
+ log_start
++ show_hint "Socket not bound to VRF, but address is in VRF"
+ run_cmd nettest -s -R -P icmp -l ${a} -b
+- log_test_addr ${a} $? 0 "Raw socket bind to local address"
++ log_test_addr ${a} $? 1 "Raw socket bind to local address"
+
+ log_start
+ run_cmd nettest -s -R -P icmp -l ${a} -d ${NSA_DEV} -b
+--
+2.33.0
+
--- /dev/null
+From 1b4cf2ce1639213405a9f5e6310f5c3e82fdb51d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 9 Dec 2021 10:02:30 +0800
+Subject: selftests: net: Correct ping6 expected rc from 2 to 1
+
+From: Jie2x Zhou <jie2x.zhou@intel.com>
+
+[ Upstream commit 92816e2629808726af015c7f5b14adc8e4f8b147 ]
+
+./fcnal-test.sh -v -t ipv6_ping
+TEST: ping out, VRF bind - ns-B IPv6 LLA [FAIL]
+TEST: ping out, VRF bind - multicast IP [FAIL]
+
+ping6 is failing as it should.
+COMMAND: ip netns exec ns-A /bin/ping6 -c1 -w1 fe80::7c4c:bcff:fe66:a63a%red
+strace of ping6 shows it is failing with '1',
+so change the expected rc from 2 to 1.
+
+Fixes: c0644e71df33 ("selftests: Add ipv6 ping tests to fcnal-test")
+Reported-by: kernel test robot <lkp@intel.com>
+Suggested-by: David Ahern <dsahern@gmail.com>
+Signed-off-by: Jie2x Zhou <jie2x.zhou@intel.com>
+Link: https://lore.kernel.org/r/20211209020230.37270-1-jie2x.zhou@intel.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/testing/selftests/net/fcnal-test.sh | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/testing/selftests/net/fcnal-test.sh b/tools/testing/selftests/net/fcnal-test.sh
+index 7c9ace9d15991..a830358ba2496 100755
+--- a/tools/testing/selftests/net/fcnal-test.sh
++++ b/tools/testing/selftests/net/fcnal-test.sh
+@@ -2128,7 +2128,7 @@ ipv6_ping_vrf()
+ log_start
+ show_hint "Fails since VRF device does not support linklocal or multicast"
+ run_cmd ${ping6} -c1 -w1 ${a}
+- log_test_addr ${a} $? 2 "ping out, VRF bind"
++ log_test_addr ${a} $? 1 "ping out, VRF bind"
+ done
+
+ for a in ${NSB_IP6} ${NSB_LO_IP6} ${NSB_LINKIP6}%${NSA_DEV} ${MCAST}%${NSA_DEV}
+--
+2.33.0
+
audit-improve-robustness-of-the-audit-queue-handling.patch
arm64-dts-imx8m-correct-assigned-clocks-for-fec.patch
arm64-dts-imx8mp-evk-improve-the-ethernet-phy-description.patch
+arm64-dts-rockchip-remove-mmc-hs400-enhanced-strobe-.patch
+arm64-dts-rockchip-fix-rk3308-roc-cc-vcc-sd-supply.patch
+arm64-dts-rockchip-fix-rk3399-leez-p710-vcc3v3-lan-s.patch
+arm64-dts-rockchip-fix-audio-supply-for-rock-pi-4.patch
+mac80211-track-only-qos-data-frames-for-admission-co.patch
+hv-utils-add-ptp_1588_clock-to-kconfig-to-fix-build.patch
+tee-amdtee-fix-an-is_err-vs-null-bug.patch
+ceph-fix-duplicate-increment-of-opened_inodes-metric.patch
+ceph-initialize-pathlen-variable-in-reconnect_caps_c.patch
+arm-socfpga-dts-fix-qspi-node-compatible.patch
+clk-don-t-parent-clks-until-the-parent-is-fully-regi.patch
+soc-imx-register-soc-device-only-on-i.mx-boards.patch
+virtio-vsock-fix-the-transport-to-work-with-vmaddr_c.patch
+selftests-net-correct-ping6-expected-rc-from-2-to-1.patch
+s390-kexec_file-fix-error-handling-when-applying-rel.patch
+sch_cake-do-not-call-cake_destroy-from-cake_init.patch
+inet_diag-fix-kernel-infoleak-for-udp-sockets.patch
+net-hns3-fix-use-after-free-bug-in-hclgevf_send_mbx_.patch
+selftests-add-duplicate-config-only-for-md5-vrf-test.patch
+selftests-fix-raw-socket-bind-tests-with-vrf.patch
+selftests-fix-ipv6-address-bind-tests.patch
+dmaengine-st_fdma-fix-module_alias.patch
+net-sched-sch_ets-don-t-remove-idle-classes-from-the.patch
+selftest-net-forwarding-declare-netifs-p9-p10.patch
+drm-ast-potential-dereference-of-null-pointer.patch
+mac80211-agg-tx-don-t-schedule_and_wake_txq-under-st.patch
+mac80211-fix-lookup-when-adding-addba-extension-elem.patch
+flow_offload-return-eopnotsupp-for-the-unsupported-m.patch
+rds-memory-leak-in-__rds_conn_create.patch
+xsk-do-not-sleep-in-poll-when-need_wakeup-set.patch
+drm-amd-pm-fix-a-potential-gpu_metrics_table-memory-.patch
+mptcp-clear-kern-flag-from-fallback-sockets.patch
+soc-tegra-fuse-fix-bitwise-vs.-logical-or-warning.patch
+igb-fix-removal-of-unicast-mac-filters-of-vfs.patch
+igbvf-fix-double-free-in-igbvf_probe.patch
+igc-fix-typo-in-i225-ltr-functions.patch
+ixgbe-document-how-to-enable-nbase-t-support.patch
+ixgbe-set-x550-mdio-speed-before-talking-to-phy.patch
+netdevsim-zero-initialize-memory-for-new-map-s-value.patch
+net-packet-rx_owner_map-depends-on-pg_vec.patch
+sfc_ef100-potential-dereference-of-null-pointer.patch
+net-fix-double-0x-prefix-print-in-skb-dump.patch
+net-smc-prevent-smc_release-from-long-blocking.patch
+net-systemport-add-global-locking-for-descriptor-lif.patch
+sit-do-not-call-ipip6_dev_free-from-sit_init_net.patch
+bpf-selftests-fix-racing-issue-in-btf_skc_cls_ingres.patch
--- /dev/null
+From 17b146dad243f35f9db3b9b3b664a4edb535a139 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Dec 2021 22:37:31 +0800
+Subject: sfc_ef100: potential dereference of null pointer
+
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+
+[ Upstream commit 407ecd1bd726f240123f704620d46e285ff30dd9 ]
+
+The return value of kmalloc() needs to be checked.
+To avoid use in efx_nic_update_stats() in case of the failure of alloc.
+
+Fixes: b593b6f1b492 ("sfc_ef100: statistics gathering")
+Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Reported-by: kernel test robot <lkp@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/sfc/ef100_nic.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/ethernet/sfc/ef100_nic.c b/drivers/net/ethernet/sfc/ef100_nic.c
+index 3148fe7703564..cb6897c2193c2 100644
+--- a/drivers/net/ethernet/sfc/ef100_nic.c
++++ b/drivers/net/ethernet/sfc/ef100_nic.c
+@@ -597,6 +597,9 @@ static size_t ef100_update_stats(struct efx_nic *efx,
+ ef100_common_stat_mask(mask);
+ ef100_ethtool_stat_mask(mask);
+
++ if (!mc_stats)
++ return 0;
++
+ efx_nic_copy_stats(efx, mc_stats);
+ efx_nic_update_stats(ef100_stat_desc, EF100_STAT_COUNT, mask,
+ stats, mc_stats, false);
+--
+2.33.0
+
--- /dev/null
+From 3f8598ad6db2e47e1293c25aa2f1dfea110485fe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 16 Dec 2021 03:17:41 -0800
+Subject: sit: do not call ipip6_dev_free() from sit_init_net()
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit e28587cc491ef0f3c51258fdc87fbc386b1d4c59 ]
+
+ipip6_dev_free is sit dev->priv_destructor, already called
+by register_netdevice() if something goes wrong.
+
+Alternative would be to make ipip6_dev_free() robust against
+multiple invocations, but other drivers do not implement this
+strategy.
+
+syzbot reported:
+
+dst_release underflow
+WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173
+Modules linked in:
+CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173
+Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48
+RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246
+RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000
+RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000
+RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c
+R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358
+R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000
+FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160
+ ipip6_dev_free net/ipv6/sit.c:1414 [inline]
+ sit_init_net+0x229/0x550 net/ipv6/sit.c:1936
+ ops_init+0x313/0x430 net/core/net_namespace.c:140
+ setup_net+0x35b/0x9d0 net/core/net_namespace.c:326
+ copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470
+ create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110
+ unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226
+ ksys_unshare+0x57d/0xb50 kernel/fork.c:3075
+ __do_sys_unshare kernel/fork.c:3146 [inline]
+ __se_sys_unshare kernel/fork.c:3144 [inline]
+ __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144
+ do_syscall_x64 arch/x86/entry/common.c:50 [inline]
+ do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
+ entry_SYSCALL_64_after_hwframe+0x44/0xae
+RIP: 0033:0x7f66c882ce99
+Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
+RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
+RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99
+RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200
+RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
+R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000
+ </TASK>
+
+Fixes: cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev state.")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Link: https://lore.kernel.org/r/20211216111741.1387540-1-eric.dumazet@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv6/sit.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
+index a6a3d759246ec..bab0e99f6e356 100644
+--- a/net/ipv6/sit.c
++++ b/net/ipv6/sit.c
+@@ -1924,7 +1924,6 @@ static int __net_init sit_init_net(struct net *net)
+ return 0;
+
+ err_reg_dev:
+- ipip6_dev_free(sitn->fb_tunnel_dev);
+ free_netdev(sitn->fb_tunnel_dev);
+ err_alloc_dev:
+ return err;
+--
+2.33.0
+
--- /dev/null
+From 3b40bf76152b050f80dfd556c355d9288dfdac29 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 6 Dec 2021 12:38:28 +0100
+Subject: soc: imx: Register SoC device only on i.MX boards
+
+From: Stephan Gerhold <stephan@gerhold.net>
+
+[ Upstream commit 4ebd29f91629e69da7d57390cdc953772eee03ab ]
+
+At the moment, using the ARM32 multi_v7_defconfig always results in two
+SoCs being exposed in sysfs. This is wrong, as far as I'm aware the
+Qualcomm DragonBoard 410c does not actually make use of a i.MX SoC. :)
+
+ qcom-db410c:/sys/devices/soc0$ grep . *
+ family:Freescale i.MX
+ machine:Qualcomm Technologies, Inc. APQ 8016 SBC
+ revision:0.0
+ serial_number:0000000000000000
+ soc_id:Unknown
+
+ qcom-db410c:/sys/devices/soc1$ grep . *
+ family:Snapdragon
+ machine:APQ8016
+ ...
+
+This happens because imx_soc_device_init() registers the soc device
+unconditionally, even when running on devices that do not make use of i.MX.
+Arnd already reported this more than a year ago and even suggested a fix
+similar to this commit, but for some reason it was never submitted.
+
+Fix it by checking if the "__mxc_cpu_type" variable was actually
+initialized by earlier platform code. On devices without i.MX it will
+simply stay 0.
+
+Cc: Peng Fan <peng.fan@nxp.com>
+Fixes: d2199b34871b ("ARM: imx: use device_initcall for imx_soc_device_init")
+Reported-by: Arnd Bergmann <arnd@arndb.de>
+Link: https://lore.kernel.org/r/CAK8P3a0hxO1TmK6oOMQ70AHSWJnP_CAq57YMOutrxkSYNjFeuw@mail.gmail.com/
+Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
+Reviewed-by: Fabio Estevam <festevam@gmail.com>
+Reviewed-by: Peng Fan <peng.fan@nxp.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/imx/soc-imx.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/soc/imx/soc-imx.c b/drivers/soc/imx/soc-imx.c
+index 01bfea1cb64a8..1e8780299d5c4 100644
+--- a/drivers/soc/imx/soc-imx.c
++++ b/drivers/soc/imx/soc-imx.c
+@@ -33,6 +33,10 @@ static int __init imx_soc_device_init(void)
+ u32 val;
+ int ret;
+
++ /* Return early if this is running on devices with different SoCs */
++ if (!__mxc_cpu_type)
++ return 0;
++
+ if (of_machine_is_compatible("fsl,ls1021a"))
+ return 0;
+
+--
+2.33.0
+
--- /dev/null
+From 2bffc6c44c43255be298fa404fd5b26964327cfb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 10 Dec 2021 09:55:29 -0700
+Subject: soc/tegra: fuse: Fix bitwise vs. logical OR warning
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+[ Upstream commit a7083763619f7485ccdade160deb81737cf2732f ]
+
+A new warning in clang points out two instances where boolean
+expressions are being used with a bitwise OR instead of logical OR:
+
+drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
+ reg = tegra_fuse_read_spare(i) |
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~
+ ||
+drivers/soc/tegra/fuse/speedo-tegra20.c:72:9: note: cast one or both operands to int to silence this warning
+drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
+ reg = tegra_fuse_read_spare(i) |
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~
+ ||
+drivers/soc/tegra/fuse/speedo-tegra20.c:87:9: note: cast one or both operands to int to silence this warning
+2 warnings generated.
+
+The motivation for the warning is that logical operations short circuit
+while bitwise operations do not.
+
+In this instance, tegra_fuse_read_spare() is not semantically returning
+a boolean, it is returning a bit value. Use u32 for its return type so
+that it can be used with either bitwise or boolean operators without any
+warnings.
+
+Fixes: 25cd5a391478 ("ARM: tegra: Add speedo-based process identification")
+Link: https://github.com/ClangBuiltLinux/linux/issues/1488
+Suggested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/soc/tegra/fuse/fuse-tegra.c | 2 +-
+ drivers/soc/tegra/fuse/fuse.h | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c b/drivers/soc/tegra/fuse/fuse-tegra.c
+index 94b60a692b515..4388a4a5e0919 100644
+--- a/drivers/soc/tegra/fuse/fuse-tegra.c
++++ b/drivers/soc/tegra/fuse/fuse-tegra.c
+@@ -260,7 +260,7 @@ static struct platform_driver tegra_fuse_driver = {
+ };
+ builtin_platform_driver(tegra_fuse_driver);
+
+-bool __init tegra_fuse_read_spare(unsigned int spare)
++u32 __init tegra_fuse_read_spare(unsigned int spare)
+ {
+ unsigned int offset = fuse->soc->info->spare + spare * 4;
+
+diff --git a/drivers/soc/tegra/fuse/fuse.h b/drivers/soc/tegra/fuse/fuse.h
+index e057a58e20603..21887a57cf2c2 100644
+--- a/drivers/soc/tegra/fuse/fuse.h
++++ b/drivers/soc/tegra/fuse/fuse.h
+@@ -63,7 +63,7 @@ struct tegra_fuse {
+ void tegra_init_revision(void);
+ void tegra_init_apbmisc(void);
+
+-bool __init tegra_fuse_read_spare(unsigned int spare);
++u32 __init tegra_fuse_read_spare(unsigned int spare);
+ u32 __init tegra_fuse_read_early(unsigned int offset);
+
+ u8 tegra_get_major_rev(void);
+--
+2.33.0
+
--- /dev/null
+From 7a885d098676cfacd3ab0bd6b1a0859b28a55726 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 24 Nov 2021 17:54:04 +0300
+Subject: tee: amdtee: fix an IS_ERR() vs NULL bug
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 9d7482771fac8d8e38e763263f2ca0ca12dd22c6 ]
+
+The __get_free_pages() function does not return error pointers it returns
+NULL so fix this condition to avoid a NULL dereference.
+
+Fixes: 757cc3e9ff1d ("tee: add AMD-TEE driver")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Acked-by: Rijo Thomas <Rijo-john.Thomas@amd.com>
+Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tee/amdtee/core.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/tee/amdtee/core.c b/drivers/tee/amdtee/core.c
+index da6b88e80dc07..297dc62bca298 100644
+--- a/drivers/tee/amdtee/core.c
++++ b/drivers/tee/amdtee/core.c
+@@ -203,9 +203,8 @@ static int copy_ta_binary(struct tee_context *ctx, void *ptr, void **ta,
+
+ *ta_size = roundup(fw->size, PAGE_SIZE);
+ *ta = (void *)__get_free_pages(GFP_KERNEL, get_order(*ta_size));
+- if (IS_ERR(*ta)) {
+- pr_err("%s: get_free_pages failed 0x%llx\n", __func__,
+- (u64)*ta);
++ if (!*ta) {
++ pr_err("%s: get_free_pages failed\n", __func__);
+ rc = -ENOMEM;
+ goto rel_fw;
+ }
+--
+2.33.0
+
--- /dev/null
+From 42d968e41a83b5ad0e85ccb82e532355dad0b847 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 25 Nov 2021 20:18:23 -0500
+Subject: virtio/vsock: fix the transport to work with VMADDR_CID_ANY
+
+From: Wei Wang <wei.w.wang@intel.com>
+
+[ Upstream commit 1db8f5fc2e5c66a5c51e1f6488e0ba7d45c29ae4 ]
+
+The VMADDR_CID_ANY flag used by a socket means that the socket isn't bound
+to any specific CID. For example, a host vsock server may want to be bound
+with VMADDR_CID_ANY, so that a guest vsock client can connect to the host
+server with CID=VMADDR_CID_HOST (i.e. 2), and meanwhile, a host vsock
+client can connect to the same local server with CID=VMADDR_CID_LOCAL
+(i.e. 1).
+
+The current implementation sets the destination socket's svm_cid to a
+fixed CID value after the first client's connection, which isn't an
+expected operation. For example, if the guest client first connects to the
+host server, the server's svm_cid gets set to VMADDR_CID_HOST, then other
+host clients won't be able to connect to the server anymore.
+
+Reproduce steps:
+1. Run the host server:
+ socat VSOCK-LISTEN:1234,fork -
+2. Run a guest client to connect to the host server:
+ socat - VSOCK-CONNECT:2:1234
+3. Run a host client to connect to the host server:
+ socat - VSOCK-CONNECT:1:1234
+
+Without this patch, step 3. above fails to connect, and socat complains
+"socat[1720] E connect(5, AF=40 cid:1 port:1234, 16): Connection
+reset by peer".
+With this patch, the above works well.
+
+Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")
+Signed-off-by: Wei Wang <wei.w.wang@intel.com>
+Link: https://lore.kernel.org/r/20211126011823.1760-1-wei.w.wang@intel.com
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
+index 902cb6dd710bd..d6d3a05c008a4 100644
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -1153,7 +1153,8 @@ void virtio_transport_recv_pkt(struct virtio_transport *t,
+ space_available = virtio_transport_space_update(sk, pkt);
+
+ /* Update CID in case it has changed after a transport reset event */
+- vsk->local_addr.svm_cid = dst.svm_cid;
++ if (vsk->local_addr.svm_cid != VMADDR_CID_ANY)
++ vsk->local_addr.svm_cid = dst.svm_cid;
+
+ if (space_available)
+ sk->sk_write_space(sk);
+--
+2.33.0
+
--- /dev/null
+From cfb6a332c22618f9f86a4484e68c2c10792a6b11 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Dec 2021 11:26:07 +0100
+Subject: xsk: Do not sleep in poll() when need_wakeup set
+
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+
+[ Upstream commit bd0687c18e635b63233dc87f38058cd728802ab4 ]
+
+Do not sleep in poll() when the need_wakeup flag is set. When this
+flag is set, the application needs to explicitly wake up the driver
+with a syscall (poll, recvmsg, sendmsg, etc.) to guarantee that Rx
+and/or Tx processing will be processed promptly. But the current code
+in poll(), sleeps first then wakes up the driver. This means that no
+driver processing will occur (baring any interrupts) until the timeout
+has expired.
+
+Fix this by checking the need_wakeup flag first and if set, wake the
+driver and return to the application. Only if need_wakeup is not set
+should the process sleep if there is a timeout set in the poll() call.
+
+Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings")
+Reported-by: Keith Wiles <keith.wiles@intel.com>
+Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Link: https://lore.kernel.org/bpf/20211214102607.7677-1-magnus.karlsson@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/xdp/xsk.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
+index ca4716b92774b..12112f4b9f7ce 100644
+--- a/net/xdp/xsk.c
++++ b/net/xdp/xsk.c
+@@ -499,8 +499,6 @@ static __poll_t xsk_poll(struct file *file, struct socket *sock,
+ struct xdp_sock *xs = xdp_sk(sk);
+ struct xsk_buff_pool *pool;
+
+- sock_poll_wait(file, sock, wait);
+-
+ if (unlikely(!xsk_is_bound(xs)))
+ return mask;
+
+@@ -512,6 +510,8 @@ static __poll_t xsk_poll(struct file *file, struct socket *sock,
+ else
+ /* Poll needs to drive Tx also in copy mode */
+ __xsk_sendmsg(sk);
++ } else {
++ sock_poll_wait(file, sock, wait);
+ }
+
+ if (xs->rx && !xskq_prod_is_empty(xs->rx))
+--
+2.33.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
