Fixes for 4.9

Signed-off-by: Sasha Levin <sashal@kernel.org>
diff --git a/queue-4.9/arm-9196-1-spectre-bhb-enable-for-cortex-a15.patch b/queue-4.9/arm-9196-1-spectre-bhb-enable-for-cortex-a15.patch
new file mode 100644
index 0000000..c8c27ae
--- /dev/null
+++ b/queue-4.9/arm-9196-1-spectre-bhb-enable-for-cortex-a15.patch
@@ -0,0 +1,36 @@
+From 0aad4203103c081af9d9338ec84dd143e51e03de Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 20 Apr 2022 09:44:51 +0100
+Subject: ARM: 9196/1: spectre-bhb: enable for Cortex-A15
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+[ Upstream commit 0dc14aa94ccd8ba35eb17a0f9b123d1566efd39e ]
+
+The Spectre-BHB mitigations were inadvertently left disabled for
+Cortex-A15, due to the fact that cpu_v7_bugs_init() is not called in
+that case. So fix that.
+
+Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/mm/proc-v7-bugs.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm/mm/proc-v7-bugs.c b/arch/arm/mm/proc-v7-bugs.c
+index 1b6e770bc1cd..8b78694d56b8 100644
+--- a/arch/arm/mm/proc-v7-bugs.c
++++ b/arch/arm/mm/proc-v7-bugs.c
+@@ -297,6 +297,7 @@ void cpu_v7_ca15_ibe(void)
+ {
+ 	if (check_spectre_auxcr(this_cpu_ptr(&spectre_warned), BIT(0)))
+ 		cpu_v7_spectre_v2_init();
++	cpu_v7_spectre_bhb_init();
+ }
+ 
+ void cpu_v7_bugs_init(void)
+-- 
+2.35.1
+
diff --git a/queue-4.9/arm-9197-1-spectre-bhb-fix-loop8-sequence-for-thumb2.patch b/queue-4.9/arm-9197-1-spectre-bhb-fix-loop8-sequence-for-thumb2.patch
new file mode 100644
index 0000000..3f0b19e
--- /dev/null
+++ b/queue-4.9/arm-9197-1-spectre-bhb-fix-loop8-sequence-for-thumb2.patch
@@ -0,0 +1,37 @@
+From c001b31da5fb36916044492e7cb1168dd59e6399 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 20 Apr 2022 09:46:17 +0100
+Subject: ARM: 9197/1: spectre-bhb: fix loop8 sequence for Thumb2
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+[ Upstream commit 3cfb3019979666bdf33a1010147363cf05e0f17b ]
+
+In Thumb2, 'b . + 4' produces a branch instruction that uses a narrow
+encoding, and so it does not jump to the following instruction as
+expected. So use W(b) instead.
+
+Fixes: 6c7cb60bff7a ("ARM: fix Thumb2 regression with Spectre BHB")
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/arm/kernel/entry-armv.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
+index 77ec669fd5ee..247229e69322 100644
+--- a/arch/arm/kernel/entry-armv.S
++++ b/arch/arm/kernel/entry-armv.S
+@@ -1074,7 +1074,7 @@ vector_bhb_loop8_\name:
+ 
+ 	@ bhb workaround
+ 	mov	r0, #8
+-3:	b	. + 4
++3:	W(b)	. + 4
+ 	subs	r0, r0, #1
+ 	bne	3b
+ 	dsb
+-- 
+2.35.1
+
diff --git a/queue-4.9/ethernet-tulip-fix-missing-pci_disable_device-on-err.patch b/queue-4.9/ethernet-tulip-fix-missing-pci_disable_device-on-err.patch
new file mode 100644
index 0000000..c608b8f
--- /dev/null
+++ b/queue-4.9/ethernet-tulip-fix-missing-pci_disable_device-on-err.patch
@@ -0,0 +1,49 @@
+From 48c15905ae341156e1ca77a62102cd3472dcda9c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 6 May 2022 17:42:50 +0800
+Subject: ethernet: tulip: fix missing pci_disable_device() on error in
+ tulip_init_one()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 51ca86b4c9c7c75f5630fa0dbe5f8f0bd98e3c3e ]
+
+Fix the missing pci_disable_device() before return
+from tulip_init_one() in the error handling case.
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Link: https://lore.kernel.org/r/20220506094250.3630615-1-yangyingliang@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/dec/tulip/tulip_core.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c b/drivers/net/ethernet/dec/tulip/tulip_core.c
+index bbde90bc74fe..6224f9d22298 100644
+--- a/drivers/net/ethernet/dec/tulip/tulip_core.c
++++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
+@@ -1412,8 +1412,10 @@ static int tulip_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
+ 
+ 	/* alloc_etherdev ensures aligned and zeroed private structures */
+ 	dev = alloc_etherdev (sizeof (*tp));
+-	if (!dev)
++	if (!dev) {
++		pci_disable_device(pdev);
+ 		return -ENOMEM;
++	}
+ 
+ 	SET_NETDEV_DEV(dev, &pdev->dev);
+ 	if (pci_resource_len (pdev, 0) < tulip_tbl[chip_idx].io_size) {
+@@ -1792,6 +1794,7 @@ static int tulip_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
+ 
+ err_out_free_netdev:
+ 	free_netdev (dev);
++	pci_disable_device(pdev);
+ 	return -ENODEV;
+ }
+ 
+-- 
+2.35.1
+
diff --git a/queue-4.9/igb-skip-phy-status-check-where-unavailable.patch b/queue-4.9/igb-skip-phy-status-check-where-unavailable.patch
new file mode 100644
index 0000000..10bf4c1
--- /dev/null
+++ b/queue-4.9/igb-skip-phy-status-check-where-unavailable.patch
@@ -0,0 +1,46 @@
+From 49c73e51ad903eb64a18d1588d7f4e40f5d7165c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 17 May 2022 11:01:05 -0700
+Subject: igb: skip phy status check where unavailable
+
+From: Kevin Mitchell <kevmitch@arista.com>
+
+[ Upstream commit 942d2ad5d2e0df758a645ddfadffde2795322728 ]
+
+igb_read_phy_reg() will silently return, leaving phy_data untouched, if
+hw->ops.read_reg isn't set. Depending on the uninitialized value of
+phy_data, this led to the phy status check either succeeding immediately
+or looping continuously for 2 seconds before emitting a noisy err-level
+timeout. This message went out to the console even though there was no
+actual problem.
+
+Instead, first check if there is read_reg function pointer. If not,
+proceed without trying to check the phy status register.
+
+Fixes: b72f3f72005d ("igb: When GbE link up, wait for Remote receiver status condition")
+Signed-off-by: Kevin Mitchell <kevmitch@arista.com>
+Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
+index 6bede6774486..d825e527ec1a 100644
+--- a/drivers/net/ethernet/intel/igb/igb_main.c
++++ b/drivers/net/ethernet/intel/igb/igb_main.c
+@@ -4546,7 +4546,8 @@ static void igb_watchdog_task(struct work_struct *work)
+ 				break;
+ 			}
+ 
+-			if (adapter->link_speed != SPEED_1000)
++			if (adapter->link_speed != SPEED_1000 ||
++			    !hw->phy.ops.read_reg)
+ 				goto no_wait;
+ 
+ 			/* wait for Remote receiver status OK */
+-- 
+2.35.1
+
diff --git a/queue-4.9/mac80211-fix-rx-reordering-with-non-explicit-psmp-ac.patch b/queue-4.9/mac80211-fix-rx-reordering-with-non-explicit-psmp-ac.patch
new file mode 100644
index 0000000..a85550f
--- /dev/null
+++ b/queue-4.9/mac80211-fix-rx-reordering-with-non-explicit-psmp-ac.patch
@@ -0,0 +1,38 @@
+From 6d81e5846c2ea7c59f9dbcbecda4fefe773eb3ef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 20 Apr 2022 12:50:38 +0200
+Subject: mac80211: fix rx reordering with non explicit / psmp ack policy
+
+From: Felix Fietkau <nbd@nbd.name>
+
+[ Upstream commit 5e469ed9764d4722c59562da13120bd2dc6834c5 ]
+
+When the QoS ack policy was set to non explicit / psmp ack, frames are treated
+as not being part of a BA session, which causes extra latency on reordering.
+Fix this by only bypassing reordering for packets with no-ack policy
+
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Link: https://lore.kernel.org/r/20220420105038.36443-1-nbd@nbd.name
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/mac80211/rx.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
+index 41af02a70742..02845bed07d7 100644
+--- a/net/mac80211/rx.c
++++ b/net/mac80211/rx.c
+@@ -1179,8 +1179,7 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx,
+ 		goto dont_reorder;
+ 
+ 	/* not part of a BA session */
+-	if (ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_BLOCKACK &&
+-	    ack_policy != IEEE80211_QOS_CTL_ACK_POLICY_NORMAL)
++	if (ack_policy == IEEE80211_QOS_CTL_ACK_POLICY_NOACK)
+ 		goto dont_reorder;
+ 
+ 	/* new, potentially un-ordered, ampdu frame - process it */
+-- 
+2.35.1
+
diff --git a/queue-4.9/net-af_key-add-check-for-pfkey_broadcast-in-function.patch b/queue-4.9/net-af_key-add-check-for-pfkey_broadcast-in-function.patch
new file mode 100644
index 0000000..d8cf407
--- /dev/null
+++ b/queue-4.9/net-af_key-add-check-for-pfkey_broadcast-in-function.patch
@@ -0,0 +1,42 @@
+From 8b425f41c89b058e9e7d5382de53beb7cba99d25 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 17 May 2022 17:42:31 +0800
+Subject: net: af_key: add check for pfkey_broadcast in function pfkey_process
+
+From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+
+[ Upstream commit 4dc2a5a8f6754492180741facf2a8787f2c415d7 ]
+
+If skb_clone() returns null pointer, pfkey_broadcast() will
+return error.
+Therefore, it should be better to check the return value of
+pfkey_broadcast() and return error if fails.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/key/af_key.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/net/key/af_key.c b/net/key/af_key.c
+index c9cc9f75b099..776f94ecbfe6 100644
+--- a/net/key/af_key.c
++++ b/net/key/af_key.c
+@@ -2861,8 +2861,10 @@ static int pfkey_process(struct sock *sk, struct sk_buff *skb, const struct sadb
+ 	void *ext_hdrs[SADB_EXT_MAX];
+ 	int err;
+ 
+-	pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL,
+-			BROADCAST_PROMISC_ONLY, NULL, sock_net(sk));
++	err = pfkey_broadcast(skb_clone(skb, GFP_KERNEL), GFP_KERNEL,
++			      BROADCAST_PROMISC_ONLY, NULL, sock_net(sk));
++	if (err)
++		return err;
+ 
+ 	memset(ext_hdrs, 0, sizeof(ext_hdrs));
+ 	err = parse_exthdrs(skb, hdr, ext_hdrs);
+-- 
+2.35.1
+
diff --git a/queue-4.9/net-qla3xxx-fix-a-test-in-ql_reset_work.patch b/queue-4.9/net-qla3xxx-fix-a-test-in-ql_reset_work.patch
new file mode 100644
index 0000000..64f576e
--- /dev/null
+++ b/queue-4.9/net-qla3xxx-fix-a-test-in-ql_reset_work.patch
@@ -0,0 +1,48 @@
+From 7117770c8b96c02c95438e013a1ffae45cf2fa83 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 15 May 2022 20:07:02 +0200
+Subject: net/qla3xxx: Fix a test in ql_reset_work()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit 5361448e45fac6fb96738df748229432a62d78b6 ]
+
+test_bit() tests if one bit is set or not.
+Here the logic seems to check of bit QL_RESET_PER_SCSI (i.e. 4) OR bit
+QL_RESET_START (i.e. 3) is set.
+
+In fact, it checks if bit 7 (4 | 3 = 7) is set, that is to say
+QL_ADAPTER_UP.
+
+This looks harmless, because this bit is likely be set, and when the
+ql_reset_work() delayed work is scheduled in ql3xxx_isr() (the only place
+that schedule this work), QL_RESET_START or QL_RESET_PER_SCSI is set.
+
+This has been spotted by smatch.
+
+Fixes: 5a4faa873782 ("[PATCH] qla3xxx NIC driver")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Link: https://lore.kernel.org/r/80e73e33f390001d9c0140ffa9baddf6466a41a2.1652637337.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qla3xxx.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c
+index 147effc16316..e62e3a9d5249 100644
+--- a/drivers/net/ethernet/qlogic/qla3xxx.c
++++ b/drivers/net/ethernet/qlogic/qla3xxx.c
+@@ -3625,7 +3625,8 @@ static void ql_reset_work(struct work_struct *work)
+ 		qdev->mem_map_registers;
+ 	unsigned long hw_flags;
+ 
+-	if (test_bit((QL_RESET_PER_SCSI | QL_RESET_START), &qdev->flags)) {
++	if (test_bit(QL_RESET_PER_SCSI, &qdev->flags) ||
++	    test_bit(QL_RESET_START, &qdev->flags)) {
+ 		clear_bit(QL_LINK_MASTER, &qdev->flags);
+ 
+ 		/*
+-- 
+2.35.1
+
diff --git a/queue-4.9/net-stmmac-fix-missing-pci_disable_device-on-error-i.patch b/queue-4.9/net-stmmac-fix-missing-pci_disable_device-on-error-i.patch
new file mode 100644
index 0000000..e8552fb
--- /dev/null
+++ b/queue-4.9/net-stmmac-fix-missing-pci_disable_device-on-error-i.patch
@@ -0,0 +1,46 @@
+From 52acf7596b14e5b1b8fe18a801a2746df48c829f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 10 May 2022 11:13:16 +0800
+Subject: net: stmmac: fix missing pci_disable_device() on error in
+ stmmac_pci_probe()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 0807ce0b010418a191e0e4009803b2d74c3245d5 ]
+
+Switch to using pcim_enable_device() to avoid missing pci_disable_device().
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Link: https://lore.kernel.org/r/20220510031316.1780409-1-yangyingliang@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+index 49eaede34eea..9beb93479e28 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+@@ -183,7 +183,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
+ 		return -ENOMEM;
+ 
+ 	/* Enable pci device */
+-	ret = pci_enable_device(pdev);
++	ret = pcim_enable_device(pdev);
+ 	if (ret) {
+ 		dev_err(&pdev->dev, "%s: ERROR: failed to enable device\n",
+ 			__func__);
+@@ -241,8 +241,6 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
+ 		pcim_iounmap_regions(pdev, BIT(i));
+ 		break;
+ 	}
+-
+-	pci_disable_device(pdev);
+ }
+ 
+ static int stmmac_pci_suspend(struct device *dev)
+-- 
+2.35.1
+
diff --git a/queue-4.9/net-vmxnet3-fix-possible-null-pointer-dereference-in.patch b/queue-4.9/net-vmxnet3-fix-possible-null-pointer-dereference-in.patch
new file mode 100644
index 0000000..889d00a
--- /dev/null
+++ b/queue-4.9/net-vmxnet3-fix-possible-null-pointer-dereference-in.patch
@@ -0,0 +1,68 @@
+From f877c41bc2e6b7f1bd379e884e6d1c1c923f38b8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 14 May 2022 13:07:11 +0800
+Subject: net: vmxnet3: fix possible NULL pointer dereference in
+ vmxnet3_rq_cleanup()
+
+From: Zixuan Fu <r33s3n6@gmail.com>
+
+[ Upstream commit edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd ]
+
+In vmxnet3_rq_create(), when dma_alloc_coherent() fails,
+vmxnet3_rq_destroy() is called. It sets rq->rx_ring[i].base to NULL. Then
+vmxnet3_rq_create() returns an error to its callers mxnet3_rq_create_all()
+-> vmxnet3_change_mtu(). Then vmxnet3_change_mtu() calls
+vmxnet3_force_close() -> dev_close() in error handling code. And the driver
+calls vmxnet3_close() -> vmxnet3_quiesce_dev() -> vmxnet3_rq_cleanup_all()
+-> vmxnet3_rq_cleanup(). In vmxnet3_rq_cleanup(),
+rq->rx_ring[ring_idx].base is accessed, but this variable is NULL, causing
+a NULL pointer dereference.
+
+To fix this possible bug, an if statement is added to check whether
+rq->rx_ring[0].base is NULL in vmxnet3_rq_cleanup() and exit early if so.
+
+The error log in our fault-injection testing is shown as follows:
+
+[   65.220135] BUG: kernel NULL pointer dereference, address: 0000000000000008
+...
+[   65.222633] RIP: 0010:vmxnet3_rq_cleanup_all+0x396/0x4e0 [vmxnet3]
+...
+[   65.227977] Call Trace:
+...
+[   65.228262]  vmxnet3_quiesce_dev+0x80f/0x8a0 [vmxnet3]
+[   65.228580]  vmxnet3_close+0x2c4/0x3f0 [vmxnet3]
+[   65.228866]  __dev_close_many+0x288/0x350
+[   65.229607]  dev_close_many+0xa4/0x480
+[   65.231124]  dev_close+0x138/0x230
+[   65.231933]  vmxnet3_force_close+0x1f0/0x240 [vmxnet3]
+[   65.232248]  vmxnet3_change_mtu+0x75d/0x920 [vmxnet3]
+...
+
+Fixes: d1a890fa37f27 ("net: VMware virtual Ethernet NIC driver: vmxnet3")
+Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
+Signed-off-by: Zixuan Fu <r33s3n6@gmail.com>
+Link: https://lore.kernel.org/r/20220514050711.2636709-1-r33s3n6@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
+index b76404d0657e..cce959f281b7 100644
+--- a/drivers/net/vmxnet3/vmxnet3_drv.c
++++ b/drivers/net/vmxnet3/vmxnet3_drv.c
+@@ -1573,6 +1573,10 @@ vmxnet3_rq_cleanup(struct vmxnet3_rx_queue *rq,
+ 	u32 i, ring_idx;
+ 	struct Vmxnet3_RxDesc *rxd;
+ 
++	/* ring has already been cleaned up */
++	if (!rq->rx_ring[0].base)
++		return;
++
+ 	for (ring_idx = 0; ring_idx < 2; ring_idx++) {
+ 		for (i = 0; i < rq->rx_ring[ring_idx].size; i++) {
+ #ifdef __BIG_ENDIAN_BITFIELD
+-- 
+2.35.1
+
diff --git a/queue-4.9/net-vmxnet3-fix-possible-use-after-free-bugs-in-vmxn.patch b/queue-4.9/net-vmxnet3-fix-possible-use-after-free-bugs-in-vmxn.patch
new file mode 100644
index 0000000..d4d8742
--- /dev/null
+++ b/queue-4.9/net-vmxnet3-fix-possible-use-after-free-bugs-in-vmxn.patch
@@ -0,0 +1,94 @@
+From d6f25d37ed6c6889db3ea48e87e6df6fcc554888 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 14 May 2022 13:06:56 +0800
+Subject: net: vmxnet3: fix possible use-after-free bugs in
+ vmxnet3_rq_alloc_rx_buf()
+
+From: Zixuan Fu <r33s3n6@gmail.com>
+
+[ Upstream commit 9e7fef9521e73ca8afd7da9e58c14654b02dfad8 ]
+
+In vmxnet3_rq_alloc_rx_buf(), when dma_map_single() fails, rbi->skb is
+freed immediately. Similarly, in another branch, when dma_map_page() fails,
+rbi->page is also freed. In the two cases, vmxnet3_rq_alloc_rx_buf()
+returns an error to its callers vmxnet3_rq_init() -> vmxnet3_rq_init_all()
+-> vmxnet3_activate_dev(). Then vmxnet3_activate_dev() calls
+vmxnet3_rq_cleanup_all() in error handling code, and rbi->skb or rbi->page
+are freed again in vmxnet3_rq_cleanup_all(), causing use-after-free bugs.
+
+To fix these possible bugs, rbi->skb and rbi->page should be cleared after
+they are freed.
+
+The error log in our fault-injection testing is shown as follows:
+
+[   14.319016] BUG: KASAN: use-after-free in consume_skb+0x2f/0x150
+...
+[   14.321586] Call Trace:
+...
+[   14.325357]  consume_skb+0x2f/0x150
+[   14.325671]  vmxnet3_rq_cleanup_all+0x33a/0x4e0 [vmxnet3]
+[   14.326150]  vmxnet3_activate_dev+0xb9d/0x2ca0 [vmxnet3]
+[   14.326616]  vmxnet3_open+0x387/0x470 [vmxnet3]
+...
+[   14.361675] Allocated by task 351:
+...
+[   14.362688]  __netdev_alloc_skb+0x1b3/0x6f0
+[   14.362960]  vmxnet3_rq_alloc_rx_buf+0x1b0/0x8d0 [vmxnet3]
+[   14.363317]  vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3]
+[   14.363661]  vmxnet3_open+0x387/0x470 [vmxnet3]
+...
+[   14.367309]
+[   14.367412] Freed by task 351:
+...
+[   14.368932]  __dev_kfree_skb_any+0xd2/0xe0
+[   14.369193]  vmxnet3_rq_alloc_rx_buf+0x71e/0x8d0 [vmxnet3]
+[   14.369544]  vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3]
+[   14.369883]  vmxnet3_open+0x387/0x470 [vmxnet3]
+[   14.370174]  __dev_open+0x28a/0x420
+[   14.370399]  __dev_change_flags+0x192/0x590
+[   14.370667]  dev_change_flags+0x7a/0x180
+[   14.370919]  do_setlink+0xb28/0x3570
+[   14.371150]  rtnl_newlink+0x1160/0x1740
+[   14.371399]  rtnetlink_rcv_msg+0x5bf/0xa50
+[   14.371661]  netlink_rcv_skb+0x1cd/0x3e0
+[   14.371913]  netlink_unicast+0x5dc/0x840
+[   14.372169]  netlink_sendmsg+0x856/0xc40
+[   14.372420]  ____sys_sendmsg+0x8a7/0x8d0
+[   14.372673]  __sys_sendmsg+0x1c2/0x270
+[   14.372914]  do_syscall_64+0x41/0x90
+[   14.373145]  entry_SYSCALL_64_after_hwframe+0x44/0xae
+...
+
+Fixes: 5738a09d58d5a ("vmxnet3: fix checks for dma mapping errors")
+Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
+Signed-off-by: Zixuan Fu <r33s3n6@gmail.com>
+Link: https://lore.kernel.org/r/20220514050656.2636588-1-r33s3n6@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/vmxnet3/vmxnet3_drv.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
+index 56a8031b56b3..b76404d0657e 100644
+--- a/drivers/net/vmxnet3/vmxnet3_drv.c
++++ b/drivers/net/vmxnet3/vmxnet3_drv.c
+@@ -595,6 +595,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
+ 				if (dma_mapping_error(&adapter->pdev->dev,
+ 						      rbi->dma_addr)) {
+ 					dev_kfree_skb_any(rbi->skb);
++					rbi->skb = NULL;
+ 					rq->stats.rx_buf_alloc_failure++;
+ 					break;
+ 				}
+@@ -619,6 +620,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
+ 				if (dma_mapping_error(&adapter->pdev->dev,
+ 						      rbi->dma_addr)) {
+ 					put_page(rbi->page);
++					rbi->page = NULL;
+ 					rq->stats.rx_buf_alloc_failure++;
+ 					break;
+ 				}
+-- 
+2.35.1
+
diff --git a/queue-4.9/nfc-nci-fix-sleep-in-atomic-context-bugs-caused-by-n.patch b/queue-4.9/nfc-nci-fix-sleep-in-atomic-context-bugs-caused-by-n.patch
new file mode 100644
index 0000000..301c03f
--- /dev/null
+++ b/queue-4.9/nfc-nci-fix-sleep-in-atomic-context-bugs-caused-by-n.patch
@@ -0,0 +1,81 @@
+From ada75cc56eae6cf7d3760b2f81be44b90a2d7ac7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 17 May 2022 09:25:30 +0800
+Subject: NFC: nci: fix sleep in atomic context bugs caused by nci_skb_alloc
+
+From: Duoming Zhou <duoming@zju.edu.cn>
+
+[ Upstream commit 23dd4581350d4ffa23d58976ec46408f8f4c1e16 ]
+
+There are sleep in atomic context bugs when the request to secure
+element of st-nci is timeout. The root cause is that nci_skb_alloc
+with GFP_KERNEL parameter is called in st_nci_se_wt_timeout which is
+a timer handler. The call paths that could trigger bugs are shown below:
+
+    (interrupt context 1)
+st_nci_se_wt_timeout
+  nci_hci_send_event
+    nci_hci_send_data
+      nci_skb_alloc(..., GFP_KERNEL) //may sleep
+
+   (interrupt context 2)
+st_nci_se_wt_timeout
+  nci_hci_send_event
+    nci_hci_send_data
+      nci_send_data
+        nci_queue_tx_data_frags
+          nci_skb_alloc(..., GFP_KERNEL) //may sleep
+
+This patch changes allocation mode of nci_skb_alloc from GFP_KERNEL to
+GFP_ATOMIC in order to prevent atomic context sleeping. The GFP_ATOMIC
+flag makes memory allocation operation could be used in atomic context.
+
+Fixes: ed06aeefdac3 ("nfc: st-nci: Rename st21nfcb to st-nci")
+Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20220517012530.75714-1-duoming@zju.edu.cn
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/nfc/nci/data.c | 2 +-
+ net/nfc/nci/hci.c  | 4 ++--
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
+index d20383779710..b8a295dd15d8 100644
+--- a/net/nfc/nci/data.c
++++ b/net/nfc/nci/data.c
+@@ -130,7 +130,7 @@ static int nci_queue_tx_data_frags(struct nci_dev *ndev,
+ 
+ 		skb_frag = nci_skb_alloc(ndev,
+ 					 (NCI_DATA_HDR_SIZE + frag_len),
+-					 GFP_KERNEL);
++					 GFP_ATOMIC);
+ 		if (skb_frag == NULL) {
+ 			rc = -ENOMEM;
+ 			goto free_exit;
+diff --git a/net/nfc/nci/hci.c b/net/nfc/nci/hci.c
+index 5fae3f064ad0..9c37618f36c6 100644
+--- a/net/nfc/nci/hci.c
++++ b/net/nfc/nci/hci.c
+@@ -165,7 +165,7 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,
+ 
+ 	i = 0;
+ 	skb = nci_skb_alloc(ndev, conn_info->max_pkt_payload_len +
+-			    NCI_DATA_HDR_SIZE, GFP_KERNEL);
++			    NCI_DATA_HDR_SIZE, GFP_ATOMIC);
+ 	if (!skb)
+ 		return -ENOMEM;
+ 
+@@ -198,7 +198,7 @@ static int nci_hci_send_data(struct nci_dev *ndev, u8 pipe,
+ 		if (i < data_len) {
+ 			skb = nci_skb_alloc(ndev,
+ 					    conn_info->max_pkt_payload_len +
+-					    NCI_DATA_HDR_SIZE, GFP_KERNEL);
++					    NCI_DATA_HDR_SIZE, GFP_ATOMIC);
+ 			if (!skb)
+ 				return -ENOMEM;
+ 
+-- 
+2.35.1
+
diff --git a/queue-4.9/perf-bench-numa-address-compiler-error-on-s390.patch b/queue-4.9/perf-bench-numa-address-compiler-error-on-s390.patch
new file mode 100644
index 0000000..df34ebc
--- /dev/null
+++ b/queue-4.9/perf-bench-numa-address-compiler-error-on-s390.patch
@@ -0,0 +1,67 @@
+From 646f988402063d824677ff9842252431bb6ff756 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 May 2022 10:11:58 +0200
+Subject: perf bench numa: Address compiler error on s390
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Richter <tmricht@linux.ibm.com>
+
+[ Upstream commit f8ac1c478424a9a14669b8cef7389b1e14e5229d ]
+
+The compilation on s390 results in this error:
+
+  # make DEBUG=y bench/numa.o
+  ...
+  bench/numa.c: In function ‘__bench_numa’:
+  bench/numa.c:1749:81: error: ‘%d’ directive output may be truncated
+              writing between 1 and 11 bytes into a region of size between
+              10 and 20 [-Werror=format-truncation=]
+  1749 |        snprintf(tname, sizeof(tname), "process%d:thread%d", p, t);
+                                                               ^~
+  ...
+  bench/numa.c:1749:64: note: directive argument in the range
+                 [-2147483647, 2147483646]
+  ...
+  #
+
+The maximum length of the %d replacement is 11 characters because of the
+negative sign.  Therefore extend the array by two more characters.
+
+Output after:
+
+  # make  DEBUG=y bench/numa.o > /dev/null 2>&1; ll bench/numa.o
+  -rw-r--r-- 1 root root 418320 May 19 09:11 bench/numa.o
+  #
+
+Fixes: 3aff8ba0a4c9c919 ("perf bench numa: Avoid possible truncation when using snprintf()")
+Suggested-by: Namhyung Kim <namhyung@gmail.com>
+Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
+Cc: Heiko Carstens <hca@linux.ibm.com>
+Cc: Sumanth Korikkar <sumanthk@linux.ibm.com>
+Cc: Sven Schnelle <svens@linux.ibm.com>
+Cc: Vasily Gorbik <gor@linux.ibm.com>
+Link: https://lore.kernel.org/r/20220520081158.2990006-1-tmricht@linux.ibm.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/bench/numa.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/perf/bench/numa.c b/tools/perf/bench/numa.c
+index 7b364f2926d4..901e9d6efcec 100644
+--- a/tools/perf/bench/numa.c
++++ b/tools/perf/bench/numa.c
+@@ -1626,7 +1626,7 @@ static int __bench_numa(const char *name)
+ 		"GB/sec,", "total-speed",	"GB/sec total speed");
+ 
+ 	if (g->p.show_details >= 2) {
+-		char tname[14 + 2 * 10 + 1];
++		char tname[14 + 2 * 11 + 1];
+ 		struct thread_data *td;
+ 		for (p = 0; p < g->p.nr_proc; p++) {
+ 			for (t = 0; t < g->p.nr_threads; t++) {
+-- 
+2.35.1
+
diff --git a/queue-4.9/scsi-qla2xxx-fix-missed-dma-unmap-for-aborted-comman.patch b/queue-4.9/scsi-qla2xxx-fix-missed-dma-unmap-for-aborted-comman.patch
new file mode 100644
index 0000000..caf3f66
--- /dev/null
+++ b/queue-4.9/scsi-qla2xxx-fix-missed-dma-unmap-for-aborted-comman.patch
@@ -0,0 +1,51 @@
+From 357342b89dc83a7c32e44439be39d9265772d873 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 15 Apr 2022 12:42:29 +0000
+Subject: scsi: qla2xxx: Fix missed DMA unmap for aborted commands
+
+From: Gleb Chesnokov <Chesnokov.G@raidix.com>
+
+[ Upstream commit 26f9ce53817a8fd84b69a73473a7de852a24c897 ]
+
+Aborting commands that have already been sent to the firmware can
+cause BUG in qlt_free_cmd(): BUG_ON(cmd->sg_mapped)
+
+For instance:
+
+ - Command passes rdx_to_xfer state, maps sgl, sends to the firmware
+
+ - Reset occurs, qla2xxx performs ISP error recovery, aborts the command
+
+ - Target stack calls qlt_abort_cmd() and then qlt_free_cmd()
+
+ - BUG_ON(cmd->sg_mapped) in qlt_free_cmd() occurs because sgl was not
+   unmapped
+
+Thus, unmap sgl in qlt_abort_cmd() for commands with the aborted flag set.
+
+Link: https://lore.kernel.org/r/AS8PR10MB4952D545F84B6B1DFD39EC1E9DEE9@AS8PR10MB4952.EURPRD10.PROD.OUTLOOK.COM
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Gleb Chesnokov <Chesnokov.G@raidix.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/qla2xxx/qla_target.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/scsi/qla2xxx/qla_target.c b/drivers/scsi/qla2xxx/qla_target.c
+index 6ef7a094ee51..b4a21adb3e73 100644
+--- a/drivers/scsi/qla2xxx/qla_target.c
++++ b/drivers/scsi/qla2xxx/qla_target.c
+@@ -3286,6 +3286,9 @@ int qlt_abort_cmd(struct qla_tgt_cmd *cmd)
+ 
+ 	spin_lock_irqsave(&cmd->cmd_lock, flags);
+ 	if (cmd->aborted) {
++		if (cmd->sg_mapped)
++			qlt_unmap_sg(vha, cmd);
++
+ 		spin_unlock_irqrestore(&cmd->cmd_lock, flags);
+ 		/*
+ 		 * It's normal to see 2 calls in this path:
+-- 
+2.35.1
+
diff --git a/queue-4.9/series b/queue-4.9/series
index ce33a2c..ac9a809 100644
--- a/queue-4.9/series
+++ b/queue-4.9/series
@@ -10,3 +10,16 @@
 alsa-wavefront-proper-check-of-get_user-error.patch
 perf-fix-sys_perf_event_open-race-against-self.patch
 drm-dp-mst-fix-a-possible-memory-leak-in-fetch_monitor_name.patch
+net-vmxnet3-fix-possible-use-after-free-bugs-in-vmxn.patch
+net-vmxnet3-fix-possible-null-pointer-dereference-in.patch
+net-qla3xxx-fix-a-test-in-ql_reset_work.patch
+nfc-nci-fix-sleep-in-atomic-context-bugs-caused-by-n.patch
+net-af_key-add-check-for-pfkey_broadcast-in-function.patch
+arm-9196-1-spectre-bhb-enable-for-cortex-a15.patch
+arm-9197-1-spectre-bhb-fix-loop8-sequence-for-thumb2.patch
+igb-skip-phy-status-check-where-unavailable.patch
+perf-bench-numa-address-compiler-error-on-s390.patch
+scsi-qla2xxx-fix-missed-dma-unmap-for-aborted-comman.patch
+mac80211-fix-rx-reordering-with-non-explicit-psmp-ac.patch
+ethernet-tulip-fix-missing-pci_disable_device-on-err.patch
+net-stmmac-fix-missing-pci_disable_device-on-error-i.patch