x86-amd_nb-use-family-19h-models-60h-7fh-function-4-ids.patch
revert-mmc-core-capture-correct-oemid-bits-for-emmc-cards.patch
btrfs-use-u64-for-buffer-sizes-in-the-tree-search-io.patch
+wifi-cfg80211-fix-kernel-doc-for-wiphy_delayed_work_flush.patch
+virtio-vsock-don-t-use-skbuff-state-to-account-credit.patch
+virtio-vsock-remove-redundant-skb_pull-call.patch
+virtio-vsock-don-t-drop-skbuff-on-copy-failure.patch
+vsock-loopback-use-only-sk_buff_head.lock-to-protect-the-packet-queue.patch
+virtio-vsock-fix-leaks-due-to-missing-skb-owner.patch
+virtio-vsock-fix-uninit-value-in-virtio_transport_recv_pkt.patch
+virtio-vsock-fix-header-length-on-skb-merging.patch
--- /dev/null
+From 8daaf39f7f6ef53a11817f6a11ec104016c3545f Mon Sep 17 00:00:00 2001
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+Date: Tue, 14 Mar 2023 14:08:20 +0300
+Subject: virtio/vsock: don't drop skbuff on copy failure
+
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+
+commit 8daaf39f7f6ef53a11817f6a11ec104016c3545f upstream.
+
+This returns behaviour of SOCK_STREAM read as before skbuff usage. When
+copying to user fails current skbuff won't be dropped, but returned to
+sockets's queue. Technically instead of 'skb_dequeue()', 'skb_peek()' is
+called and when skbuff becomes empty, it is removed from queue by
+'__skb_unlink()'.
+
+Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
+Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Acked-by: Bobby Eshleman <bobby.eshleman@bytedance.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -364,7 +364,7 @@ virtio_transport_stream_do_dequeue(struc
+
+ spin_lock_bh(&vvs->rx_lock);
+ while (total < len && !skb_queue_empty(&vvs->rx_queue)) {
+- skb = __skb_dequeue(&vvs->rx_queue);
++ skb = skb_peek(&vvs->rx_queue);
+
+ bytes = len - total;
+ if (bytes > skb->len)
+@@ -388,9 +388,8 @@ virtio_transport_stream_do_dequeue(struc
+ u32 pkt_len = le32_to_cpu(virtio_vsock_hdr(skb)->len);
+
+ virtio_transport_dec_rx_pkt(vvs, pkt_len);
++ __skb_unlink(skb, &vvs->rx_queue);
+ consume_skb(skb);
+- } else {
+- __skb_queue_head(&vvs->rx_queue, skb);
+ }
+ }
+
--- /dev/null
+From 077706165717686a2a6a71405fef036cd5b37ae0 Mon Sep 17 00:00:00 2001
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+Date: Tue, 14 Mar 2023 14:05:48 +0300
+Subject: virtio/vsock: don't use skbuff state to account credit
+
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+
+commit 077706165717686a2a6a71405fef036cd5b37ae0 upstream.
+
+'skb->len' can vary when we partially read the data, this complicates the
+calculation of credit to be updated in 'virtio_transport_inc_rx_pkt()/
+virtio_transport_dec_rx_pkt()'.
+
+Also in 'virtio_transport_dec_rx_pkt()' we were miscalculating the
+credit since 'skb->len' was redundant.
+
+For these reasons, let's replace the use of skbuff state to calculate new
+'rx_bytes'/'fwd_cnt' values with explicit value as input argument. This
+makes code more simple, because it is not needed to change skbuff state
+before each call to update 'rx_bytes'/'fwd_cnt'.
+
+Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
+Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Acked-by: Bobby Eshleman <bobby.eshleman@bytedance.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 23 +++++++++++------------
+ 1 file changed, 11 insertions(+), 12 deletions(-)
+
+diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
+index a1581c77cf84..618680fd9906 100644
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -241,21 +241,18 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
+ }
+
+ static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
+- struct sk_buff *skb)
++ u32 len)
+ {
+- if (vvs->rx_bytes + skb->len > vvs->buf_alloc)
++ if (vvs->rx_bytes + len > vvs->buf_alloc)
+ return false;
+
+- vvs->rx_bytes += skb->len;
++ vvs->rx_bytes += len;
+ return true;
+ }
+
+ static void virtio_transport_dec_rx_pkt(struct virtio_vsock_sock *vvs,
+- struct sk_buff *skb)
++ u32 len)
+ {
+- int len;
+-
+- len = skb_headroom(skb) - sizeof(struct virtio_vsock_hdr) - skb->len;
+ vvs->rx_bytes -= len;
+ vvs->fwd_cnt += len;
+ }
+@@ -388,7 +385,9 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
+ skb_pull(skb, bytes);
+
+ if (skb->len == 0) {
+- virtio_transport_dec_rx_pkt(vvs, skb);
++ u32 pkt_len = le32_to_cpu(virtio_vsock_hdr(skb)->len);
++
++ virtio_transport_dec_rx_pkt(vvs, pkt_len);
+ consume_skb(skb);
+ } else {
+ __skb_queue_head(&vvs->rx_queue, skb);
+@@ -437,17 +436,17 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
+
+ while (!msg_ready) {
+ struct virtio_vsock_hdr *hdr;
++ size_t pkt_len;
+
+ skb = __skb_dequeue(&vvs->rx_queue);
+ if (!skb)
+ break;
+ hdr = virtio_vsock_hdr(skb);
++ pkt_len = (size_t)le32_to_cpu(hdr->len);
+
+ if (dequeued_len >= 0) {
+- size_t pkt_len;
+ size_t bytes_to_copy;
+
+- pkt_len = (size_t)le32_to_cpu(hdr->len);
+ bytes_to_copy = min(user_buf_len, pkt_len);
+
+ if (bytes_to_copy) {
+@@ -484,7 +483,7 @@ static int virtio_transport_seqpacket_do_dequeue(struct vsock_sock *vsk,
+ msg->msg_flags |= MSG_EOR;
+ }
+
+- virtio_transport_dec_rx_pkt(vvs, skb);
++ virtio_transport_dec_rx_pkt(vvs, pkt_len);
+ kfree_skb(skb);
+ }
+
+@@ -1040,7 +1039,7 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
+
+ spin_lock_bh(&vvs->rx_lock);
+
+- can_enqueue = virtio_transport_inc_rx_pkt(vvs, skb);
++ can_enqueue = virtio_transport_inc_rx_pkt(vvs, len);
+ if (!can_enqueue) {
+ free_pkt = true;
+ goto out;
+--
+2.42.1
+
--- /dev/null
+From f7154d967bc4ee25ea1572937550e711b2525474 Mon Sep 17 00:00:00 2001
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+Date: Tue, 28 Mar 2023 14:31:28 +0300
+Subject: virtio/vsock: fix header length on skb merging
+
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+
+commit f7154d967bc4ee25ea1572937550e711b2525474 upstream.
+
+This fixes appending newly arrived skbuff to the last skbuff of the
+socket's queue. Problem fires when we are trying to append data to skbuff
+which was already processed in dequeue callback at least once. Dequeue
+callback calls function 'skb_pull()' which changes 'skb->len'. In current
+implementation 'skb->len' is used to update length in header of the last
+skbuff after new data was copied to it. This is bug, because value in
+header is used to calculate 'rx_bytes'/'fwd_cnt' and thus must be not
+be changed during skbuff's lifetime.
+
+Bug starts to fire since:
+
+commit 077706165717
+("virtio/vsock: don't use skbuff state to account credit")
+
+It presents before, but didn't triggered due to a little bit buggy
+implementation of credit calculation logic. So use Fixes tag for it.
+
+Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
+Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -1075,7 +1075,7 @@ virtio_transport_recv_enqueue(struct vso
+ memcpy(skb_put(last_skb, skb->len), skb->data, skb->len);
+ free_pkt = true;
+ last_hdr->flags |= hdr->flags;
+- last_hdr->len = cpu_to_le32(last_skb->len);
++ le32_add_cpu(&last_hdr->len, len);
+ goto out;
+ }
+ }
--- /dev/null
+From f9d2b1e146e0f82f3d04629afd92698522058361 Mon Sep 17 00:00:00 2001
+From: Bobby Eshleman <bobby.eshleman@bytedance.com>
+Date: Wed, 29 Mar 2023 16:51:58 +0000
+Subject: virtio/vsock: fix leaks due to missing skb owner
+
+From: Bobby Eshleman <bobby.eshleman@bytedance.com>
+
+commit f9d2b1e146e0f82f3d04629afd92698522058361 upstream.
+
+This patch sets the skb owner in the recv and send path for virtio.
+
+For the send path, this solves the leak caused when
+virtio_transport_purge_skbs() finds skb->sk is always NULL and therefore
+never matches it with the current socket. Setting the owner upon
+allocation fixes this.
+
+For the recv path, this ensures correctness of accounting and also
+correct transfer of ownership in vsock_loopback (when skbs are sent from
+one socket and received by another).
+
+Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
+Signed-off-by: Bobby Eshleman <bobby.eshleman@bytedance.com>
+Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
+Link: https://lore.kernel.org/all/ZCCbATwov4U+GBUv@pop-os.localdomain/
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -94,6 +94,11 @@ virtio_transport_alloc_skb(struct virtio
+ info->op,
+ info->flags);
+
++ if (info->vsk && !skb_set_owner_sk_safe(skb, sk_vsock(info->vsk))) {
++ WARN_ONCE(1, "failed to allocate skb on vsock socket with sk_refcnt == 0\n");
++ goto out;
++ }
++
+ return skb;
+
+ out:
+@@ -1302,6 +1307,11 @@ void virtio_transport_recv_pkt(struct vi
+ goto free_pkt;
+ }
+
++ if (!skb_set_owner_sk_safe(skb, sk)) {
++ WARN_ONCE(1, "receiving vsock socket has sk_refcnt == 0\n");
++ goto free_pkt;
++ }
++
+ vsk = vsock_sk(sk);
+
+ lock_sock(sk);
--- /dev/null
+From 34c4effacfc329aeca5635a69fd9e0f6c90b4101 Mon Sep 17 00:00:00 2001
+From: Shigeru Yoshida <syoshida@redhat.com>
+Date: Sun, 5 Nov 2023 00:05:31 +0900
+Subject: virtio/vsock: Fix uninit-value in virtio_transport_recv_pkt()
+
+From: Shigeru Yoshida <syoshida@redhat.com>
+
+commit 34c4effacfc329aeca5635a69fd9e0f6c90b4101 upstream.
+
+KMSAN reported the following uninit-value access issue:
+
+=====================================================
+BUG: KMSAN: uninit-value in virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421
+ virtio_transport_recv_pkt+0x1dfb/0x26a0 net/vmw_vsock/virtio_transport_common.c:1421
+ vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120
+ process_one_work kernel/workqueue.c:2630 [inline]
+ process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703
+ worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784
+ kthread+0x3cc/0x520 kernel/kthread.c:388
+ ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
+ ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
+
+Uninit was stored to memory at:
+ virtio_transport_space_update net/vmw_vsock/virtio_transport_common.c:1274 [inline]
+ virtio_transport_recv_pkt+0x1ee8/0x26a0 net/vmw_vsock/virtio_transport_common.c:1415
+ vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120
+ process_one_work kernel/workqueue.c:2630 [inline]
+ process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703
+ worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784
+ kthread+0x3cc/0x520 kernel/kthread.c:388
+ ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
+ ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
+
+Uninit was created at:
+ slab_post_alloc_hook+0x105/0xad0 mm/slab.h:767
+ slab_alloc_node mm/slub.c:3478 [inline]
+ kmem_cache_alloc_node+0x5a2/0xaf0 mm/slub.c:3523
+ kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:559
+ __alloc_skb+0x2fd/0x770 net/core/skbuff.c:650
+ alloc_skb include/linux/skbuff.h:1286 [inline]
+ virtio_vsock_alloc_skb include/linux/virtio_vsock.h:66 [inline]
+ virtio_transport_alloc_skb+0x90/0x11e0 net/vmw_vsock/virtio_transport_common.c:58
+ virtio_transport_reset_no_sock net/vmw_vsock/virtio_transport_common.c:957 [inline]
+ virtio_transport_recv_pkt+0x1279/0x26a0 net/vmw_vsock/virtio_transport_common.c:1387
+ vsock_loopback_work+0x3bb/0x5a0 net/vmw_vsock/vsock_loopback.c:120
+ process_one_work kernel/workqueue.c:2630 [inline]
+ process_scheduled_works+0xff6/0x1e60 kernel/workqueue.c:2703
+ worker_thread+0xeca/0x14d0 kernel/workqueue.c:2784
+ kthread+0x3cc/0x520 kernel/kthread.c:388
+ ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
+ ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
+
+CPU: 1 PID: 10664 Comm: kworker/1:5 Not tainted 6.6.0-rc3-00146-g9f3ebbef746f #3
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014
+Workqueue: vsock-loopback vsock_loopback_work
+=====================================================
+
+The following simple reproducer can cause the issue described above:
+
+int main(void)
+{
+ int sock;
+ struct sockaddr_vm addr = {
+ .svm_family = AF_VSOCK,
+ .svm_cid = VMADDR_CID_ANY,
+ .svm_port = 1234,
+ };
+
+ sock = socket(AF_VSOCK, SOCK_STREAM, 0);
+ connect(sock, (struct sockaddr *)&addr, sizeof(addr));
+ return 0;
+}
+
+This issue occurs because the `buf_alloc` and `fwd_cnt` fields of the
+`struct virtio_vsock_hdr` are not initialized when a new skb is allocated
+in `virtio_transport_init_hdr()`. This patch resolves the issue by
+initializing these fields during allocation.
+
+Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
+Reported-and-tested-by: syzbot+0c8ce1da0ac31abbadcd@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=0c8ce1da0ac31abbadcd
+Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Link: https://lore.kernel.org/r/20231104150531.257952-1-syoshida@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -68,6 +68,8 @@ virtio_transport_alloc_skb(struct virtio
+ hdr->dst_port = cpu_to_le32(dst_port);
+ hdr->flags = cpu_to_le32(info->flags);
+ hdr->len = cpu_to_le32(len);
++ hdr->buf_alloc = cpu_to_le32(0);
++ hdr->fwd_cnt = cpu_to_le32(0);
+
+ if (info->msg && len > 0) {
+ payload = skb_put(skb, len);
--- /dev/null
+From 6825e6b4f8e53799d83bc39ca6ec5baed4e2adde Mon Sep 17 00:00:00 2001
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+Date: Tue, 14 Mar 2023 14:06:53 +0300
+Subject: virtio/vsock: remove redundant 'skb_pull()' call
+
+From: Arseniy Krasnov <avkrasnov@sberdevices.ru>
+
+commit 6825e6b4f8e53799d83bc39ca6ec5baed4e2adde upstream.
+
+Since we now no longer use 'skb->len' to update credit, there is no sense
+to update skbuff state, because it is used only once after dequeue to
+copy data and then will be released.
+
+Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
+Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Acked-by: Bobby Eshleman <bobby.eshleman@bytedance.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -465,7 +465,6 @@ static int virtio_transport_seqpacket_do
+ dequeued_len = err;
+ } else {
+ user_buf_len -= bytes_to_copy;
+- skb_pull(skb, bytes_to_copy);
+ }
+
+ spin_lock_bh(&vvs->rx_lock);
--- /dev/null
+From b465518dc27da1ed74b8cbada4659708aac35adb Mon Sep 17 00:00:00 2001
+From: Stefano Garzarella <sgarzare@redhat.com>
+Date: Fri, 24 Mar 2023 12:54:50 +0100
+Subject: vsock/loopback: use only sk_buff_head.lock to protect the packet queue
+
+From: Stefano Garzarella <sgarzare@redhat.com>
+
+commit b465518dc27da1ed74b8cbada4659708aac35adb upstream.
+
+pkt_list_lock was used before commit 71dc9ec9ac7d ("virtio/vsock:
+replace virtio_vsock_pkt with sk_buff") to protect the packet queue.
+After that commit we switched to sk_buff and we are using
+sk_buff_head.lock in almost every place to protect the packet queue
+except in vsock_loopback_work() when we call skb_queue_splice_init().
+
+As reported by syzbot, this caused unlocked concurrent access to the
+packet queue between vsock_loopback_work() and
+vsock_loopback_cancel_pkt() since it is not holding pkt_list_lock.
+
+With the introduction of sk_buff_head, pkt_list_lock is redundant and
+can cause confusion, so let's remove it and use sk_buff_head.lock
+everywhere to protect the packet queue access.
+
+Fixes: 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")
+Cc: bobby.eshleman@bytedance.com
+Reported-and-tested-by: syzbot+befff0a9536049e7902e@syzkaller.appspotmail.com
+Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
+Reviewed-by: Bobby Eshleman <bobby.eshleman@bytedance.com>
+Reviewed-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/vsock_loopback.c | 10 ++--------
+ 1 file changed, 2 insertions(+), 8 deletions(-)
+
+--- a/net/vmw_vsock/vsock_loopback.c
++++ b/net/vmw_vsock/vsock_loopback.c
+@@ -15,7 +15,6 @@
+ struct vsock_loopback {
+ struct workqueue_struct *workqueue;
+
+- spinlock_t pkt_list_lock; /* protects pkt_list */
+ struct sk_buff_head pkt_queue;
+ struct work_struct pkt_work;
+ };
+@@ -32,9 +31,7 @@ static int vsock_loopback_send_pkt(struc
+ struct vsock_loopback *vsock = &the_vsock_loopback;
+ int len = skb->len;
+
+- spin_lock_bh(&vsock->pkt_list_lock);
+ skb_queue_tail(&vsock->pkt_queue, skb);
+- spin_unlock_bh(&vsock->pkt_list_lock);
+
+ queue_work(vsock->workqueue, &vsock->pkt_work);
+
+@@ -113,9 +110,9 @@ static void vsock_loopback_work(struct w
+
+ skb_queue_head_init(&pkts);
+
+- spin_lock_bh(&vsock->pkt_list_lock);
++ spin_lock_bh(&vsock->pkt_queue.lock);
+ skb_queue_splice_init(&vsock->pkt_queue, &pkts);
+- spin_unlock_bh(&vsock->pkt_list_lock);
++ spin_unlock_bh(&vsock->pkt_queue.lock);
+
+ while ((skb = __skb_dequeue(&pkts))) {
+ virtio_transport_deliver_tap_pkt(skb);
+@@ -132,7 +129,6 @@ static int __init vsock_loopback_init(vo
+ if (!vsock->workqueue)
+ return -ENOMEM;
+
+- spin_lock_init(&vsock->pkt_list_lock);
+ skb_queue_head_init(&vsock->pkt_queue);
+ INIT_WORK(&vsock->pkt_work, vsock_loopback_work);
+
+@@ -156,9 +152,7 @@ static void __exit vsock_loopback_exit(v
+
+ flush_work(&vsock->pkt_work);
+
+- spin_lock_bh(&vsock->pkt_list_lock);
+ virtio_vsock_skb_queue_purge(&vsock->pkt_queue);
+- spin_unlock_bh(&vsock->pkt_list_lock);
+
+ destroy_workqueue(vsock->workqueue);
+ }
--- /dev/null
+From 8c73d5248dcf112611654bcd32352dc330b02397 Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Wed, 13 Sep 2023 09:34:25 +0200
+Subject: wifi: cfg80211: fix kernel-doc for wiphy_delayed_work_flush()
+
+From: Johannes Berg <johannes.berg@intel.com>
+
+commit 8c73d5248dcf112611654bcd32352dc330b02397 upstream.
+
+Clearly, there's no space in the function name, not sure how
+that could've happened. Put the underscore that it should be.
+
+Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
+Fixes: 56cfb8ce1f7f ("wifi: cfg80211: add flush functions for wiphy work")
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/cfg80211.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/net/cfg80211.h
++++ b/include/net/cfg80211.h
+@@ -5744,7 +5744,7 @@ void wiphy_delayed_work_cancel(struct wi
+ struct wiphy_delayed_work *dwork);
+
+ /**
+- * wiphy_delayed work_flush - flush previously queued delayed work
++ * wiphy_delayed_work_flush - flush previously queued delayed work
+ * @wiphy: the wiphy, for debug purposes
+ * @work: the work to flush
+ *
projects / thirdparty / kernel / stable-queue.git / commitdiff
