--- /dev/null
+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
+@@ -2385,15 +2385,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));
--- /dev/null
+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
+@@ -1720,8 +1720,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);
+
--- /dev/null
+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
+@@ -124,6 +124,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,
+ };
+
--- /dev/null
+From 0d8968287a1cf7b03d07387dc871de3861b9f6b9 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Mon, 13 May 2024 08:40:27 -0700
+Subject: f2fs: Add inline to f2fs_build_fault_attr() stub
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 0d8968287a1cf7b03d07387dc871de3861b9f6b9 upstream.
+
+When building without CONFIG_F2FS_FAULT_INJECTION, there is a warning
+from each file that includes f2fs.h because the stub for
+f2fs_build_fault_attr() is missing inline:
+
+ In file included from fs/f2fs/segment.c:21:
+ fs/f2fs/f2fs.h:4605:12: warning: 'f2fs_build_fault_attr' defined but not used [-Wunused-function]
+ 4605 | static int f2fs_build_fault_attr(struct f2fs_sb_info *sbi, unsigned long rate,
+ | ^~~~~~~~~~~~~~~~~~~~~
+
+Add the missing inline to resolve all of the warnings for this
+configuration.
+
+Fixes: 4ed886b187f4 ("f2fs: check validation of fault attrs in f2fs_build_fault_attr()")
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/f2fs.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/f2fs/f2fs.h
++++ b/fs/f2fs/f2fs.h
+@@ -4533,8 +4533,8 @@ static inline bool f2fs_need_verity(cons
+ extern int f2fs_build_fault_attr(struct f2fs_sb_info *sbi, unsigned long rate,
+ unsigned long type);
+ #else
+-static int f2fs_build_fault_attr(struct f2fs_sb_info *sbi, unsigned long rate,
+- unsigned long type)
++static inline int f2fs_build_fault_attr(struct f2fs_sb_info *sbi,
++ unsigned long rate, unsigned long type)
+ {
+ return 0;
+ }
--- /dev/null
+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);
--- /dev/null
+From 9f365cb8bbd0162963d6852651d7c9e30adcb7b5 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <nathan@kernel.org>
+Date: Tue, 14 May 2024 13:47:23 -0700
+Subject: scsi: mpi3mr: Use proper format specifier in mpi3mr_sas_port_add()
+
+From: Nathan Chancellor <nathan@kernel.org>
+
+commit 9f365cb8bbd0162963d6852651d7c9e30adcb7b5 upstream.
+
+When building for a 32-bit platform such as ARM or i386, for which size_t
+is unsigned int, there is a warning due to using an unsigned long format
+specifier:
+
+ drivers/scsi/mpi3mr/mpi3mr_transport.c:1370:11: error: format specifies type 'unsigned long' but the argument has type 'unsigned int' [-Werror,-Wformat]
+ 1369 | ioc_warn(mrioc, "skipping port %u, max allowed value is %lu\n",
+ | ~~~
+ | %u
+ 1370 | i, sizeof(mr_sas_port->phy_mask) * 8);
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Use the proper format specifier for size_t, %zu, to resolve the warning for
+all platforms.
+
+Fixes: 3668651def2c ("scsi: mpi3mr: Sanitise num_phys")
+Signed-off-by: Nathan Chancellor <nathan@kernel.org>
+Link: https://lore.kernel.org/r/20240514-mpi3mr-fix-wformat-v1-1-f1ad49217e5e@kernel.org
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/mpi3mr/mpi3mr_transport.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/scsi/mpi3mr/mpi3mr_transport.c
++++ b/drivers/scsi/mpi3mr/mpi3mr_transport.c
+@@ -1366,7 +1366,7 @@ static struct mpi3mr_sas_port *mpi3mr_sa
+ continue;
+
+ if (i > sizeof(mr_sas_port->phy_mask) * 8) {
+- ioc_warn(mrioc, "skipping port %u, max allowed value is %lu\n",
++ ioc_warn(mrioc, "skipping port %u, max allowed value is %zu\n",
+ i, sizeof(mr_sas_port->phy_mask) * 8);
+ goto out_fail;
+ }
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
+f2fs-add-inline-to-f2fs_build_fault_attr-stub.patch
+scsi-mpi3mr-use-proper-format-specifier-in-mpi3mr_sas_port_add.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
projects / thirdparty / kernel / stable-queue.git / commitdiff
