From: Greg Kroah-Hartman Date: Thu, 5 Sep 2024 08:15:57 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v6.1.109~12 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1f197b0ee6169e7ed84de004c96881086480cede;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: 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 ext4-handle-redirtying-in-ext4_bio_write_page.patch ext4-reject-casefold-inode-flag-without-casefold-feature.patch udf-limit-file-size-to-4tb.patch virtio_net-fix-napi_skb_cache_put-warning.patch --- diff --git a/queue-6.1/bluetooth-sco-fix-possible-circular-locking-dependency-on-sco_connect_cfm.patch b/queue-6.1/bluetooth-sco-fix-possible-circular-locking-dependency-on-sco_connect_cfm.patch new file mode 100644 index 00000000000..17243e85fe7 --- /dev/null +++ b/queue-6.1/bluetooth-sco-fix-possible-circular-locking-dependency-on-sco_connect_cfm.patch @@ -0,0 +1,227 @@ +From 9a8ec9e8ebb5a7c0cfbce2d6b4a6b67b2b78e8f3 Mon Sep 17 00:00:00 2001 +From: Luiz Augusto von Dentz +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 + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.1/bluetooth-sco-fix-sco_conn-related-locking-and-validity-issues.patch b/queue-6.1/bluetooth-sco-fix-sco_conn-related-locking-and-validity-issues.patch new file mode 100644 index 00000000000..07cb656f42c --- /dev/null +++ b/queue-6.1/bluetooth-sco-fix-sco_conn-related-locking-and-validity-issues.patch @@ -0,0 +1,95 @@ +From 3dcaa192ac2159193bc6ab57bc5369dcb84edd8e Mon Sep 17 00:00:00 2001 +From: Pauli Virtanen +Date: Mon, 10 Jul 2023 19:48:19 +0300 +Subject: Bluetooth: SCO: fix sco_conn related locking and validity issues + +From: Pauli Virtanen + +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 +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-6.1/ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch b/queue-6.1/ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch new file mode 100644 index 00000000000..34359647525 --- /dev/null +++ b/queue-6.1/ext4-fix-inode-tree-inconsistency-caused-by-enomem.patch @@ -0,0 +1,44 @@ +From 3f5424790d4377839093b68c12b130077a4e4510 Mon Sep 17 00:00:00 2001 +From: zhanchengbin +Date: Tue, 3 Jan 2023 10:28:12 +0800 +Subject: ext4: fix inode tree inconsistency caused by ENOMEM + +From: zhanchengbin + +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 +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20230103022812.130603-1-zhanchengbin1@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + 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) { diff --git a/queue-6.1/ext4-handle-redirtying-in-ext4_bio_write_page.patch b/queue-6.1/ext4-handle-redirtying-in-ext4_bio_write_page.patch new file mode 100644 index 00000000000..018c0acdc7a --- /dev/null +++ b/queue-6.1/ext4-handle-redirtying-in-ext4_bio_write_page.patch @@ -0,0 +1,67 @@ +From 04e568a3b31cfbd545c04c8bfc35c20e5ccfce0f Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Wed, 7 Dec 2022 12:27:04 +0100 +Subject: ext4: handle redirtying in ext4_bio_write_page() + +From: Jan Kara + +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) +Signed-off-by: Jan Kara +Link: https://lore.kernel.org/r/20221207112722.22220-1-jack@suse.cz +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-6.1/ext4-reject-casefold-inode-flag-without-casefold-feature.patch b/queue-6.1/ext4-reject-casefold-inode-flag-without-casefold-feature.patch new file mode 100644 index 00000000000..8295ba88339 --- /dev/null +++ b/queue-6.1/ext4-reject-casefold-inode-flag-without-casefold-feature.patch @@ -0,0 +1,51 @@ +From 8216776ccff6fcd40e3fdaa109aa4150ebe760b3 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Mon, 14 Aug 2023 11:29:01 -0700 +Subject: ext4: reject casefold inode flag without casefold feature + +From: Eric Biggers + +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 +Link: https://lore.kernel.org/r/20230814182903.37267-2-ebiggers@kernel.org +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.1/series b/queue-6.1/series index fe67d6246d3..0ba23792d12 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -94,3 +94,10 @@ drm-amd-display-added-null-check-at-start-of-dc_vali.patch 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 diff --git a/queue-6.1/udf-limit-file-size-to-4tb.patch b/queue-6.1/udf-limit-file-size-to-4tb.patch new file mode 100644 index 00000000000..7fd136f95e2 --- /dev/null +++ b/queue-6.1/udf-limit-file-size-to-4tb.patch @@ -0,0 +1,46 @@ +From c2efd13a2ed4f29bf9ef14ac2fbb7474084655f8 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Wed, 25 Jan 2023 17:56:06 +0100 +Subject: udf: Limit file size to 4TB + +From: Jan Kara + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-6.1/virtio_net-fix-napi_skb_cache_put-warning.patch b/queue-6.1/virtio_net-fix-napi_skb_cache_put-warning.patch new file mode 100644 index 00000000000..5dcb4415401 --- /dev/null +++ b/queue-6.1/virtio_net-fix-napi_skb_cache_put-warning.patch @@ -0,0 +1,88 @@ +From f8321fa75102246d7415a6af441872f6637c93ab Mon Sep 17 00:00:00 2001 +From: Breno Leitao +Date: Fri, 12 Jul 2024 04:53:25 -0700 +Subject: virtio_net: Fix napi_skb_cache_put warning + +From: Breno Leitao + +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 +Signed-off-by: Breno Leitao +Reviewed-by: Jakub Kicinski +Acked-by: Michael S. Tsirkin +Acked-by: Jason Wang +Reviewed-by: Heng Qi +Link: https://patch.msgid.link/20240712115325.54175-1-leitao@debian.org +Signed-off-by: Jakub Kicinski +[Shivani: Modified to apply on v6.6.y] +Signed-off-by: Shivani Agarwal +Signed-off-by: Greg Kroah-Hartman +--- + 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);