--- /dev/null
+From 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Thu, 30 Mar 2023 14:15:50 -0700
+Subject: Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+commit 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 upstream.
+
+This attempts to fix the following trace:
+
+======================================================
+WARNING: possible circular locking dependency detected
+6.3.0-rc2-g0b93eeba4454 #4703 Not tainted
+------------------------------------------------------
+kworker/u3:0/46 is trying to acquire lock:
+ffff888001fd9130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at:
+sco_connect_cfm+0x118/0x4a0
+
+but task is already holding lock:
+ffffffff831e3340 (hci_cb_list_lock){+.+.}-{3:3}, at:
+hci_sync_conn_complete_evt+0x1ad/0x3d0
+
+which lock already depends on the new lock.
+
+the existing dependency chain (in reverse order) is:
+
+-> #2 (hci_cb_list_lock){+.+.}-{3:3}:
+ __mutex_lock+0x13b/0xcc0
+ hci_sync_conn_complete_evt+0x1ad/0x3d0
+ hci_event_packet+0x55c/0x7c0
+ hci_rx_work+0x34c/0xa00
+ process_one_work+0x575/0x910
+ worker_thread+0x89/0x6f0
+ kthread+0x14e/0x180
+ ret_from_fork+0x2b/0x50
+
+-> #1 (&hdev->lock){+.+.}-{3:3}:
+ __mutex_lock+0x13b/0xcc0
+ sco_sock_connect+0xfc/0x630
+ __sys_connect+0x197/0x1b0
+ __x64_sys_connect+0x37/0x50
+ do_syscall_64+0x42/0x90
+ entry_SYSCALL_64_after_hwframe+0x70/0xda
+
+-> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
+ __lock_acquire+0x18cc/0x3740
+ lock_acquire+0x151/0x3a0
+ lock_sock_nested+0x32/0x80
+ sco_connect_cfm+0x118/0x4a0
+ hci_sync_conn_complete_evt+0x1e6/0x3d0
+ hci_event_packet+0x55c/0x7c0
+ hci_rx_work+0x34c/0xa00
+ process_one_work+0x575/0x910
+ worker_thread+0x89/0x6f0
+ kthread+0x14e/0x180
+ ret_from_fork+0x2b/0x50
+
+other info that might help us debug this:
+
+Chain exists of:
+ sk_lock-AF_BLUETOOTH-BTPROTO_SCO --> &hdev->lock --> hci_cb_list_lock
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(hci_cb_list_lock);
+ lock(&hdev->lock);
+ lock(hci_cb_list_lock);
+ lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO);
+
+ *** DEADLOCK ***
+
+4 locks held by kworker/u3:0/46:
+ #0: ffff8880028d1130 ((wq_completion)hci0#2){+.+.}-{0:0}, at:
+ process_one_work+0x4c0/0x910
+ #1: ffff8880013dfde0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0},
+ at: process_one_work+0x4c0/0x910
+ #2: ffff8880025d8070 (&hdev->lock){+.+.}-{3:3}, at:
+ hci_sync_conn_complete_evt+0xa6/0x3d0
+ #3: ffffffffb79e3340 (hci_cb_list_lock){+.+.}-{3:3}, at:
+ hci_sync_conn_complete_evt+0x1ad/0x3d0
+
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/sco.c | 69 ++++++++++++++++++++++++++++++----------------------
+ 1 file changed, 40 insertions(+), 29 deletions(-)
+
+--- a/net/bluetooth/sco.c
++++ b/net/bluetooth/sco.c
+@@ -239,27 +239,41 @@ static int sco_chan_add(struct sco_conn
+ return err;
+ }
+
+-static int sco_connect(struct hci_dev *hdev, struct sock *sk)
++static int sco_connect(struct sock *sk)
+ {
+ struct sco_conn *conn;
+ struct hci_conn *hcon;
++ struct hci_dev *hdev;
+ int err, type;
+
+ BT_DBG("%pMR -> %pMR", &sco_pi(sk)->src, &sco_pi(sk)->dst);
+
++ hdev = hci_get_route(&sco_pi(sk)->dst, &sco_pi(sk)->src, BDADDR_BREDR);
++ if (!hdev)
++ return -EHOSTUNREACH;
++
++ hci_dev_lock(hdev);
++
+ if (lmp_esco_capable(hdev) && !disable_esco)
+ type = ESCO_LINK;
+ else
+ type = SCO_LINK;
+
+ if (sco_pi(sk)->setting == BT_VOICE_TRANSPARENT &&
+- (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev)))
+- return -EOPNOTSUPP;
++ (!lmp_transp_capable(hdev) || !lmp_esco_capable(hdev))) {
++ err = -EOPNOTSUPP;
++ goto unlock;
++ }
+
+ hcon = hci_connect_sco(hdev, type, &sco_pi(sk)->dst,
+ sco_pi(sk)->setting, &sco_pi(sk)->codec);
+- if (IS_ERR(hcon))
+- return PTR_ERR(hcon);
++ if (IS_ERR(hcon)) {
++ err = PTR_ERR(hcon);
++ goto unlock;
++ }
++
++ hci_dev_unlock(hdev);
++ hci_dev_put(hdev);
+
+ conn = sco_conn_add(hcon);
+ if (!conn) {
+@@ -267,13 +281,15 @@ static int sco_connect(struct hci_dev *h
+ return -ENOMEM;
+ }
+
+- /* Update source addr of the socket */
+- bacpy(&sco_pi(sk)->src, &hcon->src);
+-
+ err = sco_chan_add(conn, sk, NULL);
+ if (err)
+ return err;
+
++ lock_sock(sk);
++
++ /* Update source addr of the socket */
++ bacpy(&sco_pi(sk)->src, &hcon->src);
++
+ if (hcon->state == BT_CONNECTED) {
+ sco_sock_clear_timer(sk);
+ sk->sk_state = BT_CONNECTED;
+@@ -282,6 +298,13 @@ static int sco_connect(struct hci_dev *h
+ sco_sock_set_timer(sk, sk->sk_sndtimeo);
+ }
+
++ release_sock(sk);
++
++ return err;
++
++unlock:
++ hci_dev_unlock(hdev);
++ hci_dev_put(hdev);
+ return err;
+ }
+
+@@ -561,7 +584,6 @@ static int sco_sock_connect(struct socke
+ {
+ struct sockaddr_sco *sa = (struct sockaddr_sco *) addr;
+ struct sock *sk = sock->sk;
+- struct hci_dev *hdev;
+ int err;
+
+ BT_DBG("sk %p", sk);
+@@ -570,37 +592,26 @@ static int sco_sock_connect(struct socke
+ addr->sa_family != AF_BLUETOOTH)
+ return -EINVAL;
+
+- lock_sock(sk);
+- if (sk->sk_state != BT_OPEN && sk->sk_state != BT_BOUND) {
+- err = -EBADFD;
+- goto done;
+- }
++ if (sk->sk_state != BT_OPEN && sk->sk_state != BT_BOUND)
++ return -EBADFD;
+
+- if (sk->sk_type != SOCK_SEQPACKET) {
++ if (sk->sk_type != SOCK_SEQPACKET)
+ err = -EINVAL;
+- goto done;
+- }
+-
+- hdev = hci_get_route(&sa->sco_bdaddr, &sco_pi(sk)->src, BDADDR_BREDR);
+- if (!hdev) {
+- err = -EHOSTUNREACH;
+- goto done;
+- }
+- hci_dev_lock(hdev);
+
++ lock_sock(sk);
+ /* Set destination address and psm */
+ bacpy(&sco_pi(sk)->dst, &sa->sco_bdaddr);
++ release_sock(sk);
+
+- err = sco_connect(hdev, sk);
+- hci_dev_unlock(hdev);
+- hci_dev_put(hdev);
++ err = sco_connect(sk);
+ if (err)
+- goto done;
++ return err;
++
++ lock_sock(sk);
+
+ err = bt_sock_wait_state(sk, BT_CONNECTED,
+ sock_sndtimeo(sk, flags & O_NONBLOCK));
+
+-done:
+ release_sock(sk);
+ return err;
+ }
--- /dev/null
+From 3dcaa192ac2159193bc6ab57bc5369dcb84edd8e Mon Sep 17 00:00:00 2001
+From: Pauli Virtanen <pav@iki.fi>
+Date: Mon, 10 Jul 2023 19:48:19 +0300
+Subject: Bluetooth: SCO: fix sco_conn related locking and validity issues
+
+From: Pauli Virtanen <pav@iki.fi>
+
+commit 3dcaa192ac2159193bc6ab57bc5369dcb84edd8e upstream.
+
+Operations that check/update sk_state and access conn should hold
+lock_sock, otherwise they can race.
+
+The order of taking locks is hci_dev_lock > lock_sock > sco_conn_lock,
+which is how it is in connect/disconnect_cfm -> sco_conn_del ->
+sco_chan_del.
+
+Fix locking in sco_connect to take lock_sock around updating sk_state
+and conn.
+
+sco_conn_del must not occur during sco_connect, as it frees the
+sco_conn. Hold hdev->lock longer to prevent that.
+
+sco_conn_add shall return sco_conn with valid hcon. Make it so also when
+reusing an old SCO connection waiting for disconnect timeout (see
+__sco_sock_close where conn->hcon is set to NULL).
+
+This should not reintroduce the issue fixed in the earlier
+commit 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking
+dependency on sco_connect_cfm"), the relevant fix of releasing lock_sock
+in sco_sock_connect before acquiring hdev->lock is retained.
+
+These changes mirror similar fixes earlier in ISO sockets.
+
+Fixes: 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm")
+Signed-off-by: Pauli Virtanen <pav@iki.fi>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/sco.c | 23 ++++++++++++-----------
+ 1 file changed, 12 insertions(+), 11 deletions(-)
+
+--- a/net/bluetooth/sco.c
++++ b/net/bluetooth/sco.c
+@@ -130,8 +130,11 @@ static struct sco_conn *sco_conn_add(str
+ struct hci_dev *hdev = hcon->hdev;
+ struct sco_conn *conn = hcon->sco_data;
+
+- if (conn)
++ if (conn) {
++ if (!conn->hcon)
++ conn->hcon = hcon;
+ return conn;
++ }
+
+ conn = kzalloc(sizeof(struct sco_conn), GFP_KERNEL);
+ if (!conn)
+@@ -272,21 +275,21 @@ static int sco_connect(struct sock *sk)
+ goto unlock;
+ }
+
+- hci_dev_unlock(hdev);
+- hci_dev_put(hdev);
+-
+ conn = sco_conn_add(hcon);
+ if (!conn) {
+ hci_conn_drop(hcon);
+- return -ENOMEM;
++ err = -ENOMEM;
++ goto unlock;
+ }
+
+- err = sco_chan_add(conn, sk, NULL);
+- if (err)
+- return err;
+-
+ lock_sock(sk);
+
++ err = sco_chan_add(conn, sk, NULL);
++ if (err) {
++ release_sock(sk);
++ goto unlock;
++ }
++
+ /* Update source addr of the socket */
+ bacpy(&sco_pi(sk)->src, &hcon->src);
+
+@@ -300,8 +303,6 @@ static int sco_connect(struct sock *sk)
+
+ release_sock(sk);
+
+- return err;
+-
+ unlock:
+ hci_dev_unlock(hdev);
+ hci_dev_put(hdev);
--- /dev/null
+From 3f5424790d4377839093b68c12b130077a4e4510 Mon Sep 17 00:00:00 2001
+From: zhanchengbin <zhanchengbin1@huawei.com>
+Date: Tue, 3 Jan 2023 10:28:12 +0800
+Subject: ext4: fix inode tree inconsistency caused by ENOMEM
+
+From: zhanchengbin <zhanchengbin1@huawei.com>
+
+commit 3f5424790d4377839093b68c12b130077a4e4510 upstream.
+
+If ENOMEM fails when the extent is splitting, we need to restore the length
+of the split extent.
+In the ext4_split_extent_at function, only in ext4_ext_create_new_leaf will
+it alloc memory and change the shape of the extent tree,even if an ENOMEM
+is returned at this time, the extent tree is still self-consistent, Just
+restore the split extent lens in the function ext4_split_extent_at.
+
+ext4_split_extent_at
+ ext4_ext_insert_extent
+ ext4_ext_create_new_leaf
+ 1)ext4_ext_split
+ ext4_find_extent
+ 2)ext4_ext_grow_indepth
+ ext4_find_extent
+
+Signed-off-by: zhanchengbin <zhanchengbin1@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230103022812.130603-1-zhanchengbin1@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/extents.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/ext4/extents.c
++++ b/fs/ext4/extents.c
+@@ -3229,7 +3229,7 @@ static int ext4_split_extent_at(handle_t
+ ext4_ext_mark_unwritten(ex2);
+
+ err = ext4_ext_insert_extent(handle, inode, ppath, &newex, flags);
+- if (err != -ENOSPC && err != -EDQUOT)
++ if (err != -ENOSPC && err != -EDQUOT && err != -ENOMEM)
+ goto out;
+
+ if (EXT4_EXT_MAY_ZEROOUT & split_flag) {
--- /dev/null
+From 04e568a3b31cfbd545c04c8bfc35c20e5ccfce0f Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Wed, 7 Dec 2022 12:27:04 +0100
+Subject: ext4: handle redirtying in ext4_bio_write_page()
+
+From: Jan Kara <jack@suse.cz>
+
+commit 04e568a3b31cfbd545c04c8bfc35c20e5ccfce0f upstream.
+
+Since we want to transition transaction commits to use ext4_writepages()
+for writing back ordered, add handling of page redirtying into
+ext4_bio_write_page(). Also move buffer dirty bit clearing into the same
+place other buffer state handling.
+
+Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20221207112722.22220-1-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/page-io.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/fs/ext4/page-io.c
++++ b/fs/ext4/page-io.c
+@@ -484,6 +484,13 @@ int ext4_bio_write_page(struct ext4_io_s
+ /* A hole? We can safely clear the dirty bit */
+ if (!buffer_mapped(bh))
+ clear_buffer_dirty(bh);
++ /*
++ * Keeping dirty some buffer we cannot write? Make
++ * sure to redirty the page. This happens e.g. when
++ * doing writeout for transaction commit.
++ */
++ if (buffer_dirty(bh) && !PageDirty(page))
++ redirty_page_for_writepage(wbc, page);
+ if (io->io_bio)
+ ext4_io_submit(io);
+ continue;
+@@ -491,6 +498,7 @@ int ext4_bio_write_page(struct ext4_io_s
+ if (buffer_new(bh))
+ clear_buffer_new(bh);
+ set_buffer_async_write(bh);
++ clear_buffer_dirty(bh);
+ nr_to_submit++;
+ } while ((bh = bh->b_this_page) != head);
+
+@@ -534,7 +542,10 @@ int ext4_bio_write_page(struct ext4_io_s
+ printk_ratelimited(KERN_ERR "%s: ret = %d\n", __func__, ret);
+ redirty_page_for_writepage(wbc, page);
+ do {
+- clear_buffer_async_write(bh);
++ if (buffer_async_write(bh)) {
++ clear_buffer_async_write(bh);
++ set_buffer_dirty(bh);
++ }
+ bh = bh->b_this_page;
+ } while (bh != head);
+ goto unlock;
+@@ -547,7 +558,6 @@ int ext4_bio_write_page(struct ext4_io_s
+ continue;
+ io_submit_add_bh(io, inode, page, bounce_page, bh);
+ nr_submitted++;
+- clear_buffer_dirty(bh);
+ } while ((bh = bh->b_this_page) != head);
+
+ unlock:
--- /dev/null
+From 8216776ccff6fcd40e3fdaa109aa4150ebe760b3 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Mon, 14 Aug 2023 11:29:01 -0700
+Subject: ext4: reject casefold inode flag without casefold feature
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 8216776ccff6fcd40e3fdaa109aa4150ebe760b3 upstream.
+
+It is invalid for the casefold inode flag to be set without the casefold
+superblock feature flag also being set. e2fsck already considers this
+case to be invalid and handles it by offering to clear the casefold flag
+on the inode. __ext4_iget() also already considered this to be invalid,
+sort of, but it only got so far as logging an error message; it didn't
+actually reject the inode. Make it reject the inode so that other code
+doesn't have to handle this case. This matches what f2fs does.
+
+Note: we could check 's_encoding != NULL' instead of
+ext4_has_feature_casefold(). This would make the check robust against
+the casefold feature being enabled by userspace writing to the page
+cache of the mounted block device. However, it's unsolvable in general
+for filesystems to be robust against concurrent writes to the page cache
+of the mounted block device. Though this very particular scenario
+involving the casefold feature is solvable, we should not pretend that
+we can support this model, so let's just check the casefold feature.
+tune2fs already forbids enabling casefold on a mounted filesystem.
+
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Link: https://lore.kernel.org/r/20230814182903.37267-2-ebiggers@kernel.org
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/inode.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/inode.c
++++ b/fs/ext4/inode.c
+@@ -5101,9 +5101,12 @@ struct inode *__ext4_iget(struct super_b
+ "iget: bogus i_mode (%o)", inode->i_mode);
+ goto bad_inode;
+ }
+- if (IS_CASEFOLDED(inode) && !ext4_has_feature_casefold(inode->i_sb))
++ if (IS_CASEFOLDED(inode) && !ext4_has_feature_casefold(inode->i_sb)) {
+ ext4_error_inode(inode, function, line, 0,
+ "casefold flag without casefold feature");
++ ret = -EFSCORRUPTED;
++ goto bad_inode;
++ }
+ if ((err_str = check_igot_inode(inode, flags)) != NULL) {
+ ext4_error_inode(inode, function, line, 0, err_str);
+ ret = -EFSCORRUPTED;
drm-amd-display-correct-the-defined-value-for-amdgpu.patch
drm-amd-display-skip-wbscl_set_scaler_filter-if-filt.patch
media-uvcvideo-enforce-alignment-of-frame-and-interv.patch
+virtio_net-fix-napi_skb_cache_put-warning.patch
+bluetooth-sco-fix-possible-circular-locking-dependency-on-sco_connect_cfm.patch
+bluetooth-sco-fix-sco_conn-related-locking-and-validity-issues.patch
+ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch
+udf-limit-file-size-to-4tb.patch
+ext4-reject-casefold-inode-flag-without-casefold-feature.patch
+ext4-handle-redirtying-in-ext4_bio_write_page.patch
--- /dev/null
+From c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Wed, 25 Jan 2023 17:56:06 +0100
+Subject: udf: Limit file size to 4TB
+
+From: Jan Kara <jack@suse.cz>
+
+commit c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8 upstream.
+
+UDF disk format supports in principle file sizes up to 1<<64-1. However
+the file space (including holes) is described by a linked list of
+extents, each of which can have at most 1GB. Thus the creation and
+handling of extents gets unusably slow beyond certain point. Limit the
+file size to 4TB to avoid locking up the kernel too easily.
+
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/super.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/fs/udf/super.c
++++ b/fs/udf/super.c
+@@ -86,6 +86,13 @@ enum {
+ #define UDF_MAX_LVID_NESTING 1000
+
+ enum { UDF_MAX_LINKS = 0xffff };
++/*
++ * We limit filesize to 4TB. This is arbitrary as the on-disk format supports
++ * more but because the file space is described by a linked list of extents,
++ * each of which can have at most 1GB, the creation and handling of extents
++ * gets unusably slow beyond certain point...
++ */
++#define UDF_MAX_FILESIZE (1ULL << 42)
+
+ /* These are the "meat" - everything else is stuffing */
+ static int udf_fill_super(struct super_block *, void *, int);
+@@ -2299,7 +2306,7 @@ static int udf_fill_super(struct super_b
+ ret = -ENOMEM;
+ goto error_out;
+ }
+- sb->s_maxbytes = MAX_LFS_FILESIZE;
++ sb->s_maxbytes = UDF_MAX_FILESIZE;
+ sb->s_max_links = UDF_MAX_LINKS;
+ return 0;
+
--- /dev/null
+From f8321fa75102246d7415a6af441872f6637c93ab Mon Sep 17 00:00:00 2001
+From: Breno Leitao <leitao@debian.org>
+Date: Fri, 12 Jul 2024 04:53:25 -0700
+Subject: virtio_net: Fix napi_skb_cache_put warning
+
+From: Breno Leitao <leitao@debian.org>
+
+commit f8321fa75102246d7415a6af441872f6637c93ab upstream.
+
+After the commit bdacf3e34945 ("net: Use nested-BH locking for
+napi_alloc_cache.") was merged, the following warning began to appear:
+
+ WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0
+
+ __warn+0x12f/0x340
+ napi_skb_cache_put+0x82/0x4b0
+ napi_skb_cache_put+0x82/0x4b0
+ report_bug+0x165/0x370
+ handle_bug+0x3d/0x80
+ exc_invalid_op+0x1a/0x50
+ asm_exc_invalid_op+0x1a/0x20
+ __free_old_xmit+0x1c8/0x510
+ napi_skb_cache_put+0x82/0x4b0
+ __free_old_xmit+0x1c8/0x510
+ __free_old_xmit+0x1c8/0x510
+ __pfx___free_old_xmit+0x10/0x10
+
+The issue arises because virtio is assuming it's running in NAPI context
+even when it's not, such as in the netpoll case.
+
+To resolve this, modify virtnet_poll_tx() to only set NAPI when budget
+is available. Same for virtnet_poll_cleantx(), which always assumed that
+it was in a NAPI context.
+
+Fixes: df133f3f9625 ("virtio_net: bulk free tx skbs")
+Suggested-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Breno Leitao <leitao@debian.org>
+Reviewed-by: Jakub Kicinski <kuba@kernel.org>
+Acked-by: Michael S. Tsirkin <mst@redhat.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Reviewed-by: Heng Qi <hengqi@linux.alibaba.com>
+Link: https://patch.msgid.link/20240712115325.54175-1-leitao@debian.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+[Shivani: Modified to apply on v6.6.y]
+Signed-off-by: Shivani Agarwal <shivani.agarwal@broadcom.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/virtio_net.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/virtio_net.c
++++ b/drivers/net/virtio_net.c
+@@ -1638,7 +1638,7 @@ static bool is_xdp_raw_buffer_queue(stru
+ return false;
+ }
+
+-static void virtnet_poll_cleantx(struct receive_queue *rq)
++static void virtnet_poll_cleantx(struct receive_queue *rq, int budget)
+ {
+ struct virtnet_info *vi = rq->vq->vdev->priv;
+ unsigned int index = vq2rxq(rq->vq);
+@@ -1656,7 +1656,7 @@ static void virtnet_poll_cleantx(struct
+
+ do {
+ virtqueue_disable_cb(sq->vq);
+- free_old_xmit_skbs(sq, true);
++ free_old_xmit_skbs(sq, !!budget);
+ } while (unlikely(!virtqueue_enable_cb_delayed(sq->vq)));
+
+ if (sq->vq->num_free >= 2 + MAX_SKB_FRAGS)
+@@ -1675,7 +1675,7 @@ static int virtnet_poll(struct napi_stru
+ unsigned int received;
+ unsigned int xdp_xmit = 0;
+
+- virtnet_poll_cleantx(rq);
++ virtnet_poll_cleantx(rq, budget);
+
+ received = virtnet_receive(rq, budget, &xdp_xmit);
+
+@@ -1778,7 +1778,7 @@ static int virtnet_poll_tx(struct napi_s
+ txq = netdev_get_tx_queue(vi->dev, index);
+ __netif_tx_lock(txq, raw_smp_processor_id());
+ virtqueue_disable_cb(sq->vq);
+- free_old_xmit_skbs(sq, true);
++ free_old_xmit_skbs(sq, !!budget);
+
+ if (sq->vq->num_free >= 2 + MAX_SKB_FRAGS)
+ netif_tx_wake_queue(txq);
projects / thirdparty / kernel / stable-queue.git / commitdiff
