]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.15-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 8 Jul 2024 12:43:04 +0000 (14:43 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 8 Jul 2024 12:43:04 +0000 (14:43 +0200)
added patches:
bluetooth-qca-fix-bt-enable-failure-again-for-qca6390-after-warm-reboot.patch
btrfs-fix-adding-block-group-to-a-reclaim-list-and-the-unused-list-during-reclaim.patch
can-kvaser_usb-explicitly-initialize-family-in-leafimx-driver_info-struct.patch
fsnotify-do-not-generate-events-for-o_path-file-descriptors.patch

queue-5.15/bluetooth-qca-fix-bt-enable-failure-again-for-qca6390-after-warm-reboot.patch [new file with mode: 0644]
queue-5.15/btrfs-fix-adding-block-group-to-a-reclaim-list-and-the-unused-list-during-reclaim.patch [new file with mode: 0644]
queue-5.15/can-kvaser_usb-explicitly-initialize-family-in-leafimx-driver_info-struct.patch [new file with mode: 0644]
queue-5.15/fsnotify-do-not-generate-events-for-o_path-file-descriptors.patch [new file with mode: 0644]
queue-5.15/series

diff --git a/queue-5.15/bluetooth-qca-fix-bt-enable-failure-again-for-qca6390-after-warm-reboot.patch b/queue-5.15/bluetooth-qca-fix-bt-enable-failure-again-for-qca6390-after-warm-reboot.patch
new file mode 100644 (file)
index 0000000..77dffc8
--- /dev/null
@@ -0,0 +1,77 @@
+From 88e72239ead9814b886db54fc4ee39ef3c2b8f26 Mon Sep 17 00:00:00 2001
+From: Zijun Hu <quic_zijuhu@quicinc.com>
+Date: Thu, 16 May 2024 21:31:34 +0800
+Subject: Bluetooth: qca: Fix BT enable failure again for QCA6390 after warm reboot
+
+From: Zijun Hu <quic_zijuhu@quicinc.com>
+
+commit 88e72239ead9814b886db54fc4ee39ef3c2b8f26 upstream.
+
+Commit 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed
+serdev") will cause below regression issue:
+
+BT can't be enabled after below steps:
+cold boot -> enable BT -> disable BT -> warm reboot -> BT enable failure
+if property enable-gpios is not configured within DT|ACPI for QCA6390.
+
+The commit is to fix a use-after-free issue within qca_serdev_shutdown()
+by adding condition to avoid the serdev is flushed or wrote after closed
+but also introduces this regression issue regarding above steps since the
+VSC is not sent to reset controller during warm reboot.
+
+Fixed by sending the VSC to reset controller within qca_serdev_shutdown()
+once BT was ever enabled, and the use-after-free issue is also fixed by
+this change since the serdev is still opened before it is flushed or wrote.
+
+Verified by the reported machine Dell XPS 13 9310 laptop over below two
+kernel commits:
+commit e00fc2700a3f ("Bluetooth: btusb: Fix triggering coredump
+implementation for QCA") of bluetooth-next tree.
+commit b23d98d46d28 ("Bluetooth: btusb: Fix triggering coredump
+implementation for QCA") of linus mainline tree.
+
+Fixes: 272970be3dab ("Bluetooth: hci_qca: Fix driver shutdown on closed serdev")
+Cc: stable@vger.kernel.org
+Reported-by: Wren Turkal <wt@penguintechs.org>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218726
+Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
+Tested-by: Wren Turkal <wt@penguintechs.org>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bluetooth/hci_qca.c |   18 +++++++++++++++---
+ 1 file changed, 15 insertions(+), 3 deletions(-)
+
+--- a/drivers/bluetooth/hci_qca.c
++++ b/drivers/bluetooth/hci_qca.c
+@@ -2340,15 +2340,27 @@ static void qca_serdev_shutdown(struct d
+       struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev);
+       struct hci_uart *hu = &qcadev->serdev_hu;
+       struct hci_dev *hdev = hu->hdev;
+-      struct qca_data *qca = hu->priv;
+       const u8 ibs_wake_cmd[] = { 0xFD };
+       const u8 edl_reset_soc_cmd[] = { 0x01, 0x00, 0xFC, 0x01, 0x05 };
+       if (qcadev->btsoc_type == QCA_QCA6390) {
+-              if (test_bit(QCA_BT_OFF, &qca->flags) ||
+-                  !test_bit(HCI_RUNNING, &hdev->flags))
++              /* The purpose of sending the VSC is to reset SOC into a initial
++               * state and the state will ensure next hdev->setup() success.
++               * if HCI_QUIRK_NON_PERSISTENT_SETUP is set, it means that
++               * hdev->setup() can do its job regardless of SoC state, so
++               * don't need to send the VSC.
++               * if HCI_SETUP is set, it means that hdev->setup() was never
++               * invoked and the SOC is already in the initial state, so
++               * don't also need to send the VSC.
++               */
++              if (test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks) ||
++                  hci_dev_test_flag(hdev, HCI_SETUP))
+                       return;
++              /* The serdev must be in open state when conrol logic arrives
++               * here, so also fix the use-after-free issue caused by that
++               * the serdev is flushed or wrote after it is closed.
++               */
+               serdev_device_write_flush(serdev);
+               ret = serdev_device_write_buf(serdev, ibs_wake_cmd,
+                                             sizeof(ibs_wake_cmd));
diff --git a/queue-5.15/btrfs-fix-adding-block-group-to-a-reclaim-list-and-the-unused-list-during-reclaim.patch b/queue-5.15/btrfs-fix-adding-block-group-to-a-reclaim-list-and-the-unused-list-during-reclaim.patch
new file mode 100644 (file)
index 0000000..fd5cb20
--- /dev/null
@@ -0,0 +1,110 @@
+From 48f091fd50b2eb33ae5eaea9ed3c4f81603acf38 Mon Sep 17 00:00:00 2001
+From: Naohiro Aota <naohiro.aota@wdc.com>
+Date: Fri, 28 Jun 2024 13:32:24 +0900
+Subject: btrfs: fix adding block group to a reclaim list and the unused list during reclaim
+
+From: Naohiro Aota <naohiro.aota@wdc.com>
+
+commit 48f091fd50b2eb33ae5eaea9ed3c4f81603acf38 upstream.
+
+There is a potential parallel list adding for retrying in
+btrfs_reclaim_bgs_work and adding to the unused list. Since the block
+group is removed from the reclaim list and it is on a relocation work,
+it can be added into the unused list in parallel. When that happens,
+adding it to the reclaim list will corrupt the list head and trigger
+list corruption like below.
+
+Fix it by taking fs_info->unused_bgs_lock.
+
+  [177.504][T2585409] BTRFS error (device nullb1): error relocating ch= unk 2415919104
+  [177.514][T2585409] list_del corruption. next->prev should be ff1100= 0344b119c0, but was ff11000377e87c70. (next=3Dff110002390cd9c0)
+  [177.529][T2585409] ------------[ cut here ]------------
+  [177.537][T2585409] kernel BUG at lib/list_debug.c:65!
+  [177.545][T2585409] Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI
+  [177.555][T2585409] CPU: 9 PID: 2585409 Comm: kworker/u128:2 Tainted: G        W          6.10.0-rc5-kts #1
+  [177.568][T2585409] Hardware name: Supermicro SYS-520P-WTR/X12SPW-TF, BIOS 1.2 02/14/2022
+  [177.579][T2585409] Workqueue: events_unbound btrfs_reclaim_bgs_work[btrfs]
+  [177.589][T2585409] RIP: 0010:__list_del_entry_valid_or_report.cold+0x70/0x72
+  [177.624][T2585409] RSP: 0018:ff11000377e87a70 EFLAGS: 00010286
+  [177.633][T2585409] RAX: 000000000000006d RBX: ff11000344b119c0 RCX:0000000000000000
+  [177.644][T2585409] RDX: 000000000000006d RSI: 0000000000000008 RDI:ffe21c006efd0f40
+  [177.655][T2585409] RBP: ff110002e0509f78 R08: 0000000000000001 R09:ffe21c006efd0f08
+  [177.665][T2585409] R10: ff11000377e87847 R11: 0000000000000000 R12:ff110002390cd9c0
+  [177.676][T2585409] R13: ff11000344b119c0 R14: ff110002e0508000 R15:dffffc0000000000
+  [177.687][T2585409] FS:  0000000000000000(0000) GS:ff11000fec880000(0000) knlGS:0000000000000000
+  [177.700][T2585409] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+  [177.709][T2585409] CR2: 00007f06bc7b1978 CR3: 0000001021e86005 CR4:0000000000771ef0
+  [177.720][T2585409] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000
+  [177.731][T2585409] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400
+  [177.742][T2585409] PKRU: 55555554
+  [177.748][T2585409] Call Trace:
+  [177.753][T2585409]  <TASK>
+  [177.759][T2585409]  ? __die_body.cold+0x19/0x27
+  [177.766][T2585409]  ? die+0x2e/0x50
+  [177.772][T2585409]  ? do_trap+0x1ea/0x2d0
+  [177.779][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
+  [177.788][T2585409]  ? do_error_trap+0xa3/0x160
+  [177.795][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
+  [177.805][T2585409]  ? handle_invalid_op+0x2c/0x40
+  [177.812][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
+  [177.820][T2585409]  ? exc_invalid_op+0x2d/0x40
+  [177.827][T2585409]  ? asm_exc_invalid_op+0x1a/0x20
+  [177.834][T2585409]  ? __list_del_entry_valid_or_report.cold+0x70/0x72
+  [177.843][T2585409]  btrfs_delete_unused_bgs+0x3d9/0x14c0 [btrfs]
+
+There is a similar retry_list code in btrfs_delete_unused_bgs(), but it is
+safe, AFAICS. Since the block group was in the unused list, the used bytes
+should be 0 when it was added to the unused list. Then, it checks
+block_group->{used,reserved,pinned} are still 0 under the
+block_group->lock. So, they should be still eligible for the unused list,
+not the reclaim list.
+
+The reason it is safe there it's because because we're holding
+space_info->groups_sem in write mode.
+
+That means no other task can allocate from the block group, so while we
+are at deleted_unused_bgs() it's not possible for other tasks to
+allocate and deallocate extents from the block group, so it can't be
+added to the unused list or the reclaim list by anyone else.
+
+The bug can be reproduced by btrfs/166 after a few rounds. In practice
+this can be hit when relocation cannot find more chunk space and ends
+with ENOSPC.
+
+Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
+Suggested-by: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
+Fixes: 4eb4e85c4f81 ("btrfs: retry block group reclaim without infinite loop")
+CC: stable@vger.kernel.org # 5.15+
+Reviewed-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/block-group.c |   13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/block-group.c
++++ b/fs/btrfs/block-group.c
+@@ -1586,8 +1586,17 @@ void btrfs_reclaim_bgs_work(struct work_
+ next:
+               if (ret) {
+                       /* Refcount held by the reclaim_bgs list after splice. */
+-                      btrfs_get_block_group(bg);
+-                      list_add_tail(&bg->bg_list, &retry_list);
++                      spin_lock(&fs_info->unused_bgs_lock);
++                      /*
++                       * This block group might be added to the unused list
++                       * during the above process. Move it back to the
++                       * reclaim list otherwise.
++                       */
++                      if (list_empty(&bg->bg_list)) {
++                              btrfs_get_block_group(bg);
++                              list_add_tail(&bg->bg_list, &retry_list);
++                      }
++                      spin_unlock(&fs_info->unused_bgs_lock);
+               }
+               btrfs_put_block_group(bg);
diff --git a/queue-5.15/can-kvaser_usb-explicitly-initialize-family-in-leafimx-driver_info-struct.patch b/queue-5.15/can-kvaser_usb-explicitly-initialize-family-in-leafimx-driver_info-struct.patch
new file mode 100644 (file)
index 0000000..674ddf8
--- /dev/null
@@ -0,0 +1,33 @@
+From 19d5b2698c35b2132a355c67b4d429053804f8cc Mon Sep 17 00:00:00 2001
+From: Jimmy Assarsson <extja@kvaser.com>
+Date: Fri, 28 Jun 2024 21:45:29 +0200
+Subject: can: kvaser_usb: Explicitly initialize family in leafimx driver_info struct
+
+From: Jimmy Assarsson <extja@kvaser.com>
+
+commit 19d5b2698c35b2132a355c67b4d429053804f8cc upstream.
+
+Explicitly set the 'family' driver_info struct member for leafimx.
+Previously, the correct operation relied on KVASER_LEAF being the first
+defined value in enum kvaser_usb_leaf_family.
+
+Fixes: e6c80e601053 ("can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression")
+Signed-off-by: Jimmy Assarsson <extja@kvaser.com>
+Link: https://lore.kernel.org/all/20240628194529.312968-1-extja@kvaser.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c
++++ b/drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c
+@@ -123,6 +123,7 @@ static const struct kvaser_usb_driver_in
+ static const struct kvaser_usb_driver_info kvaser_usb_driver_info_leafimx = {
+       .quirks = 0,
++      .family = KVASER_LEAF,
+       .ops = &kvaser_usb_leaf_dev_ops,
+ };
diff --git a/queue-5.15/fsnotify-do-not-generate-events-for-o_path-file-descriptors.patch b/queue-5.15/fsnotify-do-not-generate-events-for-o_path-file-descriptors.patch
new file mode 100644 (file)
index 0000000..5042358
--- /dev/null
@@ -0,0 +1,44 @@
+From 702eb71fd6501b3566283f8c96d7ccc6ddd662e9 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 17 Jun 2024 18:23:00 +0200
+Subject: fsnotify: Do not generate events for O_PATH file descriptors
+
+From: Jan Kara <jack@suse.cz>
+
+commit 702eb71fd6501b3566283f8c96d7ccc6ddd662e9 upstream.
+
+Currently we will not generate FS_OPEN events for O_PATH file
+descriptors but we will generate FS_CLOSE events for them. This is
+asymmetry is confusing. Arguably no fsnotify events should be generated
+for O_PATH file descriptors as they cannot be used to access or modify
+file content, they are just convenient handles to file objects like
+paths. So fix the asymmetry by stopping to generate FS_CLOSE for O_PATH
+file descriptors.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20240617162303.1596-1-jack@suse.cz
+Reviewed-by: Amir Goldstein <amir73il@gmail.com>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/fsnotify.h |    8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/include/linux/fsnotify.h
++++ b/include/linux/fsnotify.h
+@@ -93,7 +93,13 @@ static inline int fsnotify_file(struct f
+ {
+       const struct path *path = &file->f_path;
+-      if (file->f_mode & FMODE_NONOTIFY)
++      /*
++       * FMODE_NONOTIFY are fds generated by fanotify itself which should not
++       * generate new events. We also don't want to generate events for
++       * FMODE_PATH fds (involves open & close events) as they are just
++       * handle creation / destruction events and not "real" file events.
++       */
++      if (file->f_mode & (FMODE_NONOTIFY | FMODE_PATH))
+               return 0;
+       return fsnotify_parent(path->dentry, mask, path, FSNOTIFY_EVENT_PATH);
index d496b75f91ef107701efa1667339e15bd20e3378..2c1664c545b0d11d145c612f1564e931bf550a9b 100644 (file)
@@ -51,3 +51,7 @@ nilfs2-fix-inode-number-range-checks.patch
 nilfs2-add-missing-check-for-inode-numbers-on-directory-entries.patch
 mm-optimize-the-redundant-loop-of-mm_update_owner_next.patch
 mm-avoid-overflows-in-dirty-throttling-logic.patch
+btrfs-fix-adding-block-group-to-a-reclaim-list-and-the-unused-list-during-reclaim.patch
+bluetooth-qca-fix-bt-enable-failure-again-for-qca6390-after-warm-reboot.patch
+can-kvaser_usb-explicitly-initialize-family-in-leafimx-driver_info-struct.patch
+fsnotify-do-not-generate-events-for-o_path-file-descriptors.patch