--- /dev/null
+From 2a35ded6721c557ca64441079e058fc487ae41ab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 29 Oct 2022 15:49:31 +0800
+Subject: ata: palmld: fix return value check in palmld_pata_probe()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit 015618c3ec19584c83ff179fa631be8cec906aaf ]
+
+If devm_platform_ioremap_resource() fails, it never return
+NULL pointer, replace the check with IS_ERR().
+
+Fixes: 57bf0f5a162d ("ARM: pxa: use pdev resource for palmld mmio")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/pata_palmld.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/ata/pata_palmld.c b/drivers/ata/pata_palmld.c
+index 400e65190904..51caa2a427dd 100644
+--- a/drivers/ata/pata_palmld.c
++++ b/drivers/ata/pata_palmld.c
+@@ -63,8 +63,8 @@ static int palmld_pata_probe(struct platform_device *pdev)
+
+ /* remap drive's physical memory address */
+ mem = devm_platform_ioremap_resource(pdev, 0);
+- if (!mem)
+- return -ENOMEM;
++ if (IS_ERR(mem))
++ return PTR_ERR(mem);
+
+ /* request and activate power and reset GPIOs */
+ lda->power = devm_gpiod_get(dev, "power", GPIOD_OUT_HIGH);
+--
+2.35.1
+
--- /dev/null
+From 3b9688e04db7d057a92caf7f138db646a47ecf45 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 29 Oct 2022 00:07:06 +0300
+Subject: ata: pata_legacy: fix pdc20230_set_piomode()
+
+From: Sergey Shtylyov <s.shtylyov@omp.ru>
+
+[ Upstream commit 171a93182eccd6e6835d2c86b40787f9f832efaa ]
+
+Clang gives a warning when compiling pata_legacy.c with 'make W=1' about
+the 'rt' local variable in pdc20230_set_piomode() being set but unused.
+Quite obviously, there is an outb() call missing to write back the updated
+variable. Moreover, checking the docs by Petr Soucek revealed that bitwise
+AND should have been done with a negated timing mask and the master/slave
+timing masks were swapped while updating...
+
+Fixes: 669a5db411d8 ("[libata] Add a bunch of PATA drivers.")
+Reported-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/ata/pata_legacy.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
+index 0a8bf09a5c19..03c580625c2c 100644
+--- a/drivers/ata/pata_legacy.c
++++ b/drivers/ata/pata_legacy.c
+@@ -315,9 +315,10 @@ static void pdc20230_set_piomode(struct ata_port *ap, struct ata_device *adev)
+ outb(inb(0x1F4) & 0x07, 0x1F4);
+
+ rt = inb(0x1F3);
+- rt &= 0x07 << (3 * adev->devno);
++ rt &= ~(0x07 << (3 * !adev->devno));
+ if (pio)
+- rt |= (1 + 3 * pio) << (3 * adev->devno);
++ rt |= (1 + 3 * pio) << (3 * !adev->devno);
++ outb(rt, 0x1F3);
+
+ udelay(100);
+ outb(inb(0x1F2) | 0x01, 0x1F2);
+--
+2.35.1
+
--- /dev/null
+From fa332c117942ca5b0e3e3712354f313bf027ebec Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 11 Oct 2022 22:25:33 +0300
+Subject: Bluetooth: hci_conn: Fix CIS connection dst_type handling
+
+From: Pauli Virtanen <pav@iki.fi>
+
+[ Upstream commit b36a234dc438cb6b76fc929a8df9a0e59c8acf23 ]
+
+hci_connect_cis and iso_connect_cis call hci_bind_cis inconsistently
+with dst_type being either ISO socket address type or the HCI type, but
+these values cannot be mixed like this. Fix this by using only the HCI
+type.
+
+CIS connection dst_type was also not initialized in hci_bind_cis, even
+though it is used in hci_conn_hash_lookup_cis to find existing
+connections. Set the value in hci_bind_cis, so that existing CIS
+connections are found e.g. when doing deferred socket connections, also
+when dst_type is not 0 (ADDR_LE_DEV_PUBLIC).
+
+Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections")
+Signed-off-by: Pauli Virtanen <pav@iki.fi>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/hci_conn.c | 7 +------
+ net/bluetooth/iso.c | 14 ++++++++++++--
+ 2 files changed, 13 insertions(+), 8 deletions(-)
+
+diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
+index 9777e7b109ee..f1263cdd71dd 100644
+--- a/net/bluetooth/hci_conn.c
++++ b/net/bluetooth/hci_conn.c
+@@ -1697,6 +1697,7 @@ struct hci_conn *hci_bind_cis(struct hci_dev *hdev, bdaddr_t *dst,
+ if (!cis)
+ return ERR_PTR(-ENOMEM);
+ cis->cleanup = cis_cleanup;
++ cis->dst_type = dst_type;
+ }
+
+ if (cis->state == BT_CONNECTED)
+@@ -2076,12 +2077,6 @@ struct hci_conn *hci_connect_cis(struct hci_dev *hdev, bdaddr_t *dst,
+ struct hci_conn *le;
+ struct hci_conn *cis;
+
+- /* Convert from ISO socket address type to HCI address type */
+- if (dst_type == BDADDR_LE_PUBLIC)
+- dst_type = ADDR_LE_DEV_PUBLIC;
+- else
+- dst_type = ADDR_LE_DEV_RANDOM;
+-
+ if (hci_dev_test_flag(hdev, HCI_ADVERTISING))
+ le = hci_connect_le(hdev, dst, dst_type, false,
+ BT_SECURITY_LOW,
+diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c
+index 613039ba5dbf..f825857db6d0 100644
+--- a/net/bluetooth/iso.c
++++ b/net/bluetooth/iso.c
+@@ -235,6 +235,14 @@ static int iso_chan_add(struct iso_conn *conn, struct sock *sk,
+ return err;
+ }
+
++static inline u8 le_addr_type(u8 bdaddr_type)
++{
++ if (bdaddr_type == BDADDR_LE_PUBLIC)
++ return ADDR_LE_DEV_PUBLIC;
++ else
++ return ADDR_LE_DEV_RANDOM;
++}
++
+ static int iso_connect_bis(struct sock *sk)
+ {
+ struct iso_conn *conn;
+@@ -328,14 +336,16 @@ static int iso_connect_cis(struct sock *sk)
+ /* Just bind if DEFER_SETUP has been set */
+ if (test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) {
+ hcon = hci_bind_cis(hdev, &iso_pi(sk)->dst,
+- iso_pi(sk)->dst_type, &iso_pi(sk)->qos);
++ le_addr_type(iso_pi(sk)->dst_type),
++ &iso_pi(sk)->qos);
+ if (IS_ERR(hcon)) {
+ err = PTR_ERR(hcon);
+ goto done;
+ }
+ } else {
+ hcon = hci_connect_cis(hdev, &iso_pi(sk)->dst,
+- iso_pi(sk)->dst_type, &iso_pi(sk)->qos);
++ le_addr_type(iso_pi(sk)->dst_type),
++ &iso_pi(sk)->qos);
+ if (IS_ERR(hcon)) {
+ err = PTR_ERR(hcon);
+ goto done;
+--
+2.35.1
+
--- /dev/null
+From ad6268f0a5c666e60979d4cf66b369e1c87daa20 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 17 Oct 2022 15:36:23 -0700
+Subject: Bluetooth: hci_conn: Fix not restoring ISO buffer count on disconnect
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+[ Upstream commit 5638d9ea9c01c77fc11693d48cf719bc7e88f224 ]
+
+When disconnecting an ISO link the controller may not generate
+HCI_EV_NUM_COMP_PKTS for unacked packets which needs to be restored in
+hci_conn_del otherwise the host would assume they are still in use and
+would not be able to use all the buffers available.
+
+Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Tested-by: Frédéric Danis <frederic.danis@collabora.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/hci_conn.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
+index f1263cdd71dd..f26ed278d9e3 100644
+--- a/net/bluetooth/hci_conn.c
++++ b/net/bluetooth/hci_conn.c
+@@ -1003,10 +1003,21 @@ int hci_conn_del(struct hci_conn *conn)
+ hdev->acl_cnt += conn->sent;
+ } else {
+ struct hci_conn *acl = conn->link;
++
+ if (acl) {
+ acl->link = NULL;
+ hci_conn_drop(acl);
+ }
++
++ /* Unacked ISO frames */
++ if (conn->type == ISO_LINK) {
++ if (hdev->iso_pkts)
++ hdev->iso_cnt += conn->sent;
++ else if (hdev->le_pkts)
++ hdev->le_cnt += conn->sent;
++ else
++ hdev->acl_cnt += conn->sent;
++ }
+ }
+
+ if (conn->amp_mgr)
+--
+2.35.1
+
--- /dev/null
+From 6a7440be8612430732655a7ab1cda49ac2a9aec7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Oct 2022 10:18:51 +0800
+Subject: Bluetooth: L2CAP: Fix memory leak in vhci_write
+
+From: Hawkins Jiawei <yin31149@gmail.com>
+
+[ Upstream commit 7c9524d929648935bac2bbb4c20437df8f9c3f42 ]
+
+Syzkaller reports a memory leak as follows:
+====================================
+BUG: memory leak
+unreferenced object 0xffff88810d81ac00 (size 240):
+ [...]
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<ffffffff838733d9>] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418
+ [<ffffffff833f742f>] alloc_skb include/linux/skbuff.h:1257 [inline]
+ [<ffffffff833f742f>] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline]
+ [<ffffffff833f742f>] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline]
+ [<ffffffff833f742f>] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511
+ [<ffffffff815e398d>] call_write_iter include/linux/fs.h:2192 [inline]
+ [<ffffffff815e398d>] new_sync_write fs/read_write.c:491 [inline]
+ [<ffffffff815e398d>] vfs_write+0x42d/0x540 fs/read_write.c:578
+ [<ffffffff815e3cdd>] ksys_write+0x9d/0x160 fs/read_write.c:631
+ [<ffffffff845e0645>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
+ [<ffffffff845e0645>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
+ [<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
+====================================
+
+HCI core will uses hci_rx_work() to process frame, which is queued to
+the hdev->rx_q tail in hci_recv_frame() by HCI driver.
+
+Yet the problem is that, HCI core may not free the skb after handling
+ACL data packets. To be more specific, when start fragment does not
+contain the L2CAP length, HCI core just copies skb into conn->rx_skb and
+finishes frame process in l2cap_recv_acldata(), without freeing the skb,
+which triggers the above memory leak.
+
+This patch solves it by releasing the relative skb, after processing
+the above case in l2cap_recv_acldata().
+
+Fixes: 4d7ea8ee90e4 ("Bluetooth: L2CAP: Fix handling fragmented length")
+Link: https://lore.kernel.org/all/0000000000000d0b1905e6aaef64@google.com/
+Reported-and-tested-by: syzbot+8f819e36e01022991cfa@syzkaller.appspotmail.com
+Signed-off-by: Hawkins Jiawei <yin31149@gmail.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/l2cap_core.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
+index 9a32ce634919..1fbe087d6ae4 100644
+--- a/net/bluetooth/l2cap_core.c
++++ b/net/bluetooth/l2cap_core.c
+@@ -8461,9 +8461,8 @@ void l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
+ * expected length.
+ */
+ if (skb->len < L2CAP_LEN_SIZE) {
+- if (l2cap_recv_frag(conn, skb, conn->mtu) < 0)
+- goto drop;
+- return;
++ l2cap_recv_frag(conn, skb, conn->mtu);
++ break;
+ }
+
+ len = get_unaligned_le16(skb->data) + L2CAP_HDR_SIZE;
+@@ -8507,7 +8506,7 @@ void l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags)
+
+ /* Header still could not be read just continue */
+ if (conn->rx_skb->len < L2CAP_LEN_SIZE)
+- return;
++ break;
+ }
+
+ if (skb->len > conn->rx_len) {
+--
+2.35.1
+
--- /dev/null
+From d23e2c358dfbbadefeefbc737c3d1422284f049b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 5 Oct 2022 00:27:18 +0300
+Subject: Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
+
+From: Maxim Mikityanskiy <maxtram95@gmail.com>
+
+[ Upstream commit 3aff8aaca4e36dc8b17eaa011684881a80238966 ]
+
+Fix the race condition between the following two flows that run in
+parallel:
+
+1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
+ __sock_queue_rcv_skb.
+
+2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.
+
+An SKB can be queued by the first flow and immediately dequeued and
+freed by the second flow, therefore the callers of l2cap_reassemble_sdu
+can't use the SKB after that function returns. However, some places
+continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
+short time after l2cap_reassemble_sdu returns, leading to a
+use-after-free condition (the stack trace is below, line numbers for
+kernel 5.19.8).
+
+Fix it by keeping a local copy of struct l2cap_ctrl.
+
+BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
+Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169
+
+Workqueue: hci0 hci_rx_work [bluetooth]
+Call Trace:
+ <TASK>
+ dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
+ print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
+ ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
+ kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
+ ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
+ l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
+ l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
+ ret_from_fork (arch/x86/entry/entry_64.S:306)
+ </TASK>
+
+Allocated by task 43169:
+ kasan_save_stack (mm/kasan/common.c:39)
+ __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
+ kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
+ __alloc_skb (net/core/skbuff.c:414)
+ l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
+ l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
+ hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
+ process_one_work (kernel/workqueue.c:2289)
+ worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
+ kthread (kernel/kthread.c:376)
+ ret_from_fork (arch/x86/entry/entry_64.S:306)
+
+Freed by task 27920:
+ kasan_save_stack (mm/kasan/common.c:39)
+ kasan_set_track (mm/kasan/common.c:45)
+ kasan_set_free_info (mm/kasan/generic.c:372)
+ ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
+ slab_free_freelist_hook (mm/slub.c:1780)
+ kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
+ skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
+ bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
+ l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
+ sock_read_iter (net/socket.c:1087)
+ new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
+ vfs_read (fs/read_write.c:482)
+ ksys_read (fs/read_write.c:620)
+ do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
+ entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
+
+Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u
+Fixes: d2a7ac5d5d3a ("Bluetooth: Add the ERTM receive state machine")
+Fixes: 4b51dae96731 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
+Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/l2cap_core.c | 48 ++++++++++++++++++++++++++++++++------
+ 1 file changed, 41 insertions(+), 7 deletions(-)
+
+diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
+index 1f34b82ca0ec..2283871d3f01 100644
+--- a/net/bluetooth/l2cap_core.c
++++ b/net/bluetooth/l2cap_core.c
+@@ -6885,6 +6885,7 @@ static int l2cap_rx_state_recv(struct l2cap_chan *chan,
+ struct l2cap_ctrl *control,
+ struct sk_buff *skb, u8 event)
+ {
++ struct l2cap_ctrl local_control;
+ int err = 0;
+ bool skb_in_use = false;
+
+@@ -6909,15 +6910,32 @@ static int l2cap_rx_state_recv(struct l2cap_chan *chan,
+ chan->buffer_seq = chan->expected_tx_seq;
+ skb_in_use = true;
+
++ /* l2cap_reassemble_sdu may free skb, hence invalidate
++ * control, so make a copy in advance to use it after
++ * l2cap_reassemble_sdu returns and to avoid the race
++ * condition, for example:
++ *
++ * The current thread calls:
++ * l2cap_reassemble_sdu
++ * chan->ops->recv == l2cap_sock_recv_cb
++ * __sock_queue_rcv_skb
++ * Another thread calls:
++ * bt_sock_recvmsg
++ * skb_recv_datagram
++ * skb_free_datagram
++ * Then the current thread tries to access control, but
++ * it was freed by skb_free_datagram.
++ */
++ local_control = *control;
+ err = l2cap_reassemble_sdu(chan, skb, control);
+ if (err)
+ break;
+
+- if (control->final) {
++ if (local_control.final) {
+ if (!test_and_clear_bit(CONN_REJ_ACT,
+ &chan->conn_state)) {
+- control->final = 0;
+- l2cap_retransmit_all(chan, control);
++ local_control.final = 0;
++ l2cap_retransmit_all(chan, &local_control);
+ l2cap_ertm_send(chan);
+ }
+ }
+@@ -7297,11 +7315,27 @@ static int l2cap_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
+ static int l2cap_stream_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
+ struct sk_buff *skb)
+ {
++ /* l2cap_reassemble_sdu may free skb, hence invalidate control, so store
++ * the txseq field in advance to use it after l2cap_reassemble_sdu
++ * returns and to avoid the race condition, for example:
++ *
++ * The current thread calls:
++ * l2cap_reassemble_sdu
++ * chan->ops->recv == l2cap_sock_recv_cb
++ * __sock_queue_rcv_skb
++ * Another thread calls:
++ * bt_sock_recvmsg
++ * skb_recv_datagram
++ * skb_free_datagram
++ * Then the current thread tries to access control, but it was freed by
++ * skb_free_datagram.
++ */
++ u16 txseq = control->txseq;
++
+ BT_DBG("chan %p, control %p, skb %p, state %d", chan, control, skb,
+ chan->rx_state);
+
+- if (l2cap_classify_txseq(chan, control->txseq) ==
+- L2CAP_TXSEQ_EXPECTED) {
++ if (l2cap_classify_txseq(chan, txseq) == L2CAP_TXSEQ_EXPECTED) {
+ l2cap_pass_to_tx(chan, control);
+
+ BT_DBG("buffer_seq %u->%u", chan->buffer_seq,
+@@ -7324,8 +7358,8 @@ static int l2cap_stream_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
+ }
+ }
+
+- chan->last_acked_seq = control->txseq;
+- chan->expected_tx_seq = __next_seq(chan, control->txseq);
++ chan->last_acked_seq = txseq;
++ chan->expected_tx_seq = __next_seq(chan, txseq);
+
+ return 0;
+ }
+--
+2.35.1
+
--- /dev/null
+From ec533fb857684251b2e1d8a0af3404c1bb1dd668 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 17 Oct 2022 15:58:13 +0800
+Subject: Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 0d0e2d032811280b927650ff3c15fe5020e82533 ]
+
+When l2cap_recv_frame() is invoked to receive data, and the cid is
+L2CAP_CID_A2MP, if the channel does not exist, it will create a channel.
+However, after a channel is created, the hold operation of the channel
+is not performed. In this case, the value of channel reference counting
+is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del()
+invokes the close hook function of A2MP to release the channel. Then
+ l2cap_chan_unlock(chan) will trigger UAF issue.
+
+The process is as follows:
+Receive data:
+l2cap_data_channel()
+ a2mp_channel_create() --->channel ref is 2
+ l2cap_chan_put() --->channel ref is 1
+
+Triger event:
+ hci_error_reset()
+ hci_dev_do_close()
+ ...
+ l2cap_disconn_cfm()
+ l2cap_conn_del()
+ l2cap_chan_hold() --->channel ref is 2
+ l2cap_chan_del() --->channel ref is 1
+ a2mp_chan_close_cb() --->channel ref is 0, release channel
+ l2cap_chan_unlock() --->UAF of channel
+
+The detailed Call Trace is as follows:
+BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0
+Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593
+Workqueue: hci0 hci_error_reset
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0xcd/0x134
+ print_report.cold+0x2ba/0x719
+ kasan_report+0xb1/0x1e0
+ kasan_check_range+0x140/0x190
+ __mutex_unlock_slowpath+0xa6/0x5e0
+ l2cap_conn_del+0x404/0x7b0
+ l2cap_disconn_cfm+0x8c/0xc0
+ hci_conn_hash_flush+0x11f/0x260
+ hci_dev_close_sync+0x5f5/0x11f0
+ hci_dev_do_close+0x2d/0x70
+ hci_error_reset+0x9e/0x140
+ process_one_work+0x98a/0x1620
+ worker_thread+0x665/0x1080
+ kthread+0x2e4/0x3a0
+ ret_from_fork+0x1f/0x30
+ </TASK>
+
+Allocated by task 7593:
+ kasan_save_stack+0x1e/0x40
+ __kasan_kmalloc+0xa9/0xd0
+ l2cap_chan_create+0x40/0x930
+ amp_mgr_create+0x96/0x990
+ a2mp_channel_create+0x7d/0x150
+ l2cap_recv_frame+0x51b8/0x9a70
+ l2cap_recv_acldata+0xaa3/0xc00
+ hci_rx_work+0x702/0x1220
+ process_one_work+0x98a/0x1620
+ worker_thread+0x665/0x1080
+ kthread+0x2e4/0x3a0
+ ret_from_fork+0x1f/0x30
+
+Freed by task 7593:
+ kasan_save_stack+0x1e/0x40
+ kasan_set_track+0x21/0x30
+ kasan_set_free_info+0x20/0x30
+ ____kasan_slab_free+0x167/0x1c0
+ slab_free_freelist_hook+0x89/0x1c0
+ kfree+0xe2/0x580
+ l2cap_chan_put+0x22a/0x2d0
+ l2cap_conn_del+0x3fc/0x7b0
+ l2cap_disconn_cfm+0x8c/0xc0
+ hci_conn_hash_flush+0x11f/0x260
+ hci_dev_close_sync+0x5f5/0x11f0
+ hci_dev_do_close+0x2d/0x70
+ hci_error_reset+0x9e/0x140
+ process_one_work+0x98a/0x1620
+ worker_thread+0x665/0x1080
+ kthread+0x2e4/0x3a0
+ ret_from_fork+0x1f/0x30
+
+Last potentially related work creation:
+ kasan_save_stack+0x1e/0x40
+ __kasan_record_aux_stack+0xbe/0xd0
+ call_rcu+0x99/0x740
+ netlink_release+0xe6a/0x1cf0
+ __sock_release+0xcd/0x280
+ sock_close+0x18/0x20
+ __fput+0x27c/0xa90
+ task_work_run+0xdd/0x1a0
+ exit_to_user_mode_prepare+0x23c/0x250
+ syscall_exit_to_user_mode+0x19/0x50
+ do_syscall_64+0x42/0x80
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+
+Second to last potentially related work creation:
+ kasan_save_stack+0x1e/0x40
+ __kasan_record_aux_stack+0xbe/0xd0
+ call_rcu+0x99/0x740
+ netlink_release+0xe6a/0x1cf0
+ __sock_release+0xcd/0x280
+ sock_close+0x18/0x20
+ __fput+0x27c/0xa90
+ task_work_run+0xdd/0x1a0
+ exit_to_user_mode_prepare+0x23c/0x250
+ syscall_exit_to_user_mode+0x19/0x50
+ do_syscall_64+0x42/0x80
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+
+Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/l2cap_core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
+index 2283871d3f01..9a32ce634919 100644
+--- a/net/bluetooth/l2cap_core.c
++++ b/net/bluetooth/l2cap_core.c
+@@ -7615,6 +7615,7 @@ static void l2cap_data_channel(struct l2cap_conn *conn, u16 cid,
+ return;
+ }
+
++ l2cap_chan_hold(chan);
+ l2cap_chan_lock(chan);
+ } else {
+ BT_DBG("unknown cid 0x%4.4x", cid);
+--
+2.35.1
+
--- /dev/null
+From 8b871df9725d37f038009542a053f1fcc75f974a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Oct 2022 09:45:06 +0200
+Subject: Bluetooth: virtio_bt: Use skb_put to set length
+
+From: Soenke Huster <soenke.huster@eknoes.de>
+
+[ Upstream commit 160fbcf3bfb93c3c086427f9f4c8bc70f217e9be ]
+
+By using skb_put we ensure that skb->tail is set
+correctly. Currently, skb->tail is always zero, which
+leads to errors, such as the following page fault in
+rfcomm_recv_frame:
+
+ BUG: unable to handle page fault for address: ffffed1021de29ff
+ #PF: supervisor read access in kernel mode
+ #PF: error_code(0x0000) - not-present page
+ RIP: 0010:rfcomm_run+0x831/0x4040 (net/bluetooth/rfcomm/core.c:1751)
+
+Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver")
+Signed-off-by: Soenke Huster <soenke.huster@eknoes.de>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/bluetooth/virtio_bt.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
+index 67c21263f9e0..fd281d439505 100644
+--- a/drivers/bluetooth/virtio_bt.c
++++ b/drivers/bluetooth/virtio_bt.c
+@@ -219,7 +219,7 @@ static void virtbt_rx_work(struct work_struct *work)
+ if (!skb)
+ return;
+
+- skb->len = len;
++ skb_put(skb, len);
+ virtbt_rx_handle(vbt, skb);
+
+ if (virtbt_add_inbuf(vbt) < 0)
+--
+2.35.1
+
--- /dev/null
+From 486e4dcf04744bc4a1d5fbf7316140d95ac49ae9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 20:57:53 +0200
+Subject: bridge: Fix flushing of dynamic FDB entries
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 628ac04a75ed5ff13647e725f40192da22ef2be8 ]
+
+The following commands should result in all the dynamic FDB entries
+being flushed, but instead all the non-local (non-permanent) entries are
+flushed:
+
+ # bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master static
+ # bridge fdb add 00:11:22:33:44:55 dev dummy1 master dynamic
+ # ip link set dev br0 type bridge fdb_flush
+ # bridge fdb show brport dummy1
+ 00:00:00:00:00:01 master br0 permanent
+ 33:33:00:00:00:01 self permanent
+ 01:00:5e:00:00:01 self permanent
+
+This is because br_fdb_flush() works with FDB flags and not the
+corresponding enumerator values. Fix by passing the FDB flag instead.
+
+After the fix:
+
+ # bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master static
+ # bridge fdb add 00:11:22:33:44:55 dev dummy1 master dynamic
+ # ip link set dev br0 type bridge fdb_flush
+ # bridge fdb show brport dummy1
+ 00:aa:bb:cc:dd:ee master br0 static
+ 00:00:00:00:00:01 master br0 permanent
+ 33:33:00:00:00:01 self permanent
+ 01:00:5e:00:00:01 self permanent
+
+Fixes: 1f78ee14eeac ("net: bridge: fdb: add support for fine-grained flushing")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
+Link: https://lore.kernel.org/r/20221101185753.2120691-1-idosch@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bridge/br_netlink.c | 2 +-
+ net/bridge/br_sysfs_br.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
+index 5aeb3646e74c..d087fd4c784a 100644
+--- a/net/bridge/br_netlink.c
++++ b/net/bridge/br_netlink.c
+@@ -1332,7 +1332,7 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
+
+ if (data[IFLA_BR_FDB_FLUSH]) {
+ struct net_bridge_fdb_flush_desc desc = {
+- .flags_mask = BR_FDB_STATIC
++ .flags_mask = BIT(BR_FDB_STATIC)
+ };
+
+ br_fdb_flush(br, &desc);
+diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
+index 612e367fff20..ea733542244c 100644
+--- a/net/bridge/br_sysfs_br.c
++++ b/net/bridge/br_sysfs_br.c
+@@ -345,7 +345,7 @@ static int set_flush(struct net_bridge *br, unsigned long val,
+ struct netlink_ext_ack *extack)
+ {
+ struct net_bridge_fdb_flush_desc desc = {
+- .flags_mask = BR_FDB_STATIC
++ .flags_mask = BIT(BR_FDB_STATIC)
+ };
+
+ br_fdb_flush(br, &desc);
+--
+2.35.1
+
--- /dev/null
+From 2de33bdbe6912904a20b338d0ebf0e7804c13b53 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 16:15:37 +0000
+Subject: btrfs: fix inode list leak during backref walking at
+ resolve_indirect_refs()
+
+From: Filipe Manana <fdmanana@suse.com>
+
+[ Upstream commit 5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1 ]
+
+During backref walking, at resolve_indirect_refs(), if we get an error
+we jump to the 'out' label and call ulist_free() on the 'parents' ulist,
+which frees all the elements in the ulist - however that does not free
+any inode lists that may be attached to elements, through the 'aux' field
+of a ulist node, so we end up leaking lists if we have any attached to
+the unodes.
+
+Fix this by calling free_leaf_list() instead of ulist_free() when we exit
+from resolve_indirect_refs(). The static function free_leaf_list() is
+moved up for this to be possible and it's slightly simplified by removing
+unnecessary code.
+
+Fixes: 3301958b7c1d ("Btrfs: add inodes before dropping the extent lock in find_all_leafs")
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/backref.c | 36 +++++++++++++++++-------------------
+ 1 file changed, 17 insertions(+), 19 deletions(-)
+
+diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
+index ccc818b40977..90702a74f90c 100644
+--- a/fs/btrfs/backref.c
++++ b/fs/btrfs/backref.c
+@@ -648,6 +648,18 @@ unode_aux_to_inode_list(struct ulist_node *node)
+ return (struct extent_inode_elem *)(uintptr_t)node->aux;
+ }
+
++static void free_leaf_list(struct ulist *ulist)
++{
++ struct ulist_node *node;
++ struct ulist_iterator uiter;
++
++ ULIST_ITER_INIT(&uiter);
++ while ((node = ulist_next(ulist, &uiter)))
++ free_inode_elem_list(unode_aux_to_inode_list(node));
++
++ ulist_free(ulist);
++}
++
+ /*
+ * We maintain three separate rbtrees: one for direct refs, one for
+ * indirect refs which have a key, and one for indirect refs which do not
+@@ -762,7 +774,11 @@ static int resolve_indirect_refs(struct btrfs_fs_info *fs_info,
+ cond_resched();
+ }
+ out:
+- ulist_free(parents);
++ /*
++ * We may have inode lists attached to refs in the parents ulist, so we
++ * must free them before freeing the ulist and its refs.
++ */
++ free_leaf_list(parents);
+ return ret;
+ }
+
+@@ -1409,24 +1425,6 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans,
+ return ret;
+ }
+
+-static void free_leaf_list(struct ulist *blocks)
+-{
+- struct ulist_node *node = NULL;
+- struct extent_inode_elem *eie;
+- struct ulist_iterator uiter;
+-
+- ULIST_ITER_INIT(&uiter);
+- while ((node = ulist_next(blocks, &uiter))) {
+- if (!node->aux)
+- continue;
+- eie = unode_aux_to_inode_list(node);
+- free_inode_elem_list(eie);
+- node->aux = 0;
+- }
+-
+- ulist_free(blocks);
+-}
+-
+ /*
+ * Finds all leafs with a reference to the specified combination of bytenr and
+ * offset. key_list_head will point to a list of corresponding keys (caller must
+--
+2.35.1
+
--- /dev/null
+From 173b6de7b17548c748eb14986c80f23cbf43e5c9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 16:15:38 +0000
+Subject: btrfs: fix inode list leak during backref walking at
+ find_parent_nodes()
+
+From: Filipe Manana <fdmanana@suse.com>
+
+[ Upstream commit 92876eec382a0f19f33d09d2c939e9ca49038ae5 ]
+
+During backref walking, at find_parent_nodes(), if we are dealing with a
+data extent and we get an error while resolving the indirect backrefs, at
+resolve_indirect_refs(), or in the while loop that iterates over the refs
+in the direct refs rbtree, we end up leaking the inode lists attached to
+the direct refs we have in the direct refs rbtree that were not yet added
+to the refs ulist passed as argument to find_parent_nodes(). Since they
+were not yet added to the refs ulist and prelim_release() does not free
+the lists, on error the caller can only free the lists attached to the
+refs that were added to the refs ulist, all the remaining refs get their
+inode lists never freed, therefore leaking their memory.
+
+Fix this by having prelim_release() always free any attached inode list
+to each ref found in the rbtree, and have find_parent_nodes() set the
+ref's inode list to NULL once it transfers ownership of the inode list
+to a ref added to the refs ulist passed to find_parent_nodes().
+
+Fixes: 86d5f9944252 ("btrfs: convert prelimary reference tracking to use rbtrees")
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/backref.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
+index 90702a74f90c..21c478df6aef 100644
+--- a/fs/btrfs/backref.c
++++ b/fs/btrfs/backref.c
+@@ -289,8 +289,10 @@ static void prelim_release(struct preftree *preftree)
+ struct prelim_ref *ref, *next_ref;
+
+ rbtree_postorder_for_each_entry_safe(ref, next_ref,
+- &preftree->root.rb_root, rbnode)
++ &preftree->root.rb_root, rbnode) {
++ free_inode_elem_list(ref->inode_list);
+ free_pref(ref);
++ }
+
+ preftree->root = RB_ROOT_CACHED;
+ preftree->count = 0;
+@@ -1384,6 +1386,12 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans,
+ if (ret < 0)
+ goto out;
+ ref->inode_list = eie;
++ /*
++ * We transferred the list ownership to the ref,
++ * so set to NULL to avoid a double free in case
++ * an error happens after this.
++ */
++ eie = NULL;
+ }
+ ret = ulist_add_merge_ptr(refs, ref->parent,
+ ref->inode_list,
+@@ -1409,6 +1417,14 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans,
+ eie->next = ref->inode_list;
+ }
+ eie = NULL;
++ /*
++ * We have transferred the inode list ownership from
++ * this ref to the ref we added to the 'refs' ulist.
++ * So set this ref's inode list to NULL to avoid
++ * use-after-free when our caller uses it or double
++ * frees in case an error happens before we return.
++ */
++ ref->inode_list = NULL;
+ }
+ cond_resched();
+ }
+--
+2.35.1
+
--- /dev/null
+From f27946c4bdca73f5c35318dfa54b629216bd1187 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 16:15:39 +0000
+Subject: btrfs: fix ulist leaks in error paths of qgroup self tests
+
+From: Filipe Manana <fdmanana@suse.com>
+
+[ Upstream commit d37de92b38932d40e4a251e876cc388f9aee5f42 ]
+
+In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests,
+if we fail to add the tree ref, remove the extent item or remove the
+extent ref, we are returning from the test function without freeing the
+"old_roots" ulist that was allocated by the previous calls to
+btrfs_find_all_roots(). Fix that by calling ulist_free() before returning.
+
+Fixes: 442244c96332 ("btrfs: qgroup: Switch self test to extent-oriented qgroup mechanism.")
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/btrfs/tests/qgroup-tests.c | 20 +++++++++++++++-----
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+diff --git a/fs/btrfs/tests/qgroup-tests.c b/fs/btrfs/tests/qgroup-tests.c
+index eee1e4459541..843dd3d3adbe 100644
+--- a/fs/btrfs/tests/qgroup-tests.c
++++ b/fs/btrfs/tests/qgroup-tests.c
+@@ -232,8 +232,10 @@ static int test_no_shared_qgroup(struct btrfs_root *root,
+
+ ret = insert_normal_tree_ref(root, nodesize, nodesize, 0,
+ BTRFS_FS_TREE_OBJECTID);
+- if (ret)
++ if (ret) {
++ ulist_free(old_roots);
+ return ret;
++ }
+
+ ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false);
+ if (ret) {
+@@ -266,8 +268,10 @@ static int test_no_shared_qgroup(struct btrfs_root *root,
+ }
+
+ ret = remove_extent_item(root, nodesize, nodesize);
+- if (ret)
++ if (ret) {
++ ulist_free(old_roots);
+ return -EINVAL;
++ }
+
+ ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false);
+ if (ret) {
+@@ -329,8 +333,10 @@ static int test_multiple_refs(struct btrfs_root *root,
+
+ ret = insert_normal_tree_ref(root, nodesize, nodesize, 0,
+ BTRFS_FS_TREE_OBJECTID);
+- if (ret)
++ if (ret) {
++ ulist_free(old_roots);
+ return ret;
++ }
+
+ ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false);
+ if (ret) {
+@@ -362,8 +368,10 @@ static int test_multiple_refs(struct btrfs_root *root,
+
+ ret = add_tree_ref(root, nodesize, nodesize, 0,
+ BTRFS_FIRST_FREE_OBJECTID);
+- if (ret)
++ if (ret) {
++ ulist_free(old_roots);
+ return ret;
++ }
+
+ ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false);
+ if (ret) {
+@@ -401,8 +409,10 @@ static int test_multiple_refs(struct btrfs_root *root,
+
+ ret = remove_extent_ref(root, nodesize, nodesize, 0,
+ BTRFS_FIRST_FREE_OBJECTID);
+- if (ret)
++ if (ret) {
++ ulist_free(old_roots);
+ return ret;
++ }
+
+ ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false);
+ if (ret) {
+--
+2.35.1
+
--- /dev/null
+From 782909305abe2e501dabbd32011d43cd6e84e9ba Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 15 Oct 2022 18:22:01 +0900
+Subject: docs/process/howto: Replace C89 with C11
+
+From: Akira Yokosawa <akiyks@gmail.com>
+
+[ Upstream commit 2f3f53d62307262f0086804ea7cea99b0e085450 ]
+
+Commit e8c07082a810 ("Kbuild: move to -std=gnu11") updated
+process/programming-language.rst, but failed to update
+process/howto.rst.
+
+Update howto.rst and resolve the inconsistency.
+
+Fixes: e8c07082a810 ("Kbuild: move to -std=gnu11")
+Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Federico Vaga <federico.vaga@vaga.pv.it>
+Cc: Alex Shi <alexs@kernel.org>
+Cc: Hu Haowen <src.res@email.cn>
+Cc: Tsugikazu Shibata <shibata@linuxfoundation.org>
+Link: https://lore.kernel.org/r/20221015092201.32099-1-akiyks@gmail.com
+Signed-off-by: Jonathan Corbet <corbet@lwn.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ Documentation/process/howto.rst | 2 +-
+ Documentation/translations/it_IT/process/howto.rst | 2 +-
+ Documentation/translations/ja_JP/howto.rst | 2 +-
+ Documentation/translations/ko_KR/howto.rst | 2 +-
+ Documentation/translations/zh_CN/process/howto.rst | 2 +-
+ Documentation/translations/zh_TW/process/howto.rst | 2 +-
+ 6 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
+index cd6997a9d203..8fc5398c732b 100644
+--- a/Documentation/process/howto.rst
++++ b/Documentation/process/howto.rst
+@@ -36,7 +36,7 @@ experience, the following books are good for, if anything, reference:
+ - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
+
+ The kernel is written using GNU C and the GNU toolchain. While it
+-adheres to the ISO C89 standard, it uses a number of extensions that are
++adheres to the ISO C11 standard, it uses a number of extensions that are
+ not featured in the standard. The kernel is a freestanding C
+ environment, with no reliance on the standard C library, so some
+ portions of the C standard are not supported. Arbitrary long long
+diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst
+index 16ad5622d549..67b84f015da8 100644
+--- a/Documentation/translations/it_IT/process/howto.rst
++++ b/Documentation/translations/it_IT/process/howto.rst
+@@ -44,7 +44,7 @@ altro, utili riferimenti:
+ - "C: A Reference Manual" di Harbison and Steele [Prentice Hall]
+
+ Il kernel è stato scritto usando GNU C e la toolchain GNU.
+-Sebbene si attenga allo standard ISO C89, esso utilizza una serie di
++Sebbene si attenga allo standard ISO C11, esso utilizza una serie di
+ estensioni che non sono previste in questo standard. Il kernel è un
+ ambiente C indipendente, che non ha alcuna dipendenza dalle librerie
+ C standard, così alcune parti del C standard non sono supportate.
+diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst
+index 649e2ff2a407..e2e946a4298a 100644
+--- a/Documentation/translations/ja_JP/howto.rst
++++ b/Documentation/translations/ja_JP/howto.rst
+@@ -65,7 +65,7 @@ Linux カーネル開発のやり方
+ - 『新・詳説 C 言語 H&S リファレンス』 (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク]
+
+ カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネル
+-は ISO C89 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って
++は ISO C11 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って
+ います。カーネルは標準 C ライブラリに依存しない、C 言語非依存環境です。
+ そのため、C の標準の中で使えないものもあります。特に任意の long long
+ の除算や浮動小数点は使えません。カーネルがツールチェインや C 言語拡張
+diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst
+index e43970584ca4..2a7ab4257e44 100644
+--- a/Documentation/translations/ko_KR/howto.rst
++++ b/Documentation/translations/ko_KR/howto.rst
+@@ -62,7 +62,7 @@ Documentation/process/howto.rst
+ - "Practical C Programming" by Steve Oualline [O'Reilly]
+ - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
+
+-커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C89 표준을
++커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C11 표준을
+ 따르는 반면 표준에 있지 않은 많은 확장기능도 가지고 있다. 커널은 표준 C
+ 라이브러리와는 관계없이 freestanding C 환경이어서 C 표준의 일부는
+ 지원되지 않는다. 임의의 long long 나누기나 floating point는 지원되지 않는다.
+diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
+index 1455190dc087..e7e4bb000b8a 100644
+--- a/Documentation/translations/zh_CN/process/howto.rst
++++ b/Documentation/translations/zh_CN/process/howto.rst
+@@ -45,7 +45,7 @@ Linux内核大部分是由C语言写成的，一些体系结构相关的代码
+ - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
+ 《C语言参考手册（原书第5版）》（邱仲潘 等译）[机械工业出版社]
+
+-Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C89标准，但也用到了一些
++Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C11标准，但也用到了一些
+ 标准中没有定义的扩展。内核是自给自足的C环境，不依赖于标准C库的支持，所以
+ 并不支持C标准中的部分定义。比如long long类型的大数除法和浮点运算就不允许
+ 使用。有时候确实很难弄清楚内核对工具链的要求和它所使用的扩展，不幸的是目
+diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
+index 68ae4411285b..e335789d7e26 100644
+--- a/Documentation/translations/zh_TW/process/howto.rst
++++ b/Documentation/translations/zh_TW/process/howto.rst
+@@ -48,7 +48,7 @@ Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼
+ - "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
+ 《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社]
+
+-Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C89標準，但也用到了一些
++Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些
+ 標準中沒有定義的擴展。內核是自給自足的C環境，不依賴於標準C庫的支持，所以
+ 並不支持C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許
+ 使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目
+--
+2.35.1
+
--- /dev/null
+From a2bb2dff0179d0eee5137886330092b93d761576 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Oct 2022 10:27:50 -0400
+Subject: IB/hfi1: Correctly move list in sc_disable()
+
+From: Dean Luick <dean.luick@cornelisnetworks.com>
+
+[ Upstream commit 1afac08b39d85437187bb2a92d89a741b1078f55 ]
+
+Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")
+incorrectly tries to move a list from one list head to another. The
+result is a kernel crash.
+
+The crash is triggered when a link goes down and there are waiters for a
+send to complete. The following signature is seen:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000030
+ [...]
+ Call Trace:
+ sc_disable+0x1ba/0x240 [hfi1]
+ pio_freeze+0x3d/0x60 [hfi1]
+ handle_freeze+0x27/0x1b0 [hfi1]
+ process_one_work+0x1b0/0x380
+ ? process_one_work+0x380/0x380
+ worker_thread+0x30/0x360
+ ? process_one_work+0x380/0x380
+ kthread+0xd7/0x100
+ ? kthread_complete_and_exit+0x20/0x20
+ ret_from_fork+0x1f/0x30
+
+The fix is to use the correct call to move the list.
+
+Fixes: 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")
+Signed-off-by: Dean Luick <dean.luick@cornelisnetworks.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
+Link: https://lore.kernel.org/r/166610327042.674422.6146908799669288976.stgit@awfm-02.cornelisnetworks.com
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/hw/hfi1/pio.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/drivers/infiniband/hw/hfi1/pio.c b/drivers/infiniband/hw/hfi1/pio.c
+index 3d42bd2b36bd..51ae58c02b15 100644
+--- a/drivers/infiniband/hw/hfi1/pio.c
++++ b/drivers/infiniband/hw/hfi1/pio.c
+@@ -913,8 +913,7 @@ void sc_disable(struct send_context *sc)
+ spin_unlock(&sc->release_lock);
+
+ write_seqlock(&sc->waitlock);
+- if (!list_empty(&sc->piowait))
+- list_move(&sc->piowait, &wake_list);
++ list_splice_init(&sc->piowait, &wake_list);
+ write_sequnlock(&sc->waitlock);
+ while (!list_empty(&wake_list)) {
+ struct iowait *wait;
+--
+2.35.1
+
--- /dev/null
+From 90c7fbc08f47dde3a3524d5aa6d17cad961559c3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 10:06:42 -0500
+Subject: ibmvnic: Free rwi on reset success
+
+From: Nick Child <nnac123@linux.ibm.com>
+
+[ Upstream commit d6dd2fe71153f0ff748bf188bd4af076fe09a0a6 ]
+
+Free the rwi structure in the event that the last rwi in the list
+processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic:
+retry reset if there are no other resets") introduces an issue that
+results in a 32 byte memory leak whenever the last rwi in the list
+gets processed.
+
+Fixes: 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets")
+Signed-off-by: Nick Child <nnac123@linux.ibm.com>
+Link: https://lore.kernel.org/r/20221031150642.13356-1-nnac123@linux.ibm.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/ibm/ibmvnic.c | 16 ++++++++--------
+ 1 file changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
+index 5ab7c0f81e9a..e6b141536879 100644
+--- a/drivers/net/ethernet/ibm/ibmvnic.c
++++ b/drivers/net/ethernet/ibm/ibmvnic.c
+@@ -3007,19 +3007,19 @@ static void __ibmvnic_reset(struct work_struct *work)
+ rwi = get_next_rwi(adapter);
+
+ /*
+- * If there is another reset queued, free the previous rwi
+- * and process the new reset even if previous reset failed
+- * (the previous reset could have failed because of a fail
+- * over for instance, so process the fail over).
+- *
+ * If there are no resets queued and the previous reset failed,
+ * the adapter would be in an undefined state. So retry the
+ * previous reset as a hard reset.
++ *
++ * Else, free the previous rwi and, if there is another reset
++ * queued, process the new reset even if previous reset failed
++ * (the previous reset could have failed because of a fail
++ * over for instance, so process the fail over).
+ */
+- if (rwi)
+- kfree(tmprwi);
+- else if (rc)
++ if (!rwi && rc)
+ rwi = tmprwi;
++ else
++ kfree(tmprwi);
+
+ if (rwi && (rwi->reset_reason == VNIC_RESET_FAILOVER ||
+ rwi->reset_reason == VNIC_RESET_MOBILITY || rc))
+--
+2.35.1
+
--- /dev/null
+From 45a5bc030779c702ec72271e846bc1e7e1100a43 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 10:06:10 +0800
+Subject: ipv6: fix WARNING in ip6_route_net_exit_late()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 768b3c745fe5789f2430bdab02f35a9ad1148d97 ]
+
+During the initialization of ip6_route_net_init_late(), if file
+ipv6_route or rt6_stats fails to be created, the initialization is
+successful by default. Therefore, the ipv6_route or rt6_stats file
+doesn't be found during the remove in ip6_route_net_exit_late(). It
+will cause WRNING.
+
+The following is the stack information:
+name 'rt6_stats'
+WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
+Modules linked in:
+Workqueue: netns cleanup_net
+RIP: 0010:remove_proc_entry+0x389/0x460
+PKRU: 55555554
+Call Trace:
+<TASK>
+ops_exit_list+0xb0/0x170
+cleanup_net+0x4ea/0xb00
+process_one_work+0x9bf/0x1710
+worker_thread+0x665/0x1080
+kthread+0x2e4/0x3a0
+ret_from_fork+0x1f/0x30
+</TASK>
+
+Fixes: cdb1876192db ("[NETNS][IPV6] route6 - create route6 proc files for the namespace")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20221102020610.351330-1-shaozhengchao@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/ipv6/route.c | 14 ++++++++++----
+ 1 file changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/net/ipv6/route.c b/net/ipv6/route.c
+index 69252eb462b2..2f355f0ec32a 100644
+--- a/net/ipv6/route.c
++++ b/net/ipv6/route.c
+@@ -6555,10 +6555,16 @@ static void __net_exit ip6_route_net_exit(struct net *net)
+ static int __net_init ip6_route_net_init_late(struct net *net)
+ {
+ #ifdef CONFIG_PROC_FS
+- proc_create_net("ipv6_route", 0, net->proc_net, &ipv6_route_seq_ops,
+- sizeof(struct ipv6_route_iter));
+- proc_create_net_single("rt6_stats", 0444, net->proc_net,
+- rt6_stats_seq_show, NULL);
++ if (!proc_create_net("ipv6_route", 0, net->proc_net,
++ &ipv6_route_seq_ops,
++ sizeof(struct ipv6_route_iter)))
++ return -ENOMEM;
++
++ if (!proc_create_net_single("rt6_stats", 0444, net->proc_net,
++ rt6_stats_seq_show, NULL)) {
++ remove_proc_entry("ipv6_route", net->proc_net);
++ return -ENOMEM;
++ }
+ #endif
+ return 0;
+ }
+--
+2.35.1
+
--- /dev/null
+From ab5b8289e39716336ae639f5ba576f6b50074abf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 20:07:04 +0800
+Subject: ipvs: fix WARNING in __ip_vs_cleanup_batch()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 3d00c6a0da8ddcf75213e004765e4a42acc71d5d ]
+
+During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn
+or ip_vs_conn_sync fails to be created, the initialization is successful
+by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't
+be found during the remove.
+
+The following is the stack information:
+name 'ip_vs_conn_sync'
+WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712
+remove_proc_entry+0x389/0x460
+Modules linked in:
+Workqueue: netns cleanup_net
+RIP: 0010:remove_proc_entry+0x389/0x460
+Call Trace:
+<TASK>
+__ip_vs_cleanup_batch+0x7d/0x120
+ops_exit_list+0x125/0x170
+cleanup_net+0x4ea/0xb00
+process_one_work+0x9bf/0x1710
+worker_thread+0x665/0x1080
+kthread+0x2e4/0x3a0
+ret_from_fork+0x1f/0x30
+</TASK>
+
+Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Acked-by: Julian Anastasov <ja@ssi.bg>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/ipvs/ip_vs_conn.c | 26 +++++++++++++++++++++-----
+ 1 file changed, 21 insertions(+), 5 deletions(-)
+
+diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
+index db13288fddfa..cb6d68220c26 100644
+--- a/net/netfilter/ipvs/ip_vs_conn.c
++++ b/net/netfilter/ipvs/ip_vs_conn.c
+@@ -1447,20 +1447,36 @@ int __net_init ip_vs_conn_net_init(struct netns_ipvs *ipvs)
+ {
+ atomic_set(&ipvs->conn_count, 0);
+
+- proc_create_net("ip_vs_conn", 0, ipvs->net->proc_net,
+- &ip_vs_conn_seq_ops, sizeof(struct ip_vs_iter_state));
+- proc_create_net("ip_vs_conn_sync", 0, ipvs->net->proc_net,
+- &ip_vs_conn_sync_seq_ops,
+- sizeof(struct ip_vs_iter_state));
++#ifdef CONFIG_PROC_FS
++ if (!proc_create_net("ip_vs_conn", 0, ipvs->net->proc_net,
++ &ip_vs_conn_seq_ops,
++ sizeof(struct ip_vs_iter_state)))
++ goto err_conn;
++
++ if (!proc_create_net("ip_vs_conn_sync", 0, ipvs->net->proc_net,
++ &ip_vs_conn_sync_seq_ops,
++ sizeof(struct ip_vs_iter_state)))
++ goto err_conn_sync;
++#endif
++
+ return 0;
++
++#ifdef CONFIG_PROC_FS
++err_conn_sync:
++ remove_proc_entry("ip_vs_conn", ipvs->net->proc_net);
++err_conn:
++ return -ENOMEM;
++#endif
+ }
+
+ void __net_exit ip_vs_conn_net_cleanup(struct netns_ipvs *ipvs)
+ {
+ /* flush all the connection entries first */
+ ip_vs_conn_flush(ipvs);
++#ifdef CONFIG_PROC_FS
+ remove_proc_entry("ip_vs_conn", ipvs->net->proc_net);
+ remove_proc_entry("ip_vs_conn_sync", ipvs->net->proc_net);
++#endif
+ }
+
+ int __init ip_vs_conn_init(void)
+--
+2.35.1
+
--- /dev/null
+From 0fc75485e760af5c9b8e5cd2cca03075117a108a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 20:07:05 +0800
+Subject: ipvs: fix WARNING in ip_vs_app_net_cleanup()
+
+From: Zhengchao Shao <shaozhengchao@huawei.com>
+
+[ Upstream commit 5663ed63adb9619c98ab7479aa4606fa9b7a548c ]
+
+During the initialization of ip_vs_app_net_init(), if file ip_vs_app
+fails to be created, the initialization is successful by default.
+Therefore, the ip_vs_app file doesn't be found during the remove in
+ip_vs_app_net_cleanup(). It will cause WRNING.
+
+The following is the stack information:
+name 'ip_vs_app'
+WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460
+Modules linked in:
+Workqueue: netns cleanup_net
+RIP: 0010:remove_proc_entry+0x389/0x460
+Call Trace:
+<TASK>
+ops_exit_list+0x125/0x170
+cleanup_net+0x4ea/0xb00
+process_one_work+0x9bf/0x1710
+worker_thread+0x665/0x1080
+kthread+0x2e4/0x3a0
+ret_from_fork+0x1f/0x30
+</TASK>
+
+Fixes: 457c4cbc5a3d ("[NET]: Make /proc/net per network namespace")
+Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
+Acked-by: Julian Anastasov <ja@ssi.bg>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/ipvs/ip_vs_app.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c
+index f9b16f2b2219..fdacbc3c15be 100644
+--- a/net/netfilter/ipvs/ip_vs_app.c
++++ b/net/netfilter/ipvs/ip_vs_app.c
+@@ -599,13 +599,19 @@ static const struct seq_operations ip_vs_app_seq_ops = {
+ int __net_init ip_vs_app_net_init(struct netns_ipvs *ipvs)
+ {
+ INIT_LIST_HEAD(&ipvs->app_list);
+- proc_create_net("ip_vs_app", 0, ipvs->net->proc_net, &ip_vs_app_seq_ops,
+- sizeof(struct seq_net_private));
++#ifdef CONFIG_PROC_FS
++ if (!proc_create_net("ip_vs_app", 0, ipvs->net->proc_net,
++ &ip_vs_app_seq_ops,
++ sizeof(struct seq_net_private)))
++ return -ENOMEM;
++#endif
+ return 0;
+ }
+
+ void __net_exit ip_vs_app_net_cleanup(struct netns_ipvs *ipvs)
+ {
+ unregister_ip_vs_app(ipvs, NULL /* all */);
++#ifdef CONFIG_PROC_FS
+ remove_proc_entry("ip_vs_app", ipvs->net->proc_net);
++#endif
+ }
+--
+2.35.1
+
--- /dev/null
+From 4f7c3666110e11e944d0f3677a6d76ad064a4c47 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 26 Oct 2022 14:32:16 +0200
+Subject: ipvs: use explicitly signed chars
+
+From: Jason A. Donenfeld <Jason@zx2c4.com>
+
+[ Upstream commit 5c26159c97b324dc5174a5713eafb8c855cf8106 ]
+
+The `char` type with no explicit sign is sometimes signed and sometimes
+unsigned. This code will break on platforms such as arm, where char is
+unsigned. So mark it here as explicitly signed, so that the
+todrop_counter decrement and subsequent comparison is correct.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Acked-by: Julian Anastasov <ja@ssi.bg>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
+index fb67f1ca2495..db13288fddfa 100644
+--- a/net/netfilter/ipvs/ip_vs_conn.c
++++ b/net/netfilter/ipvs/ip_vs_conn.c
+@@ -1265,8 +1265,8 @@ static inline int todrop_entry(struct ip_vs_conn *cp)
+ * The drop rate array needs tuning for real environments.
+ * Called from timer bh only => no locking
+ */
+- static const char todrop_rate[9] = {0, 1, 2, 3, 4, 5, 6, 7, 8};
+- static char todrop_counter[9] = {0};
++ static const signed char todrop_rate[9] = {0, 1, 2, 3, 4, 5, 6, 7, 8};
++ static signed char todrop_counter[9] = {0};
+ int i;
+
+ /* if the conn entry hasn't lasted for 60 seconds, don't drop it.
+--
+2.35.1
+
--- /dev/null
+From 8ecaa223fa41376598b4167456299543913895e5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 20:13:41 +0800
+Subject: isdn: mISDN: netjet: fix wrong check of device registration
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit bf00f5426074249058a106a6edbb89e4b25a4d79 ]
+
+The class is set in mISDN_register_device(), but if device_add() returns
+error, it will lead to delete a device without added, fix this by using
+device_is_registered() to check if the device is registered.
+
+Fixes: a900845e5661 ("mISDN: Add support for Traverse Technologies NETJet PCI cards")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/isdn/hardware/mISDN/netjet.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/isdn/hardware/mISDN/netjet.c b/drivers/isdn/hardware/mISDN/netjet.c
+index a52f275f8263..f8447135a902 100644
+--- a/drivers/isdn/hardware/mISDN/netjet.c
++++ b/drivers/isdn/hardware/mISDN/netjet.c
+@@ -956,7 +956,7 @@ nj_release(struct tiger_hw *card)
+ }
+ if (card->irq > 0)
+ free_irq(card->irq, card);
+- if (card->isac.dch.dev.dev.class)
++ if (device_is_registered(&card->isac.dch.dev.dev))
+ mISDN_unregister_device(&card->isac.dch.dev);
+
+ for (i = 0; i < 2; i++) {
+--
+2.35.1
+
--- /dev/null
+From 43a46d4834de681c2bd14db4be9bcec98c746234 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 20:13:40 +0800
+Subject: mISDN: fix possible memory leak in mISDN_register_device()
+
+From: Yang Yingliang <yangyingliang@huawei.com>
+
+[ Upstream commit e7d1d4d9ac0dfa40be4c2c8abd0731659869b297 ]
+
+Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
+bus_id string array"), the name of device is allocated dynamically,
+add put_device() to give up the reference, so that the name can be
+freed in kobject_cleanup() when the refcount is 0.
+
+Set device class before put_device() to avoid null release() function
+WARN message in device_release().
+
+Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
+Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/isdn/mISDN/core.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/isdn/mISDN/core.c b/drivers/isdn/mISDN/core.c
+index a41b4b264594..7ea0100f218a 100644
+--- a/drivers/isdn/mISDN/core.c
++++ b/drivers/isdn/mISDN/core.c
+@@ -233,11 +233,12 @@ mISDN_register_device(struct mISDNdevice *dev,
+ if (debug & DEBUG_CORE)
+ printk(KERN_DEBUG "mISDN_register %s %d\n",
+ dev_name(&dev->dev), dev->id);
++ dev->dev.class = &mISDN_class;
++
+ err = create_stack(dev);
+ if (err)
+ goto error1;
+
+- dev->dev.class = &mISDN_class;
+ dev->dev.platform_data = dev;
+ dev->dev.parent = parent;
+ dev_set_drvdata(&dev->dev, dev);
+@@ -249,8 +250,8 @@ mISDN_register_device(struct mISDNdevice *dev,
+
+ error3:
+ delete_stack(dev);
+- return err;
+ error1:
++ put_device(&dev->dev);
+ return err;
+
+ }
+--
+2.35.1
+
--- /dev/null
+From 0ee13cd5dc554e3297cf5bc8017a61d9ff9a5ba1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Oct 2022 17:54:39 +0300
+Subject: net: dsa: fall back to default tagger if we can't load the one from
+ DT
+
+From: Vladimir Oltean <vladimir.oltean@nxp.com>
+
+[ Upstream commit a2c65a9d0568b6737c02b54f00b80716a53fac61 ]
+
+DSA tagging protocol drivers can be changed at runtime through sysfs and
+at probe time through the device tree (support for the latter was added
+later).
+
+When changing through sysfs, it is assumed that the module for the new
+tagging protocol was already loaded into the kernel (in fact this is
+only a concern for Ocelot/Felix switches, where we have tag_ocelot.ko
+and tag_ocelot_8021q.ko; for every other switch, the default and
+alternative protocols are compiled within the same .ko, so there is
+nothing for the user to load).
+
+The kernel cannot currently call request_module(), because it has no way
+of constructing the modalias name of the tagging protocol driver
+("dsa_tag-%d", where the number is one of DSA_TAG_PROTO_*_VALUE).
+The device tree only contains the string name of the tagging protocol
+("ocelot-8021q"), and the only mapping between the string and the
+DSA_TAG_PROTO_OCELOT_8021Q_VALUE is present in tag_ocelot_8021q.ko.
+So this is a chicken-and-egg situation and dsa_core.ko has nothing based
+on which it can automatically request the insertion of the module.
+
+As a consequence, if CONFIG_NET_DSA_TAG_OCELOT_8021Q is built as module,
+the switch will forever defer probing.
+
+The long-term solution is to make DSA call request_module() somehow,
+but that probably needs some refactoring.
+
+What we can do to keep operating with existing device tree blobs is to
+cancel the attempt to change the tagging protocol with the one specified
+there, and to remain operating with the default one. Depending on the
+situation, the default protocol might still allow some functionality
+(in the case of ocelot, it does), and it's better to have that than to
+fail to probe.
+
+Fixes: deff710703d8 ("net: dsa: Allow default tag protocol to be overridden from DT")
+Link: https://lore.kernel.org/lkml/20221027113248.420216-1-michael@walle.cc/
+Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
+Reported-by: Michael Walle <michael@walle.cc>
+Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Tested-by: Michael Walle <michael@walle.cc>
+Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
+Link: https://lore.kernel.org/r/20221027145439.3086017-1-vladimir.oltean@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/dsa/dsa2.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
+index cac48a741f27..e537655e442b 100644
+--- a/net/dsa/dsa2.c
++++ b/net/dsa/dsa2.c
+@@ -1407,9 +1407,9 @@ static enum dsa_tag_protocol dsa_get_tag_protocol(struct dsa_port *dp,
+ static int dsa_port_parse_cpu(struct dsa_port *dp, struct net_device *master,
+ const char *user_protocol)
+ {
++ const struct dsa_device_ops *tag_ops = NULL;
+ struct dsa_switch *ds = dp->ds;
+ struct dsa_switch_tree *dst = ds->dst;
+- const struct dsa_device_ops *tag_ops;
+ enum dsa_tag_protocol default_proto;
+
+ /* Find out which protocol the switch would prefer. */
+@@ -1432,10 +1432,17 @@ static int dsa_port_parse_cpu(struct dsa_port *dp, struct net_device *master,
+ }
+
+ tag_ops = dsa_find_tagger_by_name(user_protocol);
+- } else {
+- tag_ops = dsa_tag_driver_get(default_proto);
++ if (IS_ERR(tag_ops)) {
++ dev_warn(ds->dev,
++ "Failed to find a tagging driver for protocol %s, using default\n",
++ user_protocol);
++ tag_ops = NULL;
++ }
+ }
+
++ if (!tag_ops)
++ tag_ops = dsa_tag_driver_get(default_proto);
++
+ if (IS_ERR(tag_ops)) {
+ if (PTR_ERR(tag_ops) == -ENOPROTOOPT)
+ return -EPROBE_DEFER;
+--
+2.35.1
+
--- /dev/null
+From d97fa3abc9993fd86f9cbb1c87173f07a9dddf0a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 26 Oct 2022 10:03:21 +0800
+Subject: net: dsa: Fix possible memory leaks in dsa_loop_init()
+
+From: Chen Zhongjin <chenzhongjin@huawei.com>
+
+[ Upstream commit 633efc8b3dc96f56f5a57f2a49764853a2fa3f50 ]
+
+kmemleak reported memory leaks in dsa_loop_init():
+
+kmemleak: 12 new suspected memory leaks
+
+unreferenced object 0xffff8880138ce000 (size 2048):
+ comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)
+ backtrace:
+ [<000000006a94f1d5>] kmalloc_trace+0x26/0x60
+ [<00000000a9c44622>] phy_device_create+0x5d/0x970
+ [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0
+ [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0
+ [<000000008a834798>] fixed_phy_register+0x84/0xb0
+ [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop]
+ ...
+
+There are two reasons for memleak in dsa_loop_init().
+
+First, fixed_phy_register() create and register phy_device:
+
+fixed_phy_register()
+ get_phy_device()
+ phy_device_create() # freed by phy_device_free()
+ phy_device_register() # freed by phy_device_remove()
+
+But fixed_phy_unregister() only calls phy_device_remove().
+So the memory allocated in phy_device_create() is leaked.
+
+Second, when mdio_driver_register() fail in dsa_loop_init(),
+it just returns and there is no cleanup for phydevs.
+
+Fix the problems by catching the error of mdio_driver_register()
+in dsa_loop_init(), then calling both fixed_phy_unregister() and
+phy_device_free() to release phydevs.
+Also add a function for phydevs cleanup to avoid duplacate.
+
+Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
+Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/dsa/dsa_loop.c | 25 ++++++++++++++++++-------
+ 1 file changed, 18 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
+index 263e41191c29..0d20ebafbd03 100644
+--- a/drivers/net/dsa/dsa_loop.c
++++ b/drivers/net/dsa/dsa_loop.c
+@@ -378,6 +378,17 @@ static struct mdio_driver dsa_loop_drv = {
+
+ #define NUM_FIXED_PHYS (DSA_LOOP_NUM_PORTS - 2)
+
++static void dsa_loop_phydevs_unregister(void)
++{
++ unsigned int i;
++
++ for (i = 0; i < NUM_FIXED_PHYS; i++)
++ if (!IS_ERR(phydevs[i])) {
++ fixed_phy_unregister(phydevs[i]);
++ phy_device_free(phydevs[i]);
++ }
++}
++
+ static int __init dsa_loop_init(void)
+ {
+ struct fixed_phy_status status = {
+@@ -385,23 +396,23 @@ static int __init dsa_loop_init(void)
+ .speed = SPEED_100,
+ .duplex = DUPLEX_FULL,
+ };
+- unsigned int i;
++ unsigned int i, ret;
+
+ for (i = 0; i < NUM_FIXED_PHYS; i++)
+ phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL);
+
+- return mdio_driver_register(&dsa_loop_drv);
++ ret = mdio_driver_register(&dsa_loop_drv);
++ if (ret)
++ dsa_loop_phydevs_unregister();
++
++ return ret;
+ }
+ module_init(dsa_loop_init);
+
+ static void __exit dsa_loop_exit(void)
+ {
+- unsigned int i;
+-
+ mdio_driver_unregister(&dsa_loop_drv);
+- for (i = 0; i < NUM_FIXED_PHYS; i++)
+- if (!IS_ERR(phydevs[i]))
+- fixed_phy_unregister(phydevs[i]);
++ dsa_loop_phydevs_unregister();
+ }
+ module_exit(dsa_loop_exit);
+
+--
+2.35.1
+
--- /dev/null
+From 7c17f26bcaf2848ef9fb03142772bbeaae5349b4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 10:09:11 +0800
+Subject: net: fec: fix improper use of NETDEV_TX_BUSY
+
+From: Zhang Changzhong <zhangchangzhong@huawei.com>
+
+[ Upstream commit 06a4df5863f73af193a4ff7abf7cb04058584f06 ]
+
+The ndo_start_xmit() method must not free skb when returning
+NETDEV_TX_BUSY, since caller is going to requeue freed skb.
+
+Fix it by returning NETDEV_TX_OK in case of dma_map_single() fails.
+
+Fixes: 79f339125ea3 ("net: fec: Add software TSO support")
+Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/freescale/fec_main.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
+index a486435ceee2..5aa254eaa8d0 100644
+--- a/drivers/net/ethernet/freescale/fec_main.c
++++ b/drivers/net/ethernet/freescale/fec_main.c
+@@ -657,7 +657,7 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb,
+ dev_kfree_skb_any(skb);
+ if (net_ratelimit())
+ netdev_err(ndev, "Tx DMA memory map failed\n");
+- return NETDEV_TX_BUSY;
++ return NETDEV_TX_OK;
+ }
+
+ bdp->cbd_datlen = cpu_to_fec16(size);
+@@ -719,7 +719,7 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq,
+ dev_kfree_skb_any(skb);
+ if (net_ratelimit())
+ netdev_err(ndev, "Tx DMA memory map failed\n");
+- return NETDEV_TX_BUSY;
++ return NETDEV_TX_OK;
+ }
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 616622763803f218f1f7e8988fe11db54f5e1fb3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 30 Oct 2022 22:36:35 +0100
+Subject: net: lan966x: Adjust maximum frame size when vlan is enabled/disabled
+
+From: Horatiu Vultur <horatiu.vultur@microchip.com>
+
+[ Upstream commit 25f28bb1b4a7717a9df3aa574d210374ebb6bb23 ]
+
+When vlan filtering is enabled/disabled, it is required to adjust the
+maximum received frame size that it can received. When vlan filtering is
+enabled, it would all to receive extra 4 bytes, that are the vlan tag.
+So the maximum frame size would be 1522 with a vlan tag. If vlan
+filtering is disabled then the maximum frame size would be 1518
+regardless if there is or not a vlan tag.
+
+Fixes: 6d2c186afa5d ("net: lan966x: Add vlan support.")
+Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../net/ethernet/microchip/lan966x/lan966x_regs.h | 15 +++++++++++++++
+ .../net/ethernet/microchip/lan966x/lan966x_vlan.c | 6 ++++++
+ 2 files changed, 21 insertions(+)
+
+diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
+index 8265ad89f0bc..357ecc2f1089 100644
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h
+@@ -444,6 +444,21 @@ enum lan966x_target {
+ #define DEV_MAC_MAXLEN_CFG_MAX_LEN_GET(x)\
+ FIELD_GET(DEV_MAC_MAXLEN_CFG_MAX_LEN, x)
+
++/* DEV:MAC_CFG_STATUS:MAC_TAGS_CFG */
++#define DEV_MAC_TAGS_CFG(t) __REG(TARGET_DEV, t, 8, 28, 0, 1, 44, 12, 0, 1, 4)
++
++#define DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA BIT(1)
++#define DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA_SET(x)\
++ FIELD_PREP(DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA, x)
++#define DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA_GET(x)\
++ FIELD_GET(DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA, x)
++
++#define DEV_MAC_TAGS_CFG_VLAN_AWR_ENA BIT(0)
++#define DEV_MAC_TAGS_CFG_VLAN_AWR_ENA_SET(x)\
++ FIELD_PREP(DEV_MAC_TAGS_CFG_VLAN_AWR_ENA, x)
++#define DEV_MAC_TAGS_CFG_VLAN_AWR_ENA_GET(x)\
++ FIELD_GET(DEV_MAC_TAGS_CFG_VLAN_AWR_ENA, x)
++
+ /* DEV:MAC_CFG_STATUS:MAC_IFG_CFG */
+ #define DEV_MAC_IFG_CFG(t) __REG(TARGET_DEV, t, 8, 28, 0, 1, 44, 20, 0, 1, 4)
+
+diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c b/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c
+index 8d7260cd7da9..3c44660128da 100644
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c
+@@ -169,6 +169,12 @@ void lan966x_vlan_port_apply(struct lan966x_port *port)
+ ANA_VLAN_CFG_VLAN_POP_CNT,
+ lan966x, ANA_VLAN_CFG(port->chip_port));
+
++ lan_rmw(DEV_MAC_TAGS_CFG_VLAN_AWR_ENA_SET(port->vlan_aware) |
++ DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA_SET(port->vlan_aware),
++ DEV_MAC_TAGS_CFG_VLAN_AWR_ENA |
++ DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA,
++ lan966x, DEV_MAC_TAGS_CFG(port->chip_port));
++
+ /* Drop frames with multicast source address */
+ val = ANA_DROP_CFG_DROP_MC_SMAC_ENA_SET(1);
+ if (port->vlan_aware && !pvid)
+--
+2.35.1
+
--- /dev/null
+From 42e88d53d65f698a00175c5f02166900713aa704 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 30 Oct 2022 22:36:36 +0100
+Subject: net: lan966x: Fix FDMA when MTU is changed
+
+From: Horatiu Vultur <horatiu.vultur@microchip.com>
+
+[ Upstream commit 872ad758f9b7fb4eb42aebaf64e50c5b29b7ffe5 ]
+
+When MTU is changed, FDMA is required to calculate what is the maximum
+size of the frame that it can received. So it can calculate what is the
+page order needed to allocate for the received frames.
+The first problem was that, when the max MTU was calculated it was
+reading the value from dev and not from HW, so in this way it was
+missing L2 header + the FCS.
+The other problem was that once the skb is created using
+__build_skb_around, it would reserve some space for skb_shared_info.
+So if we received a frame which size is at the limit of the page order
+then the creating will failed because it would not have space to put all
+the data.
+
+Fixes: 2ea1cbac267e ("net: lan966x: Update FDMA to change MTU.")
+Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 8 ++++++--
+ drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 2 +-
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+index 69f741db25b1..407a6c125515 100644
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+@@ -668,12 +668,14 @@ static int lan966x_fdma_get_max_mtu(struct lan966x *lan966x)
+ int i;
+
+ for (i = 0; i < lan966x->num_phys_ports; ++i) {
++ struct lan966x_port *port;
+ int mtu;
+
+- if (!lan966x->ports[i])
++ port = lan966x->ports[i];
++ if (!port)
+ continue;
+
+- mtu = lan966x->ports[i]->dev->mtu;
++ mtu = lan_rd(lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port));
+ if (mtu > max_mtu)
+ max_mtu = mtu;
+ }
+@@ -733,6 +735,8 @@ int lan966x_fdma_change_mtu(struct lan966x *lan966x)
+
+ max_mtu = lan966x_fdma_get_max_mtu(lan966x);
+ max_mtu += IFH_LEN * sizeof(u32);
++ max_mtu += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
++ max_mtu += VLAN_HLEN * 2;
+
+ if (round_up(max_mtu, PAGE_SIZE) / PAGE_SIZE - 1 ==
+ lan966x->rx.page_order)
+diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+index 989e5f045d7e..4a3cb7579420 100644
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+@@ -394,7 +394,7 @@ static int lan966x_port_change_mtu(struct net_device *dev, int new_mtu)
+
+ err = lan966x_fdma_change_mtu(lan966x);
+ if (err) {
+- lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(old_mtu),
++ lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(LAN966X_HW_MTU(old_mtu)),
+ lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port));
+ dev->mtu = old_mtu;
+ }
+--
+2.35.1
+
--- /dev/null
+From 416215f65dc7a593ebbfd6c2b15da7a6ccaf9158 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 30 Oct 2022 22:36:34 +0100
+Subject: net: lan966x: Fix the MTU calculation
+
+From: Horatiu Vultur <horatiu.vultur@microchip.com>
+
+[ Upstream commit 486c292230166c2d61701d3c984bf9143588ea28 ]
+
+When the MTU was changed, the lan966x didn't take in consideration
+the L2 header and the FCS. So the HW was configured with a smaller
+value than what was desired. Therefore the correct value to configure
+the HW would be new_mtu + ETH_HLEN + ETH_FCS_LEN.
+The vlan tag is not considered here, because at the time when the
+blamed commit was added, there was no vlan filtering support. The
+vlan fix will be part of the next patch.
+
+Fixes: d28d6d2e37d1 ("net: lan966x: add port module support")
+Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 2 +-
+ drivers/net/ethernet/microchip/lan966x/lan966x_main.h | 2 ++
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+index d928b75f3780..989e5f045d7e 100644
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
+@@ -385,7 +385,7 @@ static int lan966x_port_change_mtu(struct net_device *dev, int new_mtu)
+ int old_mtu = dev->mtu;
+ int err;
+
+- lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(new_mtu),
++ lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(LAN966X_HW_MTU(new_mtu)),
+ lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port));
+ dev->mtu = new_mtu;
+
+diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
+index 2787055c1847..e316bfe186d7 100644
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
+@@ -24,6 +24,8 @@
+ #define LAN966X_BUFFER_MEMORY (160 * 1024)
+ #define LAN966X_BUFFER_MIN_SZ 60
+
++#define LAN966X_HW_MTU(mtu) ((mtu) + ETH_HLEN + ETH_FCS_LEN)
++
+ #define PGID_AGGR 64
+ #define PGID_SRC 80
+ #define PGID_ENTRIES 89
+--
+2.35.1
+
--- /dev/null
+From 56aca823041ec4ca097620b521ae0ade4e8f4f5d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 14:34:21 +0100
+Subject: net: lan966x: Fix unmapping of received frames using FDMA
+
+From: Horatiu Vultur <horatiu.vultur@microchip.com>
+
+[ Upstream commit fc57062f98b0b0ae52bc584d8fd5ac77c50df607 ]
+
+When lan966x was receiving a frame, then it was building the skb and
+after that it was calling dma_unmap_single with frame size as the
+length. This actually has 2 issues:
+1. It is using a length to map and a different length to unmap.
+2. When the unmap was happening, the data was sync for cpu but it could
+ be that this will overwrite what build_skb was initializing.
+
+The fix for these two problems is to change the order of operations.
+First to sync the frame for cpu, then to build the skb and in the end to
+unmap using the correct size but without sync the frame again for cpu.
+
+Fixes: c8349639324a ("net: lan966x: Add FDMA functionality")
+Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
+Link: https://lore.kernel.org/r/20221031133421.1283196-1-horatiu.vultur@microchip.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ .../ethernet/microchip/lan966x/lan966x_fdma.c | 18 ++++++++++++------
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+index 407a6c125515..3a1a0f9178c0 100644
+--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c
+@@ -414,13 +414,15 @@ static struct sk_buff *lan966x_fdma_rx_get_frame(struct lan966x_rx *rx)
+ /* Get the received frame and unmap it */
+ db = &rx->dcbs[rx->dcb_index].db[rx->db_index];
+ page = rx->page[rx->dcb_index][rx->db_index];
++
++ dma_sync_single_for_cpu(lan966x->dev, (dma_addr_t)db->dataptr,
++ FDMA_DCB_STATUS_BLOCKL(db->status),
++ DMA_FROM_DEVICE);
++
+ skb = build_skb(page_address(page), PAGE_SIZE << rx->page_order);
+ if (unlikely(!skb))
+ goto unmap_page;
+
+- dma_unmap_single(lan966x->dev, (dma_addr_t)db->dataptr,
+- FDMA_DCB_STATUS_BLOCKL(db->status),
+- DMA_FROM_DEVICE);
+ skb_put(skb, FDMA_DCB_STATUS_BLOCKL(db->status));
+
+ lan966x_ifh_get_src_port(skb->data, &src_port);
+@@ -429,6 +431,10 @@ static struct sk_buff *lan966x_fdma_rx_get_frame(struct lan966x_rx *rx)
+ if (WARN_ON(src_port >= lan966x->num_phys_ports))
+ goto free_skb;
+
++ dma_unmap_single_attrs(lan966x->dev, (dma_addr_t)db->dataptr,
++ PAGE_SIZE << rx->page_order, DMA_FROM_DEVICE,
++ DMA_ATTR_SKIP_CPU_SYNC);
++
+ skb->dev = lan966x->ports[src_port]->dev;
+ skb_pull(skb, IFH_LEN * sizeof(u32));
+
+@@ -454,9 +460,9 @@ static struct sk_buff *lan966x_fdma_rx_get_frame(struct lan966x_rx *rx)
+ free_skb:
+ kfree_skb(skb);
+ unmap_page:
+- dma_unmap_page(lan966x->dev, (dma_addr_t)db->dataptr,
+- FDMA_DCB_STATUS_BLOCKL(db->status),
+- DMA_FROM_DEVICE);
++ dma_unmap_single_attrs(lan966x->dev, (dma_addr_t)db->dataptr,
++ PAGE_SIZE << rx->page_order, DMA_FROM_DEVICE,
++ DMA_ATTR_SKIP_CPU_SYNC);
+ __free_pages(page, rx->page_order);
+
+ return NULL;
+--
+2.35.1
+
--- /dev/null
+From 50c53cb091abc72bfcadd3be8b46732b401f19bf Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 21:26:45 +0800
+Subject: net: mdio: fix undefined behavior in bit shift for __mdiobus_register
+
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+
+[ Upstream commit 40e4eb324c59e11fcb927aa46742d28aba6ecb8a ]
+
+Shifting signed 32-bit value by 31 bits is undefined, so changing
+significant bit to unsigned. The UBSAN warning calltrace like below:
+
+UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27
+left shift of 1 by 31 places cannot be represented in type 'int'
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x7d/0xa5
+ dump_stack+0x15/0x1b
+ ubsan_epilogue+0xe/0x4e
+ __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
+ __mdiobus_register+0x49d/0x4e0
+ fixed_mdio_bus_init+0xd8/0x12d
+ do_one_initcall+0x76/0x430
+ kernel_init_freeable+0x3b3/0x422
+ kernel_init+0x24/0x1e0
+ ret_from_fork+0x1f/0x30
+ </TASK>
+
+Fixes: 4fd5f812c23c ("phylib: allow incremental scanning of an mii bus")
+Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://lore.kernel.org/r/20221031132645.168421-1-cuigaosheng1@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/phy/mdio_bus.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
+index 8a2dbe849866..1bc988d9f2e8 100644
+--- a/drivers/net/phy/mdio_bus.c
++++ b/drivers/net/phy/mdio_bus.c
+@@ -583,7 +583,7 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner)
+ }
+
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+- if ((bus->phy_mask & (1 << i)) == 0) {
++ if ((bus->phy_mask & BIT(i)) == 0) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bus, i);
+--
+2.35.1
+
--- /dev/null
+From c7b867cca0f7028f73af9efac0270682a6b1a3f1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 20:15:52 +0800
+Subject: net, neigh: Fix null-ptr-deref in neigh_table_clear()
+
+From: Chen Zhongjin <chenzhongjin@huawei.com>
+
+[ Upstream commit f8017317cb0b279b8ab98b0f3901a2e0ac880dad ]
+
+When IPv6 module gets initialized but hits an error in the middle,
+kenel panic with:
+
+KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f]
+CPU: 1 PID: 361 Comm: insmod
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
+RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370
+RSP: 0018:ffff888012677908 EFLAGS: 00000202
+...
+Call Trace:
+ <TASK>
+ neigh_table_clear+0x94/0x2d0
+ ndisc_cleanup+0x27/0x40 [ipv6]
+ inet6_init+0x21c/0x2cb [ipv6]
+ do_one_initcall+0xd3/0x4d0
+ do_init_module+0x1ae/0x670
+...
+Kernel panic - not syncing: Fatal exception
+
+When ipv6 initialization fails, it will try to cleanup and calls:
+
+neigh_table_clear()
+ neigh_ifdown(tbl, NULL)
+ pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev == NULL))
+ # dev_net(NULL) triggers null-ptr-deref.
+
+Fix it by passing NULL to pneigh_queue_purge() in neigh_ifdown() if dev
+is NULL, to make kernel not panic immediately.
+
+Fixes: 66ba215cb513 ("neigh: fix possible DoS due to net iface start/stop loop")
+Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Reviewed-by: Denis V. Lunev <den@openvz.org>
+Link: https://lore.kernel.org/r/20221101121552.21890-1-chenzhongjin@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/core/neighbour.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/core/neighbour.c b/net/core/neighbour.c
+index 78cc8fb68814..84755db81e9d 100644
+--- a/net/core/neighbour.c
++++ b/net/core/neighbour.c
+@@ -409,7 +409,7 @@ static int __neigh_ifdown(struct neigh_table *tbl, struct net_device *dev,
+ write_lock_bh(&tbl->lock);
+ neigh_flush_dev(tbl, dev, skip_perm);
+ pneigh_ifdown_and_unlock(tbl, dev);
+- pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev));
++ pneigh_queue_purge(&tbl->proxy_queue, dev ? dev_net(dev) : NULL);
+ if (skb_queue_empty_lockless(&tbl->proxy_queue))
+ del_timer_sync(&tbl->proxy_timer);
+ return 0;
+--
+2.35.1
+
--- /dev/null
+From 188843d03e6105b324139179ea6fd3a4758b9b8d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Oct 2022 18:05:00 +0300
+Subject: net: sched: Fix use after free in red_enqueue()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9 ]
+
+We can't use "skb" again after passing it to qdisc_enqueue(). This is
+basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb
+len before calling child enqueue").
+
+Fixes: d7f4f332f082 ("sch_red: update backlog as well")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sched/sch_red.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c
+index f1e013e3f04a..935d90874b1b 100644
+--- a/net/sched/sch_red.c
++++ b/net/sched/sch_red.c
+@@ -72,6 +72,7 @@ static int red_enqueue(struct sk_buff *skb, struct Qdisc *sch,
+ {
+ struct red_sched_data *q = qdisc_priv(sch);
+ struct Qdisc *child = q->qdisc;
++ unsigned int len;
+ int ret;
+
+ q->vars.qavg = red_calc_qavg(&q->parms,
+@@ -126,9 +127,10 @@ static int red_enqueue(struct sk_buff *skb, struct Qdisc *sch,
+ break;
+ }
+
++ len = qdisc_pkt_len(skb);
+ ret = qdisc_enqueue(skb, child, to_free);
+ if (likely(ret == NET_XMIT_SUCCESS)) {
+- qdisc_qstats_backlog_inc(sch, skb);
++ sch->qstats.backlog += len;
+ sch->q.qlen++;
+ } else if (net_xmit_drop_count(ret)) {
+ q->stats.pdrop++;
+--
+2.35.1
+
--- /dev/null
+From 0a8b4c10373b50b734c1b32920adcfebf95f632f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 17:37:22 +0800
+Subject: net/smc: Fix possible leaked pernet namespace in smc_init()
+
+From: Chen Zhongjin <chenzhongjin@huawei.com>
+
+[ Upstream commit 62ff373da2534534c55debe6c724c7fe14adb97f ]
+
+In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called
+without any error handling.
+If it fails, registering of &smc_net_ops won't be reverted.
+And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted.
+
+This leaves wild ops in subsystem linkedlist and when another module
+tries to call register_pernet_operations() it triggers page fault:
+
+BUG: unable to handle page fault for address: fffffbfff81b964c
+RIP: 0010:register_pernet_operations+0x1b9/0x5f0
+Call Trace:
+ <TASK>
+ register_pernet_subsys+0x29/0x40
+ ebtables_init+0x58/0x1000 [ebtables]
+ ...
+
+Fixes: 194730a9beb5 ("net/smc: Make SMC statistics network namespace aware")
+Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
+Reviewed-by: Tony Lu <tonylu@linux.alibaba.com>
+Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
+Link: https://lore.kernel.org/r/20221101093722.127223-1-chenzhongjin@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/smc/af_smc.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
+index 0939cc3b915a..58ff5f33b370 100644
+--- a/net/smc/af_smc.c
++++ b/net/smc/af_smc.c
+@@ -3380,14 +3380,14 @@ static int __init smc_init(void)
+
+ rc = register_pernet_subsys(&smc_net_stat_ops);
+ if (rc)
+- return rc;
++ goto out_pernet_subsys;
+
+ smc_ism_init();
+ smc_clc_init();
+
+ rc = smc_nl_init();
+ if (rc)
+- goto out_pernet_subsys;
++ goto out_pernet_subsys_stat;
+
+ rc = smc_pnet_init();
+ if (rc)
+@@ -3480,6 +3480,8 @@ static int __init smc_init(void)
+ smc_pnet_exit();
+ out_nl:
+ smc_nl_exit();
++out_pernet_subsys_stat:
++ unregister_pernet_subsys(&smc_net_stat_ops);
+ out_pernet_subsys:
+ unregister_pernet_subsys(&smc_net_ops);
+
+--
+2.35.1
+
--- /dev/null
+From 72cbbdbd1abea7f44821de79cbaa4be4d1b7279f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 29 Oct 2022 17:41:01 +0800
+Subject: net: tun: fix bugs for oversize packet when napi frags enabled
+
+From: Ziyang Xuan <william.xuanziyang@huawei.com>
+
+[ Upstream commit 363a5328f4b0517e59572118ccfb7c626d81dca9 ]
+
+Recently, we got two syzkaller problems because of oversize packet
+when napi frags enabled.
+
+One of the problems is because the first seg size of the iov_iter
+from user space is very big, it is 2147479538 which is bigger than
+the threshold value for bail out early in __alloc_pages(). And
+skb->pfmemalloc is true, __kmalloc_reserve() would use pfmemalloc
+reserves without __GFP_NOWARN flag. Thus we got a warning as following:
+
+========================================================
+WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
+...
+Call trace:
+ __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295
+ __alloc_pages_node include/linux/gfp.h:550 [inline]
+ alloc_pages_node include/linux/gfp.h:564 [inline]
+ kmalloc_large_node+0x94/0x350 mm/slub.c:4038
+ __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545
+ __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151
+ pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654
+ __skb_grow include/linux/skbuff.h:2779 [inline]
+ tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477
+ tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835
+ tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036
+
+The other problem is because odd IPv6 packets without NEXTHDR_NONE
+extension header and have big packet length, it is 2127925 which is
+bigger than ETH_MAX_MTU(65535). After ipv6_gso_pull_exthdrs() in
+ipv6_gro_receive(), network_header offset and transport_header offset
+are all bigger than U16_MAX. That would trigger skb->network_header
+and skb->transport_header overflow error, because they are all '__u16'
+type. Eventually, it would affect the value for __skb_push(skb, value),
+and make it be a big value. After __skb_push() in ipv6_gro_receive(),
+skb->data would less than skb->head, an out of bounds memory bug occurred.
+That would trigger the problem as following:
+
+==================================================================
+BUG: KASAN: use-after-free in eth_type_trans+0x100/0x260
+...
+Call trace:
+ dump_backtrace+0xd8/0x130
+ show_stack+0x1c/0x50
+ dump_stack_lvl+0x64/0x7c
+ print_address_description.constprop.0+0xbc/0x2e8
+ print_report+0x100/0x1e4
+ kasan_report+0x80/0x120
+ __asan_load8+0x78/0xa0
+ eth_type_trans+0x100/0x260
+ napi_gro_frags+0x164/0x550
+ tun_get_user+0xda4/0x1270
+ tun_chr_write_iter+0x74/0x130
+ do_iter_readv_writev+0x130/0x1ec
+ do_iter_write+0xbc/0x1e0
+ vfs_writev+0x13c/0x26c
+
+To fix the problems, restrict the packet size less than
+(ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN) which has considered reserved
+skb space in napi_alloc_skb() because transport_header is an offset from
+skb->head. Add len check in tun_napi_alloc_frags() simply.
+
+Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver")
+Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20221029094101.1653855-1-william.xuanziyang@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/tun.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/tun.c b/drivers/net/tun.c
+index db736b944016..b02bd0a6c0a9 100644
+--- a/drivers/net/tun.c
++++ b/drivers/net/tun.c
+@@ -1459,7 +1459,8 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile,
+ int err;
+ int i;
+
+- if (it->nr_segs > MAX_SKB_FRAGS + 1)
++ if (it->nr_segs > MAX_SKB_FRAGS + 1 ||
++ len > (ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN))
+ return ERR_PTR(-EMSGSIZE);
+
+ local_bh_disable();
+--
+2.35.1
+
--- /dev/null
+From 4faab618d92e12b4f868d16f78aba77680d487c8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Nov 2022 10:40:47 +0100
+Subject: netfilter: ipset: enforce documented limit to prevent allocating huge
+ memory
+
+From: Jozsef Kadlecsik <kadlec@netfilter.org>
+
+[ Upstream commit 510841da1fcc16f702440ab58ef0b4d82a9056b7 ]
+
+Daniel Xu reported that the hash:net,iface type of the ipset subsystem does
+not limit adding the same network with different interfaces to a set, which
+can lead to huge memory usage or allocation failure.
+
+The quick reproducer is
+
+$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0
+$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done
+
+The backtrace when vmalloc fails:
+
+ [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages
+ <...>
+ [Tue Oct 25 00:13:08 2022] Call Trace:
+ [Tue Oct 25 00:13:08 2022] <TASK>
+ [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60
+ [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180
+ [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760
+ [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20
+ [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90
+ [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0
+ [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710
+ <...>
+
+The fix is to enforce the limit documented in the ipset(8) manpage:
+
+> The internal restriction of the hash:net,iface set type is that the same
+> network prefix cannot be stored with more than 64 different interfaces
+> in a single set.
+
+Fixes: ccf0a4b7fc68 ("netfilter: ipset: Add bucketsize parameter to all hash types")
+Reported-by: Daniel Xu <dxu@dxuuu.xyz>
+Signed-off-by: Jozsef Kadlecsik <kadlec@netfilter.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/ipset/ip_set_hash_gen.h | 30 ++++++---------------------
+ 1 file changed, 6 insertions(+), 24 deletions(-)
+
+diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h
+index 6e391308431d..3adc291d9ce1 100644
+--- a/net/netfilter/ipset/ip_set_hash_gen.h
++++ b/net/netfilter/ipset/ip_set_hash_gen.h
+@@ -42,31 +42,8 @@
+ #define AHASH_MAX_SIZE (6 * AHASH_INIT_SIZE)
+ /* Max muber of elements in the array block when tuned */
+ #define AHASH_MAX_TUNED 64
+-
+ #define AHASH_MAX(h) ((h)->bucketsize)
+
+-/* Max number of elements can be tuned */
+-#ifdef IP_SET_HASH_WITH_MULTI
+-static u8
+-tune_bucketsize(u8 curr, u32 multi)
+-{
+- u32 n;
+-
+- if (multi < curr)
+- return curr;
+-
+- n = curr + AHASH_INIT_SIZE;
+- /* Currently, at listing one hash bucket must fit into a message.
+- * Therefore we have a hard limit here.
+- */
+- return n > curr && n <= AHASH_MAX_TUNED ? n : curr;
+-}
+-#define TUNE_BUCKETSIZE(h, multi) \
+- ((h)->bucketsize = tune_bucketsize((h)->bucketsize, multi))
+-#else
+-#define TUNE_BUCKETSIZE(h, multi)
+-#endif
+-
+ /* A hash bucket */
+ struct hbucket {
+ struct rcu_head rcu; /* for call_rcu */
+@@ -936,7 +913,12 @@ mtype_add(struct ip_set *set, void *value, const struct ip_set_ext *ext,
+ goto set_full;
+ /* Create a new slot */
+ if (n->pos >= n->size) {
+- TUNE_BUCKETSIZE(h, multi);
++#ifdef IP_SET_HASH_WITH_MULTI
++ if (h->bucketsize >= AHASH_MAX_TUNED)
++ goto set_full;
++ else if (h->bucketsize < multi)
++ h->bucketsize += AHASH_INIT_SIZE;
++#endif
+ if (n->size >= AHASH_MAX(h)) {
+ /* Trigger rehashing */
+ mtype_data_next(&h->next, d);
+--
+2.35.1
+
--- /dev/null
+From 2e20e22894b9ca91f8e4f3b5302b98334da18649 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 26 Oct 2022 09:52:36 +0200
+Subject: netfilter: nf_tables: netlink notifier might race to release objects
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+[ Upstream commit d4bc8271db21ea9f1c86a1ca4d64999f184d4aae ]
+
+commit release path is invoked via call_rcu and it runs lockless to
+release the objects after rcu grace period. The netlink notifier handler
+might win race to remove objects that the transaction context is still
+referencing from the commit release path.
+
+Call rcu_barrier() to ensure pending rcu callbacks run to completion
+if the list of transactions to be destroyed is not empty.
+
+Fixes: 6001a930ce03 ("netfilter: nftables: introduce table ownership")
+Reported-by: syzbot+8f747f62763bc6c32916@syzkaller.appspotmail.com
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_tables_api.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
+index 5897afd12466..cc598504bc10 100644
+--- a/net/netfilter/nf_tables_api.c
++++ b/net/netfilter/nf_tables_api.c
+@@ -10030,6 +10030,8 @@ static int nft_rcv_nl_event(struct notifier_block *this, unsigned long event,
+ nft_net = nft_pernet(net);
+ deleted = 0;
+ mutex_lock(&nft_net->commit_mutex);
++ if (!list_empty(&nf_tables_destroy_list))
++ rcu_barrier();
+ again:
+ list_for_each_entry(table, &nft_net->tables, list) {
+ if (nft_table_has_owner(table) &&
+--
+2.35.1
+
--- /dev/null
+From 10f5188b3f8660690be88fb9ec220f199d18044c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 26 Oct 2022 09:54:45 +0200
+Subject: netfilter: nf_tables: release flow rule object from commit path
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+[ Upstream commit 26b5934ff4194e13196bedcba373cd4915071d0e ]
+
+No need to postpone this to the commit release path, since no packets
+are walking over this object, this is accessed from control plane only.
+This helped uncovered UAF triggered by races with the netlink notifier.
+
+Fixes: 9dd732e0bdf5 ("netfilter: nf_tables: memleak flow rule from commit path")
+Reported-by: syzbot+8f747f62763bc6c32916@syzkaller.appspotmail.com
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/netfilter/nf_tables_api.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
+index cc598504bc10..879f4a1a27d5 100644
+--- a/net/netfilter/nf_tables_api.c
++++ b/net/netfilter/nf_tables_api.c
+@@ -8465,9 +8465,6 @@ static void nft_commit_release(struct nft_trans *trans)
+ nf_tables_chain_destroy(&trans->ctx);
+ break;
+ case NFT_MSG_DELRULE:
+- if (trans->ctx.chain->flags & NFT_CHAIN_HW_OFFLOAD)
+- nft_flow_rule_destroy(nft_trans_flow_rule(trans));
+-
+ nf_tables_rule_destroy(&trans->ctx, nft_trans_rule(trans));
+ break;
+ case NFT_MSG_DELSET:
+@@ -8973,6 +8970,9 @@ static int nf_tables_commit(struct net *net, struct sk_buff *skb)
+ nft_rule_expr_deactivate(&trans->ctx,
+ nft_trans_rule(trans),
+ NFT_TRANS_COMMIT);
++
++ if (trans->ctx.chain->flags & NFT_CHAIN_HW_OFFLOAD)
++ nft_flow_rule_destroy(nft_trans_flow_rule(trans));
+ break;
+ case NFT_MSG_NEWSET:
+ nft_clear(net, nft_trans_set(trans));
+--
+2.35.1
+
--- /dev/null
+From 1700a6dadb973a420cf15f564bb76f8678d8ab4c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Oct 2022 22:03:29 +0800
+Subject: nfc: fdp: Fix potential memory leak in fdp_nci_send()
+
+From: Shang XiaoJing <shangxiaojing@huawei.com>
+
+[ Upstream commit 8e4aae6b8ca76afb1fb64dcb24be44ba814e7f8a ]
+
+fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in
+the function. As a result, when fdp_nci_i2c_write() finished, the skb
+will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write()
+finished.
+
+Fixes: a06347c04c13 ("NFC: Add Intel Fields Peak NFC solution driver")
+Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nfc/fdp/fdp.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c
+index c6b3334f24c9..f12f903a9dd1 100644
+--- a/drivers/nfc/fdp/fdp.c
++++ b/drivers/nfc/fdp/fdp.c
+@@ -249,11 +249,19 @@ static int fdp_nci_close(struct nci_dev *ndev)
+ static int fdp_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
+ {
+ struct fdp_nci_info *info = nci_get_drvdata(ndev);
++ int ret;
+
+ if (atomic_dec_and_test(&info->data_pkt_counter))
+ info->data_pkt_counter_cb(ndev);
+
+- return info->phy_ops->write(info->phy, skb);
++ ret = info->phy_ops->write(info->phy, skb);
++ if (ret < 0) {
++ kfree_skb(skb);
++ return ret;
++ }
++
++ consume_skb(skb);
++ return 0;
+ }
+
+ static int fdp_nci_request_firmware(struct nci_dev *ndev)
+--
+2.35.1
+
--- /dev/null
+From 7e0dc24aa274b8a5026c95ae54808e5ac2bee454 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Oct 2022 22:03:32 +0800
+Subject: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send()
+
+From: Shang XiaoJing <shangxiaojing@huawei.com>
+
+[ Upstream commit 93d904a734a74c54d945a9884b4962977f1176cd ]
+
+nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb
+should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send()
+will only free skb when i2c_master_send() return >=0, which means skb
+will memleak when i2c_master_send() failed. Free skb no matter whether
+i2c_master_send() succeeds.
+
+Fixes: b5b3e23e4cac ("NFC: nfcmrvl: add i2c driver")
+Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nfc/nfcmrvl/i2c.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/nfc/nfcmrvl/i2c.c b/drivers/nfc/nfcmrvl/i2c.c
+index 01329b91d59d..a902720cd849 100644
+--- a/drivers/nfc/nfcmrvl/i2c.c
++++ b/drivers/nfc/nfcmrvl/i2c.c
+@@ -132,10 +132,15 @@ static int nfcmrvl_i2c_nci_send(struct nfcmrvl_private *priv,
+ ret = -EREMOTEIO;
+ } else
+ ret = 0;
++ }
++
++ if (ret) {
+ kfree_skb(skb);
++ return ret;
+ }
+
+- return ret;
++ consume_skb(skb);
++ return 0;
+ }
+
+ static void nfcmrvl_i2c_nci_update_config(struct nfcmrvl_private *priv,
+--
+2.35.1
+
--- /dev/null
+From 9ca79d3e0c9ae3aa501d31b2e06a0c6ad3f5c695 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Oct 2022 22:03:30 +0800
+Subject: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send()
+
+From: Shang XiaoJing <shangxiaojing@huawei.com>
+
+[ Upstream commit 7bf1ed6aff0f70434bd0cdd45495e83f1dffb551 ]
+
+nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when
+nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write()
+run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the
+result, the skb will memleak. nxp_nci_send() should also free the skb
+when nxp_nci_i2c_write() succeeds.
+
+Fixes: dece45855a8b ("NFC: nxp-nci: Add support for NXP NCI chips")
+Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nfc/nxp-nci/core.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/nfc/nxp-nci/core.c b/drivers/nfc/nxp-nci/core.c
+index 7c93d484dc1b..580cb6ecffee 100644
+--- a/drivers/nfc/nxp-nci/core.c
++++ b/drivers/nfc/nxp-nci/core.c
+@@ -80,10 +80,13 @@ static int nxp_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
+ return -EINVAL;
+
+ r = info->phy_ops->write(info->phy_id, skb);
+- if (r < 0)
++ if (r < 0) {
+ kfree_skb(skb);
++ return r;
++ }
+
+- return r;
++ consume_skb(skb);
++ return 0;
+ }
+
+ static int nxp_nci_rf_pll_unlocked_ntf(struct nci_dev *ndev,
+--
+2.35.1
+
--- /dev/null
+From 250b310a5536b3313eae5fcf6a9f8d7f125dc639 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 27 Oct 2022 22:03:31 +0800
+Subject: nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send()
+
+From: Shang XiaoJing <shangxiaojing@huawei.com>
+
+[ Upstream commit 3a146b7e3099dc7cf3114f627d9b79291e2d2203 ]
+
+s3fwrn5_nci_send() will call s3fwrn5_i2c_write() or s3fwrn82_uart_write(),
+and free the skb if write() failed. However, even if the write() run
+succeeds, the skb will not be freed in write(). As the result, the skb
+will memleak. s3fwrn5_nci_send() should also free the skb when write()
+succeeds.
+
+Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip")
+Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nfc/s3fwrn5/core.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/nfc/s3fwrn5/core.c b/drivers/nfc/s3fwrn5/core.c
+index 1c412007fabb..0270e05b68df 100644
+--- a/drivers/nfc/s3fwrn5/core.c
++++ b/drivers/nfc/s3fwrn5/core.c
+@@ -110,11 +110,15 @@ static int s3fwrn5_nci_send(struct nci_dev *ndev, struct sk_buff *skb)
+ }
+
+ ret = s3fwrn5_write(info, skb);
+- if (ret < 0)
++ if (ret < 0) {
+ kfree_skb(skb);
++ mutex_unlock(&info->mutex);
++ return ret;
++ }
+
++ consume_skb(skb);
+ mutex_unlock(&info->mutex);
+- return ret;
++ return 0;
+ }
+
+ static int s3fwrn5_nci_post_setup(struct nci_dev *ndev)
+--
+2.35.1
+
--- /dev/null
+From 97c4e0184a4ce630276bb0f131ab7a92a6f77e74 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Oct 2022 11:20:54 +0800
+Subject: nfs4: Fix kmemleak when allocate slot failed
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+[ Upstream commit 7e8436728e22181c3f12a5dbabd35ed3a8b8c593 ]
+
+If one of the slot allocate failed, should cleanup all the other
+allocated slots, otherwise, the allocated slots will leak:
+
+ unreferenced object 0xffff8881115aa100 (size 64):
+ comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)
+ hex dump (first 32 bytes):
+ 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130
+ [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270
+ [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90
+ [<00000000128486db>] nfs4_init_client+0xce/0x270
+ [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0
+ [<000000000e593b52>] nfs4_create_server+0x300/0x5f0
+ [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110
+ [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0
+ [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0
+ [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0
+ [<000000005d56bdec>] do_syscall_64+0x35/0x80
+ [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
+
+Fixes: abf79bb341bf ("NFS: Add a slot table to struct nfs_client for NFSv4.0 transport blocking")
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4client.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
+index 3c5678aec006..8ae2827da28d 100644
+--- a/fs/nfs/nfs4client.c
++++ b/fs/nfs/nfs4client.c
+@@ -346,6 +346,7 @@ int nfs40_init_client(struct nfs_client *clp)
+ ret = nfs4_setup_slot_table(tbl, NFS4_MAX_SLOT_TABLE,
+ "NFSv4.0 transport Slot table");
+ if (ret) {
++ nfs4_shutdown_slot_table(tbl);
+ kfree(tbl);
+ return ret;
+ }
+--
+2.35.1
+
--- /dev/null
+From aabd93fdc6cd0530484a77d4438ee28db19b2aea Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 11:49:21 -0400
+Subject: nfsd: fix net-namespace logic in __nfsd_file_cache_purge
+
+From: Jeff Layton <jlayton@kernel.org>
+
+[ Upstream commit d3aefd2b29ff5ffdeb5c06a7d3191a027a18cdb8 ]
+
+If the namespace doesn't match the one in "net", then we'll continue,
+but that doesn't cause another rhashtable_walk_next call, so it will
+loop infinitely.
+
+Fixes: ce502f81ba88 ("NFSD: Convert the filecache to use rhashtable")
+Reported-by: Petr Vorel <pvorel@suse.cz>
+Link: https://lore.kernel.org/ltp/Y1%2FP8gDAcWC%2F+VR3@pevik/
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/filecache.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
+index 844c41832d50..173b38ffa423 100644
+--- a/fs/nfsd/filecache.c
++++ b/fs/nfsd/filecache.c
+@@ -893,9 +893,8 @@ __nfsd_file_cache_purge(struct net *net)
+
+ nf = rhashtable_walk_next(&iter);
+ while (!IS_ERR_OR_NULL(nf)) {
+- if (net && nf->nf_net != net)
+- continue;
+- nfsd_file_unhash_and_dispose(nf, &dispose);
++ if (!net || nf->nf_net == net)
++ nfsd_file_unhash_and_dispose(nf, &dispose);
+ nf = rhashtable_walk_next(&iter);
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 1f7fbcae3a01c36ce66e09f845991cbd795db0e8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 30 Sep 2022 16:56:02 -0400
+Subject: nfsd: fix nfsd_file_unhash_and_dispose
+
+From: Jeff Layton <jlayton@kernel.org>
+
+[ Upstream commit 8d0d254b15cc5b7d46d85fb7ab8ecede9575e672 ]
+
+nfsd_file_unhash_and_dispose() is called for two reasons:
+
+We're either shutting down and purging the filecache, or we've gotten a
+notification about a file delete, so we want to go ahead and unhash it
+so that it'll get cleaned up when we close.
+
+We're either walking the hashtable or doing a lookup in it and we
+don't take a reference in either case. What we want to do in both cases
+is to try and unhash the object and put it on the dispose list if that
+was successful. If it's no longer hashed, then we don't want to touch
+it, with the assumption being that something else is already cleaning
+up the sentinel reference.
+
+Instead of trying to selectively decrement the refcount in this
+function, just unhash it, and if that was successful, move it to the
+dispose list. Then, the disposal routine will just clean that up as
+usual.
+
+Also, just make this a void function, drop the WARN_ON_ONCE, and the
+comments about deadlocking since the nature of the purported deadlock
+is no longer clear.
+
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Stable-dep-of: d3aefd2b29ff ("nfsd: fix net-namespace logic in __nfsd_file_cache_purge")
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/filecache.c | 36 +++++++-----------------------------
+ 1 file changed, 7 insertions(+), 29 deletions(-)
+
+diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
+index eeed4ae5b4ad..844c41832d50 100644
+--- a/fs/nfsd/filecache.c
++++ b/fs/nfsd/filecache.c
+@@ -405,22 +405,15 @@ nfsd_file_unhash(struct nfsd_file *nf)
+ return false;
+ }
+
+-/*
+- * Return true if the file was unhashed.
+- */
+-static bool
++static void
+ nfsd_file_unhash_and_dispose(struct nfsd_file *nf, struct list_head *dispose)
+ {
+ trace_nfsd_file_unhash_and_dispose(nf);
+- if (!nfsd_file_unhash(nf))
+- return false;
+- /* keep final reference for nfsd_file_lru_dispose */
+- if (refcount_dec_not_one(&nf->nf_ref))
+- return true;
+-
+- nfsd_file_lru_remove(nf);
+- list_add(&nf->nf_lru, dispose);
+- return true;
++ if (nfsd_file_unhash(nf)) {
++ /* caller must call nfsd_file_dispose_list() later */
++ nfsd_file_lru_remove(nf);
++ list_add(&nf->nf_lru, dispose);
++ }
+ }
+
+ static void
+@@ -562,8 +555,6 @@ nfsd_file_dispose_list_delayed(struct list_head *dispose)
+ * @lock: LRU list lock (unused)
+ * @arg: dispose list
+ *
+- * Note this can deadlock with nfsd_file_cache_purge.
+- *
+ * Return values:
+ * %LRU_REMOVED: @item was removed from the LRU
+ * %LRU_ROTATE: @item is to be moved to the LRU tail
+@@ -748,8 +739,6 @@ nfsd_file_close_inode(struct inode *inode)
+ *
+ * Walk the LRU list and close any entries that have not been used since
+ * the last scan.
+- *
+- * Note this can deadlock with nfsd_file_cache_purge.
+ */
+ static void
+ nfsd_file_delayed_close(struct work_struct *work)
+@@ -891,16 +880,12 @@ nfsd_file_cache_init(void)
+ goto out;
+ }
+
+-/*
+- * Note this can deadlock with nfsd_file_lru_cb.
+- */
+ static void
+ __nfsd_file_cache_purge(struct net *net)
+ {
+ struct rhashtable_iter iter;
+ struct nfsd_file *nf;
+ LIST_HEAD(dispose);
+- bool del;
+
+ rhashtable_walk_enter(&nfsd_file_rhash_tbl, &iter);
+ do {
+@@ -910,14 +895,7 @@ __nfsd_file_cache_purge(struct net *net)
+ while (!IS_ERR_OR_NULL(nf)) {
+ if (net && nf->nf_net != net)
+ continue;
+- del = nfsd_file_unhash_and_dispose(nf, &dispose);
+-
+- /*
+- * Deadlock detected! Something marked this entry as
+- * unhased, but hasn't removed it from the hash list.
+- */
+- WARN_ON_ONCE(!del);
+-
++ nfsd_file_unhash_and_dispose(nf, &dispose);
+ nf = rhashtable_walk_next(&iter);
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 1dd18ffadea024c4b5f8d4151827a9d044b1c9d8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 16 Oct 2022 14:44:31 -0400
+Subject: NFSv4: Fix a potential state reclaim deadlock
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+[ Upstream commit 1ba04394e028ea8b45d92685cc0d6ab582cf7647 ]
+
+If the server reboots while we are engaged in a delegation return, and
+there is a pNFS layout with return-on-close set, then the current code
+can end up deadlocking in pnfs_roc() when nfs_inode_set_delegation()
+tries to return the old delegation.
+Now that delegreturn actually uses its own copy of the stateid, it
+should be safe to just always update the delegation stateid in place.
+
+Fixes: 078000d02d57 ("pNFS: We want return-on-close to complete when evicting the inode")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/delegation.c | 36 +++++++++++++++++-------------------
+ 1 file changed, 17 insertions(+), 19 deletions(-)
+
+diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
+index 5c97cad741a7..ead8a0e06abf 100644
+--- a/fs/nfs/delegation.c
++++ b/fs/nfs/delegation.c
+@@ -228,8 +228,7 @@ static int nfs_delegation_claim_opens(struct inode *inode,
+ *
+ */
+ void nfs_inode_reclaim_delegation(struct inode *inode, const struct cred *cred,
+- fmode_t type,
+- const nfs4_stateid *stateid,
++ fmode_t type, const nfs4_stateid *stateid,
+ unsigned long pagemod_limit)
+ {
+ struct nfs_delegation *delegation;
+@@ -239,25 +238,24 @@ void nfs_inode_reclaim_delegation(struct inode *inode, const struct cred *cred,
+ delegation = rcu_dereference(NFS_I(inode)->delegation);
+ if (delegation != NULL) {
+ spin_lock(&delegation->lock);
+- if (nfs4_is_valid_delegation(delegation, 0)) {
+- nfs4_stateid_copy(&delegation->stateid, stateid);
+- delegation->type = type;
+- delegation->pagemod_limit = pagemod_limit;
+- oldcred = delegation->cred;
+- delegation->cred = get_cred(cred);
+- clear_bit(NFS_DELEGATION_NEED_RECLAIM,
+- &delegation->flags);
+- spin_unlock(&delegation->lock);
+- rcu_read_unlock();
+- put_cred(oldcred);
+- trace_nfs4_reclaim_delegation(inode, type);
+- return;
+- }
+- /* We appear to have raced with a delegation return. */
++ nfs4_stateid_copy(&delegation->stateid, stateid);
++ delegation->type = type;
++ delegation->pagemod_limit = pagemod_limit;
++ oldcred = delegation->cred;
++ delegation->cred = get_cred(cred);
++ clear_bit(NFS_DELEGATION_NEED_RECLAIM, &delegation->flags);
++ if (test_and_clear_bit(NFS_DELEGATION_REVOKED,
++ &delegation->flags))
++ atomic_long_inc(&nfs_active_delegations);
+ spin_unlock(&delegation->lock);
++ rcu_read_unlock();
++ put_cred(oldcred);
++ trace_nfs4_reclaim_delegation(inode, type);
++ } else {
++ rcu_read_unlock();
++ nfs_inode_set_delegation(inode, cred, type, stateid,
++ pagemod_limit);
+ }
+- rcu_read_unlock();
+- nfs_inode_set_delegation(inode, cred, type, stateid, pagemod_limit);
+ }
+
+ static int nfs_do_return_delegation(struct inode *inode, struct nfs_delegation *delegation, int issync)
+--
+2.35.1
+
--- /dev/null
+From 0e5faf3cb1a5594d47bdfdc95dd754ae76c6a4a6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 16 Oct 2022 14:44:32 -0400
+Subject: NFSv4.1: Handle RECLAIM_COMPLETE trunking errors
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+[ Upstream commit 5d917cba3201e5c25059df96c29252fd99c4f6a7 ]
+
+If RECLAIM_COMPLETE sets the NFS4CLNT_BIND_CONN_TO_SESSION flag, then we
+need to loop back in order to handle it.
+
+Fixes: 0048fdd06614 ("NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4state.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
+index 9bab3e9c702a..0b6bd6336c98 100644
+--- a/fs/nfs/nfs4state.c
++++ b/fs/nfs/nfs4state.c
+@@ -2671,6 +2671,7 @@ static void nfs4_state_manager(struct nfs_client *clp)
+ if (status < 0)
+ goto out_error;
+ nfs4_state_end_reclaim_reboot(clp);
++ continue;
+ }
+
+ /* Detect expired delegations... */
+--
+2.35.1
+
--- /dev/null
+From eccb60f57c7c672254086587d82614c74264ab6e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 16 Oct 2022 14:44:33 -0400
+Subject: NFSv4.1: We must always send RECLAIM_COMPLETE after a reboot
+
+From: Trond Myklebust <trond.myklebust@hammerspace.com>
+
+[ Upstream commit e59679f2b7e522ecad99974e5636291ffd47c184 ]
+
+Currently, we are only guaranteed to send RECLAIM_COMPLETE if we have
+open state to recover. Fix the client to always send RECLAIM_COMPLETE
+after setting up the lease.
+
+Fixes: fce5c838e133 ("nfs41: RECLAIM_COMPLETE functionality")
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4state.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
+index 0b6bd6336c98..a629d7db9420 100644
+--- a/fs/nfs/nfs4state.c
++++ b/fs/nfs/nfs4state.c
+@@ -1787,6 +1787,7 @@ static void nfs4_state_mark_reclaim_helper(struct nfs_client *clp,
+
+ static void nfs4_state_start_reclaim_reboot(struct nfs_client *clp)
+ {
++ set_bit(NFS4CLNT_RECLAIM_REBOOT, &clp->cl_state);
+ /* Mark all delegations for reclaim */
+ nfs_delegation_mark_reclaim(clp);
+ nfs4_state_mark_reclaim_helper(clp, nfs4_state_mark_reclaim_reboot);
+--
+2.35.1
+
--- /dev/null
+From 8e7a08a7683e427ce7bcb7dcb5ed47fc78b442b9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 13 Oct 2022 11:58:01 -0400
+Subject: NFSv4.2: Fixup CLONE dest file size for zero-length count
+
+From: Benjamin Coddington <bcodding@redhat.com>
+
+[ Upstream commit 038efb6348ce96228f6828354cb809c22a661681 ]
+
+When holding a delegation, the NFS client optimizes away setting the
+attributes of a file from the GETATTR in the compound after CLONE, and for
+a zero-length CLONE we will end up setting the inode's size to zero in
+nfs42_copy_dest_done(). Handle this case by computing the resulting count
+from the server's reported size after CLONE's GETATTR.
+
+Suggested-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
+Fixes: 94d202d5ca39 ("NFSv42: Copy offload should update the file size when appropriate")
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs42proc.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/nfs/nfs42proc.c b/fs/nfs/nfs42proc.c
+index 6dab9e408372..21c9e97c3ba3 100644
+--- a/fs/nfs/nfs42proc.c
++++ b/fs/nfs/nfs42proc.c
+@@ -1093,6 +1093,9 @@ static int _nfs42_proc_clone(struct rpc_message *msg, struct file *src_f,
+ &args.seq_args, &res.seq_res, 0);
+ trace_nfs4_clone(src_inode, dst_inode, &args, status);
+ if (status == 0) {
++ /* a zero-length count means clone to EOF in src */
++ if (count == 0 && res.dst_fattr->valid & NFS_ATTR_FATTR_SIZE)
++ count = nfs_size_to_loff_t(res.dst_fattr->size) - dst_offset;
+ nfs42_copy_dest_done(dst_inode, dst_offset, count);
+ status = nfs_post_op_update_inode(dst_inode, res.dst_fattr);
+ }
+--
+2.35.1
+
--- /dev/null
+From 034930e6e39abdbb8bfaafbf61a8784ee8888378 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Oct 2022 16:15:42 +0200
+Subject: RDMA/cma: Use output interface for net_dev check
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Håkon Bugge <haakon.bugge@oracle.com>
+
+[ Upstream commit eb83f502adb036cd56c27e13b9ca3b2aabfa790b ]
+
+Commit 27cfde795a96 ("RDMA/cma: Fix arguments order in net device
+validation") swapped the src and dst addresses in the call to
+validate_net_dev().
+
+As a consequence, the test in validate_ipv4_net_dev() to see if the
+net_dev is the right one, is incorrect for port 1 <-> 2 communication when
+the ports are on the same sub-net. This is fixed by denoting the
+flowi4_oif as the device instead of the incoming one.
+
+The bug has not been observed using IPv6 addresses.
+
+Fixes: 27cfde795a96 ("RDMA/cma: Fix arguments order in net device validation")
+Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
+Link: https://lore.kernel.org/r/20221012141542.16925-1-haakon.bugge@oracle.com
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/core/cma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
+index be317f2665a9..ff8821f79fec 100644
+--- a/drivers/infiniband/core/cma.c
++++ b/drivers/infiniband/core/cma.c
+@@ -1556,7 +1556,7 @@ static bool validate_ipv4_net_dev(struct net_device *net_dev,
+ return false;
+
+ memset(&fl4, 0, sizeof(fl4));
+- fl4.flowi4_iif = net_dev->ifindex;
++ fl4.flowi4_oif = net_dev->ifindex;
+ fl4.daddr = daddr;
+ fl4.saddr = saddr;
+
+--
+2.35.1
+
--- /dev/null
+From c5d120d0e42e8988bd93f550ab1a80c680581199 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 Oct 2022 10:41:46 +0800
+Subject: RDMA/core: Fix null-ptr-deref in ib_core_cleanup()
+
+From: Chen Zhongjin <chenzhongjin@huawei.com>
+
+[ Upstream commit 07c0d131cc0fe1f3981a42958fc52d573d303d89 ]
+
+KASAN reported a null-ptr-deref error:
+
+ KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
+ CPU: 1 PID: 379
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
+ RIP: 0010:destroy_workqueue+0x2f/0x740
+ RSP: 0018:ffff888016137df8 EFLAGS: 00000202
+ ...
+ Call Trace:
+ ib_core_cleanup+0xa/0xa1 [ib_core]
+ __do_sys_delete_module.constprop.0+0x34f/0x5b0
+ do_syscall_64+0x3a/0x90
+ entry_SYSCALL_64_after_hwframe+0x63/0xcd
+ RIP: 0033:0x7fa1a0d221b7
+ ...
+
+It is because the fail of roce_gid_mgmt_init() is ignored:
+
+ ib_core_init()
+ roce_gid_mgmt_init()
+ gid_cache_wq = alloc_ordered_workqueue # fail
+ ...
+ ib_core_cleanup()
+ roce_gid_mgmt_cleanup()
+ destroy_workqueue(gid_cache_wq)
+ # destroy an unallocated wq
+
+Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().
+
+Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management")
+Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
+Link: https://lore.kernel.org/r/20221025024146.109137-1-chenzhongjin@huawei.com
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/core/device.c | 10 +++++++++-
+ drivers/infiniband/core/nldev.c | 2 +-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
+index d275db195f1a..4053a09b8d33 100644
+--- a/drivers/infiniband/core/device.c
++++ b/drivers/infiniband/core/device.c
+@@ -2815,10 +2815,18 @@ static int __init ib_core_init(void)
+
+ nldev_init();
+ rdma_nl_register(RDMA_NL_LS, ibnl_ls_cb_table);
+- roce_gid_mgmt_init();
++ ret = roce_gid_mgmt_init();
++ if (ret) {
++ pr_warn("Couldn't init RoCE GID management\n");
++ goto err_parent;
++ }
+
+ return 0;
+
++err_parent:
++ rdma_nl_unregister(RDMA_NL_LS);
++ nldev_exit();
++ unregister_pernet_device(&rdma_dev_net_ops);
+ err_compat:
+ unregister_blocking_lsm_notifier(&ibdev_lsm_nb);
+ err_sa:
+diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c
+index b92358f606d0..12dc97067ed2 100644
+--- a/drivers/infiniband/core/nldev.c
++++ b/drivers/infiniband/core/nldev.c
+@@ -2537,7 +2537,7 @@ void __init nldev_init(void)
+ rdma_nl_register(RDMA_NL_NLDEV, nldev_cb_table);
+ }
+
+-void __exit nldev_exit(void)
++void nldev_exit(void)
+ {
+ rdma_nl_unregister(RDMA_NL_NLDEV);
+ }
+--
+2.35.1
+
--- /dev/null
+From e36ceba12eec88638cf9287195da759c5acd1426 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 24 Oct 2022 16:38:13 +0800
+Subject: RDMA/hns: Disable local invalidate operation
+
+From: Yangyang Li <liyangyang20@huawei.com>
+
+[ Upstream commit 9e272ed69ad6f6952fafd0599d6993575512408e ]
+
+When function reset and local invalidate are mixed, HNS RoCEE may hang.
+Before introducing the cause of the problem, two hardware internal
+concepts need to be introduced:
+
+ 1. Execution queue: The queue of hardware execution instructions,
+ function reset and local invalidate are queued for execution in this
+ queue.
+
+ 2.Local queue: A queue that stores local operation instructions. The
+ instructions in the local queue will be sent to the execution queue
+ for execution. The instructions in the local queue will not be removed
+ until the execution is completed.
+
+The reason for the problem is as follows:
+
+ 1. There is a function reset instruction in the execution queue, which
+ is currently being executed. A necessary condition for the successful
+ execution of function reset is: the hardware pipeline needs to empty
+ the instructions that were not completed before;
+
+ 2. A local invalidate instruction at the head of the local queue is
+ sent to the execution queue. Now there are two instructions in the
+ execution queue, the first is the function reset instruction, and the
+ second is the local invalidate instruction, which will be executed in
+ se quence;
+
+ 3. The user has issued many local invalidate operations, causing the
+ local queue to be filled up.
+
+ 4. The user still has a new local operation command and is queuing to
+ enter the local queue. But the local queue is full and cannot receive
+ new instructions, this instruction is temporarily stored at the
+ hardware pipeline.
+
+ 5. The function reset has been waiting for the instruction before the
+ hardware pipeline stage is drained. The hardware pipeline stage also
+ caches a local invalidate instruction, so the function reset cannot be
+ completed, and the instructions after it cannot be executed.
+
+These factors together cause the execution logic deadlock of the hardware,
+and the consequence is that RoCEE will not have any response. Considering
+that the local operation command may potentially cause RoCEE to hang, this
+feature is no longer supported.
+
+Fixes: e93df0108579 ("RDMA/hns: Support local invalidate for hip08 in kernel space")
+Signed-off-by: Yangyang Li <liyangyang20@huawei.com>
+Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
+Signed-off-by: Haoyue Xu <xuhaoyue1@hisilicon.com>
+Link: https://lore.kernel.org/r/20221024083814.1089722-2-xuhaoyue1@hisilicon.com
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 11 -----------
+ drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 2 --
+ 2 files changed, 13 deletions(-)
+
+diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+index c780646bd60a..8507d788cc94 100644
+--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
++++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+@@ -118,7 +118,6 @@ static const u32 hns_roce_op_code[] = {
+ HR_OPC_MAP(ATOMIC_CMP_AND_SWP, ATOM_CMP_AND_SWAP),
+ HR_OPC_MAP(ATOMIC_FETCH_AND_ADD, ATOM_FETCH_AND_ADD),
+ HR_OPC_MAP(SEND_WITH_INV, SEND_WITH_INV),
+- HR_OPC_MAP(LOCAL_INV, LOCAL_INV),
+ HR_OPC_MAP(MASKED_ATOMIC_CMP_AND_SWP, ATOM_MSK_CMP_AND_SWAP),
+ HR_OPC_MAP(MASKED_ATOMIC_FETCH_AND_ADD, ATOM_MSK_FETCH_AND_ADD),
+ HR_OPC_MAP(REG_MR, FAST_REG_PMR),
+@@ -560,9 +559,6 @@ static int set_rc_opcode(struct hns_roce_dev *hr_dev,
+ else
+ ret = -EOPNOTSUPP;
+ break;
+- case IB_WR_LOCAL_INV:
+- hr_reg_enable(rc_sq_wqe, RC_SEND_WQE_SO);
+- fallthrough;
+ case IB_WR_SEND_WITH_INV:
+ rc_sq_wqe->inv_key = cpu_to_le32(wr->ex.invalidate_rkey);
+ break;
+@@ -3226,7 +3222,6 @@ static int hns_roce_v2_write_mtpt(struct hns_roce_dev *hr_dev,
+
+ hr_reg_write(mpt_entry, MPT_ST, V2_MPT_ST_VALID);
+ hr_reg_write(mpt_entry, MPT_PD, mr->pd);
+- hr_reg_enable(mpt_entry, MPT_L_INV_EN);
+
+ hr_reg_write_bool(mpt_entry, MPT_BIND_EN,
+ mr->access & IB_ACCESS_MW_BIND);
+@@ -3317,7 +3312,6 @@ static int hns_roce_v2_frmr_write_mtpt(struct hns_roce_dev *hr_dev,
+
+ hr_reg_enable(mpt_entry, MPT_RA_EN);
+ hr_reg_enable(mpt_entry, MPT_R_INV_EN);
+- hr_reg_enable(mpt_entry, MPT_L_INV_EN);
+
+ hr_reg_enable(mpt_entry, MPT_FRE);
+ hr_reg_clear(mpt_entry, MPT_MR_MW);
+@@ -3349,7 +3343,6 @@ static int hns_roce_v2_mw_write_mtpt(void *mb_buf, struct hns_roce_mw *mw)
+ hr_reg_write(mpt_entry, MPT_PD, mw->pdn);
+
+ hr_reg_enable(mpt_entry, MPT_R_INV_EN);
+- hr_reg_enable(mpt_entry, MPT_L_INV_EN);
+ hr_reg_enable(mpt_entry, MPT_LW_EN);
+
+ hr_reg_enable(mpt_entry, MPT_MR_MW);
+@@ -3798,7 +3791,6 @@ static const u32 wc_send_op_map[] = {
+ HR_WC_OP_MAP(RDMA_READ, RDMA_READ),
+ HR_WC_OP_MAP(RDMA_WRITE, RDMA_WRITE),
+ HR_WC_OP_MAP(RDMA_WRITE_WITH_IMM, RDMA_WRITE),
+- HR_WC_OP_MAP(LOCAL_INV, LOCAL_INV),
+ HR_WC_OP_MAP(ATOM_CMP_AND_SWAP, COMP_SWAP),
+ HR_WC_OP_MAP(ATOM_FETCH_AND_ADD, FETCH_ADD),
+ HR_WC_OP_MAP(ATOM_MSK_CMP_AND_SWAP, MASKED_COMP_SWAP),
+@@ -3848,9 +3840,6 @@ static void fill_send_wc(struct ib_wc *wc, struct hns_roce_v2_cqe *cqe)
+ case HNS_ROCE_V2_WQE_OP_RDMA_WRITE_WITH_IMM:
+ wc->wc_flags |= IB_WC_WITH_IMM;
+ break;
+- case HNS_ROCE_V2_WQE_OP_LOCAL_INV:
+- wc->wc_flags |= IB_WC_WITH_INVALIDATE;
+- break;
+ case HNS_ROCE_V2_WQE_OP_ATOM_CMP_AND_SWAP:
+ case HNS_ROCE_V2_WQE_OP_ATOM_FETCH_AND_ADD:
+ case HNS_ROCE_V2_WQE_OP_ATOM_MSK_CMP_AND_SWAP:
+diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.h b/drivers/infiniband/hw/hns/hns_roce_hw_v2.h
+index 64797109bab6..4544a8775ce5 100644
+--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.h
++++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.h
+@@ -182,7 +182,6 @@ enum {
+ HNS_ROCE_V2_WQE_OP_ATOM_MSK_CMP_AND_SWAP = 0x8,
+ HNS_ROCE_V2_WQE_OP_ATOM_MSK_FETCH_AND_ADD = 0x9,
+ HNS_ROCE_V2_WQE_OP_FAST_REG_PMR = 0xa,
+- HNS_ROCE_V2_WQE_OP_LOCAL_INV = 0xb,
+ HNS_ROCE_V2_WQE_OP_BIND_MW = 0xc,
+ HNS_ROCE_V2_WQE_OP_MASK = 0x1f,
+ };
+@@ -916,7 +915,6 @@ struct hns_roce_v2_rc_send_wqe {
+ #define RC_SEND_WQE_OWNER RC_SEND_WQE_FIELD_LOC(7, 7)
+ #define RC_SEND_WQE_CQE RC_SEND_WQE_FIELD_LOC(8, 8)
+ #define RC_SEND_WQE_FENCE RC_SEND_WQE_FIELD_LOC(9, 9)
+-#define RC_SEND_WQE_SO RC_SEND_WQE_FIELD_LOC(10, 10)
+ #define RC_SEND_WQE_SE RC_SEND_WQE_FIELD_LOC(11, 11)
+ #define RC_SEND_WQE_INLINE RC_SEND_WQE_FIELD_LOC(12, 12)
+ #define RC_SEND_WQE_WQE_INDEX RC_SEND_WQE_FIELD_LOC(30, 15)
+--
+2.35.1
+
--- /dev/null
+From 6026022b596281db988ef794c308fc11721f0d0b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 24 Oct 2022 16:38:14 +0800
+Subject: RDMA/hns: Fix NULL pointer problem in free_mr_init()
+
+From: Yixing Liu <liuyixing1@huawei.com>
+
+[ Upstream commit 12bcaf87d8b66d8cd812479c8a6349dcb245375c ]
+
+Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL
+pointer. It should be init mutex_init() first before use the lock.
+
+ Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
+ Call trace:
+ __mutex_lock.constprop.0+0xd0/0x5c0
+ __mutex_lock_slowpath+0x1c/0x2c
+ mutex_lock+0x44/0x50
+ free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2]
+ hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2]
+ hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2]
+ ib_dereg_mr_user+0x54/0x124
+ uverbs_free_mr+0x24/0x30
+ destroy_hw_idr_uobject+0x38/0x74
+ uverbs_destroy_uobject+0x48/0x1c4
+ uobj_destroy+0x74/0xcc
+ ib_uverbs_cmd_verbs+0x368/0xbb0
+ ib_uverbs_ioctl+0xec/0x1a4
+ __arm64_sys_ioctl+0xb4/0x100
+ invoke_syscall+0x50/0x120
+ el0_svc_common.constprop.0+0x58/0x190
+ do_el0_svc+0x30/0x90
+ el0_svc+0x2c/0xb4
+ el0t_64_sync_handler+0x1a4/0x1b0
+ el0t_64_sync+0x19c/0x1a0
+
+Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT")
+Signed-off-by: Yixing Liu <liuyixing1@huawei.com>
+Signed-off-by: Haoyue Xu <xuhaoyue1@hisilicon.com>
+Link: https://lore.kernel.org/r/20221024083814.1089722-3-xuhaoyue1@hisilicon.com
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+index 8507d788cc94..105888c6ccb7 100644
+--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
++++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+@@ -2805,8 +2805,12 @@ static int free_mr_modify_qp(struct hns_roce_dev *hr_dev)
+
+ static int free_mr_init(struct hns_roce_dev *hr_dev)
+ {
++ struct hns_roce_v2_priv *priv = hr_dev->priv;
++ struct hns_roce_v2_free_mr *free_mr = &priv->free_mr;
+ int ret;
+
++ mutex_init(&free_mr->mutex);
++
+ ret = free_mr_alloc_res(hr_dev);
+ if (ret)
+ return ret;
+--
+2.35.1
+
--- /dev/null
+From 01700e1a2ab96f05d95ee2022b8186f6e1315cab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 Oct 2022 18:32:32 +0300
+Subject: RDMA/qedr: clean up work queue on failure in qedr_alloc_resources()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+[ Upstream commit 7a47e077e503feb73d56e491ce89aa73b67a3972 ]
+
+Add a check for if create_singlethread_workqueue() fails and also destroy
+the work queue on failure paths.
+
+Fixes: e411e0587e0d ("RDMA/qedr: Add iWARP connection management functions")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Link: https://lore.kernel.org/r/Y1gBkDucQhhWj5YM@kili
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/hw/qedr/main.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/infiniband/hw/qedr/main.c b/drivers/infiniband/hw/qedr/main.c
+index 5152f10d2e6d..ba0c3e4c07d8 100644
+--- a/drivers/infiniband/hw/qedr/main.c
++++ b/drivers/infiniband/hw/qedr/main.c
+@@ -344,6 +344,10 @@ static int qedr_alloc_resources(struct qedr_dev *dev)
+ if (IS_IWARP(dev)) {
+ xa_init(&dev->qps);
+ dev->iwarp_wq = create_singlethread_workqueue("qedr_iwarpq");
++ if (!dev->iwarp_wq) {
++ rc = -ENOMEM;
++ goto err1;
++ }
+ }
+
+ /* Allocate Status blocks for CNQ */
+@@ -351,7 +355,7 @@ static int qedr_alloc_resources(struct qedr_dev *dev)
+ GFP_KERNEL);
+ if (!dev->sb_array) {
+ rc = -ENOMEM;
+- goto err1;
++ goto err_destroy_wq;
+ }
+
+ dev->cnq_array = kcalloc(dev->num_cnq,
+@@ -402,6 +406,9 @@ static int qedr_alloc_resources(struct qedr_dev *dev)
+ kfree(dev->cnq_array);
+ err2:
+ kfree(dev->sb_array);
++err_destroy_wq:
++ if (IS_IWARP(dev))
++ destroy_workqueue(dev->iwarp_wq);
+ err1:
+ kfree(dev->sgid_tbl);
+ return rc;
+--
+2.35.1
+
--- /dev/null
+From 5ffe1b9c58e2771dbf630743fc77d9bba830efb6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 13 Oct 2022 12:03:33 +0800
+Subject: RDMA/rxe: Fix mr leak in RESPST_ERR_RNR
+
+From: Li Zhijian <lizhijian@fujitsu.com>
+
+[ Upstream commit b5f9a01fae42684648c2ee3cd9985f80c67ab9f7 ]
+
+rxe_recheck_mr() will increase mr's ref_cnt, so we should call rxe_put(mr)
+to drop mr's ref_cnt in RESPST_ERR_RNR to avoid below warning:
+
+ WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe]
+...
+ Call Trace:
+ rxe_dereg_mr+0x4c/0x60 [rdma_rxe]
+ ib_dereg_mr_user+0xa8/0x200 [ib_core]
+ ib_mr_pool_destroy+0x77/0xb0 [ib_core]
+ nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma]
+ nvme_rdma_free_queue+0x40/0x50 [nvme_rdma]
+ nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma]
+ nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma]
+ process_one_work+0x582/0xa40
+ ? pwq_dec_nr_in_flight+0x100/0x100
+ ? rwlock_bug.part.0+0x60/0x60
+ worker_thread+0x2a9/0x700
+ ? process_one_work+0xa40/0xa40
+ kthread+0x168/0x1a0
+ ? kthread_complete_and_exit+0x20/0x20
+ ret_from_fork+0x22/0x30
+
+Link: https://lore.kernel.org/r/20221024052049.20577-1-lizhijian@fujitsu.com
+Fixes: 8a1a0be894da ("RDMA/rxe: Replace mr by rkey in responder resources")
+Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/sw/rxe/rxe_resp.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
+index 7c336db5cb54..f8b1d9fa0494 100644
+--- a/drivers/infiniband/sw/rxe/rxe_resp.c
++++ b/drivers/infiniband/sw/rxe/rxe_resp.c
+@@ -806,8 +806,10 @@ static enum resp_states read_reply(struct rxe_qp *qp,
+
+ skb = prepare_ack_packet(qp, &ack_pkt, opcode, payload,
+ res->cur_psn, AETH_ACK_UNLIMITED);
+- if (!skb)
++ if (!skb) {
++ rxe_put(mr);
+ return RESPST_ERR_RNR;
++ }
+
+ rxe_mr_copy(mr, res->read.va, payload_addr(&ack_pkt),
+ payload, RXE_FROM_MR_OBJ);
+--
+2.35.1
+
--- /dev/null
+From a8f2f1d3c748fb20a2529e5a48a1d035403297c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 29 Oct 2022 00:10:49 +0800
+Subject: rose: Fix NULL pointer dereference in rose_send_frame()
+
+From: Zhang Qilong <zhangqilong3@huawei.com>
+
+[ Upstream commit e97c089d7a49f67027395ddf70bf327eeac2611e ]
+
+The syzkaller reported an issue:
+
+KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387]
+CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
+Workqueue: rcu_gp srcu_invoke_callbacks
+RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101
+Call Trace:
+ <IRQ>
+ rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255
+ rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009
+ rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111
+ call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474
+ expire_timers kernel/time/timer.c:1519 [inline]
+ __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790
+ __run_timers kernel/time/timer.c:1768 [inline]
+ run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803
+ __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571
+ [...]
+ </IRQ>
+
+It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is
+called in the rose_send_frame(). It's the first occurrence of the
+`neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and
+the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr.
+
+It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf
+("rose: Fix Null pointer dereference in rose_send_frame()") ever.
+But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8
+("rose: check NULL rose_loopback_neigh->loopback") again.
+
+We fix it by add NULL check in rose_transmit_clear_request(). When
+the 'dev' in 'neigh' is NULL, we don't reply the request and just
+clear it.
+
+syzkaller don't provide repro, and I provide a syz repro like:
+r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2)
+ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201})
+r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0)
+bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40)
+connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)
+
+Fixes: 3c53cd65dece ("rose: check NULL rose_loopback_neigh->loopback")
+Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/rose/rose_link.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
+index 8b96a56d3a49..0f77ae8ef944 100644
+--- a/net/rose/rose_link.c
++++ b/net/rose/rose_link.c
+@@ -236,6 +236,9 @@ void rose_transmit_clear_request(struct rose_neigh *neigh, unsigned int lci, uns
+ unsigned char *dptr;
+ int len;
+
++ if (!neigh->dev)
++ return;
++
+ len = AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + ROSE_MIN_LEN + 3;
+
+ if ((skb = alloc_skb(len, GFP_ATOMIC)) == NULL)
+--
+2.35.1
+
scsi-qla2xxx-enhance-driver-tracing-with-separate-tu.patch
scsi-qla2xxx-define-static-symbols.patch
drm-i915-gvt-add-missing-vfio_unregister_group_dev-c.patch
+rdma-cma-use-output-interface-for-net_dev-check.patch
+ib-hfi1-correctly-move-list-in-sc_disable.patch
+rdma-hns-disable-local-invalidate-operation.patch
+rdma-hns-fix-null-pointer-problem-in-free_mr_init.patch
+docs-process-howto-replace-c89-with-c11.patch
+rdma-rxe-fix-mr-leak-in-respst_err_rnr.patch
+nfsv4-fix-a-potential-state-reclaim-deadlock.patch
+nfsv4.1-handle-reclaim_complete-trunking-errors.patch
+nfsv4.1-we-must-always-send-reclaim_complete-after-a.patch
+sunrpc-fix-null-ptr-deref-when-xps-sysfs-alloc-faile.patch
+nfsv4.2-fixup-clone-dest-file-size-for-zero-length-c.patch
+nfs4-fix-kmemleak-when-allocate-slot-failed.patch
+net-dsa-fix-possible-memory-leaks-in-dsa_loop_init.patch
+rdma-core-fix-null-ptr-deref-in-ib_core_cleanup.patch
+rdma-qedr-clean-up-work-queue-on-failure-in-qedr_all.patch
+tools-nolibc-fix-missing-strlen-definition-and-infin.patch
+net-dsa-fall-back-to-default-tagger-if-we-can-t-load.patch
+nfc-fdp-fix-potential-memory-leak-in-fdp_nci_send.patch
+nfc-nxp-nci-fix-potential-memory-leak-in-nxp_nci_sen.patch
+nfc-s3fwrn5-fix-potential-memory-leak-in-s3fwrn5_nci.patch
+nfc-nfcmrvl-fix-potential-memory-leak-in-nfcmrvl_i2c.patch
+net-fec-fix-improper-use-of-netdev_tx_busy.patch
+ata-pata_legacy-fix-pdc20230_set_piomode.patch
+ata-palmld-fix-return-value-check-in-palmld_pata_pro.patch
+net-sched-fix-use-after-free-in-red_enqueue.patch
+net-tun-fix-bugs-for-oversize-packet-when-napi-frags.patch
+netfilter-nf_tables-netlink-notifier-might-race-to-r.patch
+netfilter-nf_tables-release-flow-rule-object-from-co.patch
+sfc-fix-an-error-handling-path-in-efx_pci_probe.patch
+nfsd-fix-nfsd_file_unhash_and_dispose.patch
+nfsd-fix-net-namespace-logic-in-__nfsd_file_cache_pu.patch
+net-lan966x-fix-the-mtu-calculation.patch
+net-lan966x-adjust-maximum-frame-size-when-vlan-is-e.patch
+net-lan966x-fix-fdma-when-mtu-is-changed.patch
+net-lan966x-fix-unmapping-of-received-frames-using-f.patch
+ipvs-use-explicitly-signed-chars.patch
+ipvs-fix-warning-in-__ip_vs_cleanup_batch.patch
+ipvs-fix-warning-in-ip_vs_app_net_cleanup.patch
+rose-fix-null-pointer-dereference-in-rose_send_frame.patch
+misdn-fix-possible-memory-leak-in-misdn_register_dev.patch
+isdn-misdn-netjet-fix-wrong-check-of-device-registra.patch
+btrfs-fix-inode-list-leak-during-backref-walking-at-.patch
+btrfs-fix-inode-list-leak-during-backref-walking-at-.patch-31031
+btrfs-fix-ulist-leaks-in-error-paths-of-qgroup-self-.patch
+netfilter-ipset-enforce-documented-limit-to-prevent-.patch
+bluetooth-l2cap-fix-use-after-free-caused-by-l2cap_r.patch
+bluetooth-hci_conn-fix-cis-connection-dst_type-handl.patch
+bluetooth-virtio_bt-use-skb_put-to-set-length.patch
+bluetooth-l2cap-fix-use-after-free-in-l2cap_conn_del.patch
+bluetooth-l2cap-fix-memory-leak-in-vhci_write.patch
+bluetooth-hci_conn-fix-not-restoring-iso-buffer-coun.patch
+net-mdio-fix-undefined-behavior-in-bit-shift-for-__m.patch
+ibmvnic-free-rwi-on-reset-success.patch
+stmmac-dwmac-loongson-fix-invalid-mdio_node.patch
+net-smc-fix-possible-leaked-pernet-namespace-in-smc_.patch
+net-neigh-fix-null-ptr-deref-in-neigh_table_clear.patch
+bridge-fix-flushing-of-dynamic-fdb-entries.patch
+ipv6-fix-warning-in-ip6_route_net_exit_late.patch
+vsock-fix-possible-infinite-sleep-in-vsock_connectib.patch
--- /dev/null
+From 7e9c2230280b6d1c3d0fd51a0f3d756465b24f0f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 29 Oct 2022 22:57:11 +0200
+Subject: sfc: Fix an error handling path in efx_pci_probe()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+[ Upstream commit 6c412da54c80a54b1a8b7f89677f6e82f0fabec4 ]
+
+If an error occurs after the first kzalloc() the corresponding memory
+allocation is never freed.
+
+Add the missing kfree() in the error handling path, as already done in the
+remove() function.
+
+Fixes: 7e773594dada ("sfc: Separate efx_nic memory from net_device memory")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Acked-by: Martin Habets <habetsm.xilinx@gmail.com>
+Link: https://lore.kernel.org/r/dc114193121c52c8fa3779e49bdd99d4b41344a9.1667077009.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/sfc/efx.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
+index 153d68e29b8b..68a68477ab7b 100644
+--- a/drivers/net/ethernet/sfc/efx.c
++++ b/drivers/net/ethernet/sfc/efx.c
+@@ -1059,8 +1059,10 @@ static int efx_pci_probe(struct pci_dev *pci_dev,
+
+ /* Allocate and initialise a struct net_device */
+ net_dev = alloc_etherdev_mq(sizeof(probe_data), EFX_MAX_CORE_TX_QUEUES);
+- if (!net_dev)
+- return -ENOMEM;
++ if (!net_dev) {
++ rc = -ENOMEM;
++ goto fail0;
++ }
+ probe_ptr = netdev_priv(net_dev);
+ *probe_ptr = probe_data;
+ efx->net_dev = net_dev;
+@@ -1132,6 +1134,8 @@ static int efx_pci_probe(struct pci_dev *pci_dev,
+ WARN_ON(rc > 0);
+ netif_dbg(efx, drv, efx->net_dev, "initialisation failed. rc=%d\n", rc);
+ free_netdev(net_dev);
++ fail0:
++ kfree(probe_data);
+ return rc;
+ }
+
+--
+2.35.1
+
--- /dev/null
+From 96ea345412f60141aa82b03f76a8ad80ded709c1 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 1 Nov 2022 14:02:18 +0800
+Subject: stmmac: dwmac-loongson: fix invalid mdio_node
+
+From: Liu Peibao <liupeibao@loongson.cn>
+
+[ Upstream commit 2ae34111fe4eebb69986f6490015b57c88804373 ]
+
+In current code "plat->mdio_node" is always NULL, the mdio
+support is lost as there is no "mdio_bus_data". The original
+driver could work as the "mdio" variable is never set to
+false, which is described in commit <b0e03950dd71> ("stmmac:
+dwmac-loongson: fix uninitialized variable ......"). And
+after this commit merged, the "mdio" variable is always
+false, causing the mdio supoort logic lost.
+
+Fixes: 30bba69d7db4 ("stmmac: pci: Add dwmac support for Loongson")
+Signed-off-by: Liu Peibao <liupeibao@loongson.cn>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Link: https://lore.kernel.org/r/20221101060218.16453-1-liupeibao@loongson.cn
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 7 ++-----
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+index 017dbbda0c1c..79fa7870563b 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
+@@ -51,7 +51,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
+ struct stmmac_resources res;
+ struct device_node *np;
+ int ret, i, phy_mode;
+- bool mdio = false;
+
+ np = dev_of_node(&pdev->dev);
+
+@@ -69,12 +68,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id
+ if (!plat)
+ return -ENOMEM;
+
++ plat->mdio_node = of_get_child_by_name(np, "mdio");
+ if (plat->mdio_node) {
+- dev_err(&pdev->dev, "Found MDIO subnode\n");
+- mdio = true;
+- }
++ dev_info(&pdev->dev, "Found MDIO subnode\n");
+
+- if (mdio) {
+ plat->mdio_bus_data = devm_kzalloc(&pdev->dev,
+ sizeof(*plat->mdio_bus_data),
+ GFP_KERNEL);
+--
+2.35.1
+
--- /dev/null
+From 80439069cf75d6b69abbc23924b8689e4c96496d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Oct 2022 11:42:17 +0800
+Subject: SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed
+
+From: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+
+[ Upstream commit cbdeaee94a415800c65a8c3fa04d9664a8b8fb3a ]
+
+There is a null-ptr-deref when xps sysfs alloc failed:
+ BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0
+ Read of size 8 at addr 0000000000000030 by task gssproxy/457
+
+ CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x34/0x44
+ kasan_report+0xa3/0x120
+ sysfs_do_create_link_sd+0x40/0xd0
+ rpc_sysfs_client_setup+0x161/0x1b0
+ rpc_new_client+0x3fc/0x6e0
+ rpc_create_xprt+0x71/0x220
+ rpc_create+0x1d4/0x350
+ gssp_rpc_create+0xc3/0x160
+ set_gssp_clnt+0xbc/0x140
+ write_gssp+0x116/0x1a0
+ proc_reg_write+0xd6/0x130
+ vfs_write+0x177/0x690
+ ksys_write+0xb9/0x150
+ do_syscall_64+0x35/0x80
+ entry_SYSCALL_64_after_hwframe+0x46/0xb0
+
+When the xprt_switch sysfs alloc failed, should not add xprt and
+switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize
+the 'xps_sysfs' to NULL to avoid oops when destroy it.
+
+Fixes: 2a338a543163 ("sunrpc: add a symlink from rpc-client directory to the xprt_switch")
+Fixes: d408ebe04ac5 ("sunrpc: add add sysfs directory per xprt under each xprt_switch")
+Fixes: baea99445dd4 ("sunrpc: add xprt_switch direcotry to sunrpc's sysfs")
+Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sunrpc/sysfs.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/net/sunrpc/sysfs.c b/net/sunrpc/sysfs.c
+index c65c90ad626a..c1f559892ae8 100644
+--- a/net/sunrpc/sysfs.c
++++ b/net/sunrpc/sysfs.c
+@@ -518,13 +518,16 @@ void rpc_sysfs_client_setup(struct rpc_clnt *clnt,
+ struct net *net)
+ {
+ struct rpc_sysfs_client *rpc_client;
++ struct rpc_sysfs_xprt_switch *xswitch =
++ (struct rpc_sysfs_xprt_switch *)xprt_switch->xps_sysfs;
++
++ if (!xswitch)
++ return;
+
+ rpc_client = rpc_sysfs_client_alloc(rpc_sunrpc_client_kobj,
+ net, clnt->cl_clid);
+ if (rpc_client) {
+ char name[] = "switch";
+- struct rpc_sysfs_xprt_switch *xswitch =
+- (struct rpc_sysfs_xprt_switch *)xprt_switch->xps_sysfs;
+ int ret;
+
+ clnt->cl_sysfs = rpc_client;
+@@ -558,6 +561,8 @@ void rpc_sysfs_xprt_switch_setup(struct rpc_xprt_switch *xprt_switch,
+ rpc_xprt_switch->xprt_switch = xprt_switch;
+ rpc_xprt_switch->xprt = xprt;
+ kobject_uevent(&rpc_xprt_switch->kobject, KOBJ_ADD);
++ } else {
++ xprt_switch->xps_sysfs = NULL;
+ }
+ }
+
+@@ -569,6 +574,9 @@ void rpc_sysfs_xprt_setup(struct rpc_xprt_switch *xprt_switch,
+ struct rpc_sysfs_xprt_switch *switch_obj =
+ (struct rpc_sysfs_xprt_switch *)xprt_switch->xps_sysfs;
+
++ if (!switch_obj)
++ return;
++
+ rpc_xprt = rpc_sysfs_xprt_alloc(&switch_obj->kobject, xprt, gfp_flags);
+ if (rpc_xprt) {
+ xprt->xprt_sysfs = rpc_xprt;
+--
+2.35.1
+
--- /dev/null
+From 75deb3bd05620447f0faa5307478821fa918f907 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 9 Oct 2022 20:29:36 +0200
+Subject: tools/nolibc: Fix missing strlen() definition and infinite loop with
+ gcc-12
+
+From: Willy Tarreau <w@1wt.eu>
+
+[ Upstream commit bfc3b0f05653a28c8d41067a2aa3875d1f982e3e ]
+
+When built at -Os, gcc-12 recognizes an strlen() pattern in nolibc_strlen()
+and replaces it with a jump to strlen(), which is not defined as a symbol
+and breaks compilation. Worse, when the function is called strlen(), the
+function is simply replaced with a jump to itself, hence becomes an
+infinite loop.
+
+One way to avoid this is to always set -ffreestanding, but the calling
+code doesn't know this and there's no way (either via attributes or
+pragmas) to globally enable it from include files, effectively leaving
+a painful situation for the caller.
+
+Alexey suggested to place an empty asm() statement inside the loop to
+stop gcc from recognizing a well-known pattern, which happens to work
+pretty fine. At least it allows us to make sure our local definition
+is not replaced with a self jump.
+
+The function only needs to be renamed back to strlen() so that the symbol
+exists, which implies that nolibc_strlen() which is used on variable
+strings has to be declared as a macro that points back to it before the
+strlen() macro is redifined.
+
+It was verified to produce valid code with gcc 3.4 to 12.1 at different
+optimization levels, and both with constant and variable strings.
+
+In case this problem surfaces again in the future, an alternate approach
+consisting in adding an optimize("no-tree-loop-distribute-patterns")
+function attribute for gcc>=12 worked as well but is less pretty.
+
+Reported-by: kernel test robot <yujie.liu@intel.com>
+Link: https://lore.kernel.org/r/202210081618.754a77db-yujie.liu@intel.com
+Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc")
+Fixes: 96980b833a21 ("tools/nolibc/string: do not use __builtin_strlen() at -O0")
+Cc: "Paul E. McKenney" <paulmck@kernel.org>
+Cc: Alexey Dobriyan <adobriyan@gmail.com>
+Signed-off-by: Willy Tarreau <w@1wt.eu>
+Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/include/nolibc/string.h | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/tools/include/nolibc/string.h b/tools/include/nolibc/string.h
+index bef35bee9c44..718a405ffbc3 100644
+--- a/tools/include/nolibc/string.h
++++ b/tools/include/nolibc/string.h
+@@ -125,14 +125,18 @@ char *strcpy(char *dst, const char *src)
+ }
+
+ /* this function is only used with arguments that are not constants or when
+- * it's not known because optimizations are disabled.
++ * it's not known because optimizations are disabled. Note that gcc 12
++ * recognizes an strlen() pattern and replaces it with a jump to strlen(),
++ * thus itself, hence the asm() statement below that's meant to disable this
++ * confusing practice.
+ */
+ static __attribute__((unused))
+-size_t nolibc_strlen(const char *str)
++size_t strlen(const char *str)
+ {
+ size_t len;
+
+- for (len = 0; str[len]; len++);
++ for (len = 0; str[len]; len++)
++ asm("");
+ return len;
+ }
+
+@@ -140,13 +144,12 @@ size_t nolibc_strlen(const char *str)
+ * the two branches, then will rely on an external definition of strlen().
+ */
+ #if defined(__OPTIMIZE__)
++#define nolibc_strlen(x) strlen(x)
+ #define strlen(str) ({ \
+ __builtin_constant_p((str)) ? \
+ __builtin_strlen((str)) : \
+ nolibc_strlen((str)); \
+ })
+-#else
+-#define strlen(str) nolibc_strlen((str))
+ #endif
+
+ static __attribute__((unused))
+--
+2.35.1
+
--- /dev/null
+From d283c5305bd9334fa135c5761a03b83731429760 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 31 Oct 2022 19:17:06 -0700
+Subject: vsock: fix possible infinite sleep in vsock_connectible_wait_data()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dexuan Cui <decui@microsoft.com>
+
+[ Upstream commit 466a85336fee6e3b35eb97b8405a28302fd25809 ]
+
+Currently vsock_connectible_has_data() may miss a wakeup operation
+between vsock_connectible_has_data() == 0 and the prepare_to_wait().
+
+Fix the race by adding the process to the wait queue before checking
+vsock_connectible_has_data().
+
+Fixes: b3f7fd54881b ("af_vsock: separate wait data loop")
+Signed-off-by: Dexuan Cui <decui@microsoft.com>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Reported-by: Frédéric Dalleau <frederic.dalleau@docker.com>
+Tested-by: Frédéric Dalleau <frederic.dalleau@docker.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/vmw_vsock/af_vsock.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
+index b4ee163154a6..e5ab2418f9d6 100644
+--- a/net/vmw_vsock/af_vsock.c
++++ b/net/vmw_vsock/af_vsock.c
+@@ -1894,8 +1894,11 @@ static int vsock_connectible_wait_data(struct sock *sk,
+ err = 0;
+ transport = vsk->transport;
+
+- while ((data = vsock_connectible_has_data(vsk)) == 0) {
++ while (1) {
+ prepare_to_wait(sk_sleep(sk), wait, TASK_INTERRUPTIBLE);
++ data = vsock_connectible_has_data(vsk);
++ if (data != 0)
++ break;
+
+ if (sk->sk_err != 0 ||
+ (sk->sk_shutdown & RCV_SHUTDOWN) ||
+--
+2.35.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
