]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
6.1-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 7 Oct 2024 17:34:57 +0000 (19:34 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 7 Oct 2024 17:34:57 +0000 (19:34 +0200)
added patches:
acpi-resource-add-asus-expertbook-b2502cva-to-irq1_level_low_skip_override.patch
acpi-resource-add-asus-vivobook-x1704vap-to-irq1_level_low_skip_override.patch
bluetooth-hci_event-align-br-edr-just_works-paring-with-le.patch
btrfs-fix-a-null-pointer-dereference-when-failed-to-start-a-new-trasacntion.patch
btrfs-send-fix-invalid-clone-operation-for-file-that-got-its-size-decreased.patch
btrfs-wait-for-fixup-workers-before-stopping-cleaner-kthread-during-umount.patch
ceph-fix-cap-ref-leak-via-netfs-init_request.patch
gpio-davinci-fix-lazy-disable.patch
tracing-hwlat-fix-a-race-during-cpuhp-processing.patch
tracing-timerlat-fix-a-race-during-cpuhp-processing.patch

queue-6.1/acpi-resource-add-asus-expertbook-b2502cva-to-irq1_level_low_skip_override.patch [new file with mode: 0644]
queue-6.1/acpi-resource-add-asus-vivobook-x1704vap-to-irq1_level_low_skip_override.patch [new file with mode: 0644]
queue-6.1/bluetooth-hci_event-align-br-edr-just_works-paring-with-le.patch [new file with mode: 0644]
queue-6.1/btrfs-fix-a-null-pointer-dereference-when-failed-to-start-a-new-trasacntion.patch [new file with mode: 0644]
queue-6.1/btrfs-send-fix-invalid-clone-operation-for-file-that-got-its-size-decreased.patch [new file with mode: 0644]
queue-6.1/btrfs-wait-for-fixup-workers-before-stopping-cleaner-kthread-during-umount.patch [new file with mode: 0644]
queue-6.1/ceph-fix-cap-ref-leak-via-netfs-init_request.patch [new file with mode: 0644]
queue-6.1/gpio-davinci-fix-lazy-disable.patch [new file with mode: 0644]
queue-6.1/series
queue-6.1/tracing-hwlat-fix-a-race-during-cpuhp-processing.patch [new file with mode: 0644]
queue-6.1/tracing-timerlat-fix-a-race-during-cpuhp-processing.patch [new file with mode: 0644]

diff --git a/queue-6.1/acpi-resource-add-asus-expertbook-b2502cva-to-irq1_level_low_skip_override.patch b/queue-6.1/acpi-resource-add-asus-expertbook-b2502cva-to-irq1_level_low_skip_override.patch
new file mode 100644 (file)
index 0000000..108d5ce
--- /dev/null
@@ -0,0 +1,42 @@
+From 056301e7c7c886f96d799edd36f3406cc30e1822 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 27 Sep 2024 16:16:06 +0200
+Subject: ACPI: resource: Add Asus ExpertBook B2502CVA to irq1_level_low_skip_override[]
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 056301e7c7c886f96d799edd36f3406cc30e1822 upstream.
+
+Like other Asus ExpertBook models the B2502CVA has its keybopard IRQ (1)
+described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh
+which breaks the keyboard.
+
+Add the B2502CVA to the irq1_level_low_skip_override[] quirk table to fix
+this.
+
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217760
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://patch.msgid.link/20240927141606.66826-4-hdegoede@redhat.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/resource.c |    7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -514,6 +514,13 @@ static const struct dmi_system_id mainge
+               }
+       },
+       {
++              /* Asus ExpertBook B2502CVA */
++              .matches = {
++                      DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++                      DMI_MATCH(DMI_BOARD_NAME, "B2502CVA"),
++              },
++      },
++      {
+               /* TongFang GMxXGxx/TUXEDO Polaris 15 Gen5 AMD */
+               .matches = {
+                       DMI_MATCH(DMI_BOARD_NAME, "GMxXGxx"),
diff --git a/queue-6.1/acpi-resource-add-asus-vivobook-x1704vap-to-irq1_level_low_skip_override.patch b/queue-6.1/acpi-resource-add-asus-vivobook-x1704vap-to-irq1_level_low_skip_override.patch
new file mode 100644 (file)
index 0000000..80d730d
--- /dev/null
@@ -0,0 +1,44 @@
+From 2f80ce0b78c340e332f04a5801dee5e4ac8cfaeb Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 27 Sep 2024 16:16:05 +0200
+Subject: ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 2f80ce0b78c340e332f04a5801dee5e4ac8cfaeb upstream.
+
+Like other Asus Vivobook models the X1704VAP has its keybopard IRQ (1)
+described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh
+which breaks the keyboard.
+
+Add the X1704VAP to the irq1_level_low_skip_override[] quirk table to fix
+this.
+
+Reported-by: Lamome Julien <julien.lamome@wanadoo.fr>
+Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078696
+Closes: https://lore.kernel.org/all/1226760b-4699-4529-bf57-6423938157a3@wanadoo.fr/
+Cc: All applicable <stable@vger.kernel.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Link: https://patch.msgid.link/20240927141606.66826-3-hdegoede@redhat.com
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/resource.c |    7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/acpi/resource.c
++++ b/drivers/acpi/resource.c
+@@ -440,6 +440,13 @@ static const struct dmi_system_id asus_l
+               },
+       },
+       {
++              /* Asus Vivobook X1704VAP */
++              .matches = {
++                      DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++                      DMI_MATCH(DMI_BOARD_NAME, "X1704VAP"),
++              },
++      },
++      {
+               .ident = "Asus ExpertBook B1402CBA",
+               .matches = {
+                       DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
diff --git a/queue-6.1/bluetooth-hci_event-align-br-edr-just_works-paring-with-le.patch b/queue-6.1/bluetooth-hci_event-align-br-edr-just_works-paring-with-le.patch
new file mode 100644 (file)
index 0000000..7d35da7
--- /dev/null
@@ -0,0 +1,52 @@
+From b25e11f978b63cb7857890edb3a698599cddb10e Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Thu, 12 Sep 2024 12:17:00 -0400
+Subject: Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+commit b25e11f978b63cb7857890edb3a698599cddb10e upstream.
+
+This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4
+("Bluetooth: Always request for user confirmation for Just Works")
+always request user confirmation with confirm_hint set since the
+likes of bluetoothd have dedicated policy around JUST_WORKS method
+(e.g. main.conf:JustWorksRepairing).
+
+CVE: CVE-2024-8805
+Cc: stable@vger.kernel.org
+Fixes: ba15a58b179e ("Bluetooth: Fix SSP acceptor just-works confirmation without MITM")
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Tested-by: Kiran K <kiran.k@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_event.c |   13 +++++--------
+ 1 file changed, 5 insertions(+), 8 deletions(-)
+
+--- a/net/bluetooth/hci_event.c
++++ b/net/bluetooth/hci_event.c
+@@ -5422,19 +5422,16 @@ static void hci_user_confirm_request_evt
+               goto unlock;
+       }
+-      /* If no side requires MITM protection; auto-accept */
++      /* If no side requires MITM protection; use JUST_CFM method */
+       if ((!loc_mitm || conn->remote_cap == HCI_IO_NO_INPUT_OUTPUT) &&
+           (!rem_mitm || conn->io_capability == HCI_IO_NO_INPUT_OUTPUT)) {
+-              /* If we're not the initiators request authorization to
+-               * proceed from user space (mgmt_user_confirm with
+-               * confirm_hint set to 1). The exception is if neither
+-               * side had MITM or if the local IO capability is
+-               * NoInputNoOutput, in which case we do auto-accept
++              /* If we're not the initiator of request authorization and the
++               * local IO capability is not NoInputNoOutput, use JUST_WORKS
++               * method (mgmt_user_confirm with confirm_hint set to 1).
+                */
+               if (!test_bit(HCI_CONN_AUTH_PEND, &conn->flags) &&
+-                  conn->io_capability != HCI_IO_NO_INPUT_OUTPUT &&
+-                  (loc_mitm || rem_mitm)) {
++                  conn->io_capability != HCI_IO_NO_INPUT_OUTPUT) {
+                       bt_dev_dbg(hdev, "Confirming auto-accept as acceptor");
+                       confirm_hint = 1;
+                       goto confirm;
diff --git a/queue-6.1/btrfs-fix-a-null-pointer-dereference-when-failed-to-start-a-new-trasacntion.patch b/queue-6.1/btrfs-fix-a-null-pointer-dereference-when-failed-to-start-a-new-trasacntion.patch
new file mode 100644 (file)
index 0000000..21efa90
--- /dev/null
@@ -0,0 +1,89 @@
+From c3b47f49e83197e8dffd023ec568403bcdbb774b Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Sat, 28 Sep 2024 08:05:58 +0930
+Subject: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit c3b47f49e83197e8dffd023ec568403bcdbb774b upstream.
+
+[BUG]
+Syzbot reported a NULL pointer dereference with the following crash:
+
+  FAULT_INJECTION: forcing a failure.
+   start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676
+   prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642
+   relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678
+  ...
+  BTRFS info (device loop0): balance: ended with status: -12
+  Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI
+  KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]
+  RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926
+  Call Trace:
+   <TASK>
+   commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496
+   btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430
+   del_balance_item fs/btrfs/volumes.c:3678 [inline]
+   reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742
+   btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574
+   btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673
+   vfs_ioctl fs/ioctl.c:51 [inline]
+   __do_sys_ioctl fs/ioctl.c:907 [inline]
+   __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893
+   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
+   entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+[CAUSE]
+The allocation failure happens at the start_transaction() inside
+prepare_to_relocate(), and during the error handling we call
+unset_reloc_control(), which makes fs_info->balance_ctl to be NULL.
+
+Then we continue the error path cleanup in btrfs_balance() by calling
+reset_balance_state() which will call del_balance_item() to fully delete
+the balance item in the root tree.
+
+However during the small window between set_reloc_contrl() and
+unset_reloc_control(), we can have a subvolume tree update and created a
+reloc_root for that subvolume.
+
+Then we go into the final btrfs_commit_transaction() of
+del_balance_item(), and into btrfs_update_reloc_root() inside
+commit_fs_roots().
+
+That function checks if fs_info->reloc_ctl is in the merge_reloc_tree
+stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer
+dereference.
+
+[FIX]
+Just add extra check on fs_info->reloc_ctl inside
+btrfs_update_reloc_root(), before checking
+fs_info->reloc_ctl->merge_reloc_tree.
+
+That DEAD_RELOC_TREE handling is to prevent further modification to the
+reloc tree during merge stage, but since there is no reloc_ctl at all,
+we do not need to bother that.
+
+Reported-by: syzbot+283673dbc38527ef9f3d@syzkaller.appspotmail.com
+Link: https://lore.kernel.org/linux-btrfs/66f6bfa7.050a0220.38ace9.0019.GAE@google.com/
+CC: stable@vger.kernel.org # 4.19+
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Qu Wenruo <wqu@suse.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/relocation.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/btrfs/relocation.c
++++ b/fs/btrfs/relocation.c
+@@ -921,7 +921,7 @@ int btrfs_update_reloc_root(struct btrfs
+       btrfs_grab_root(reloc_root);
+       /* root->reloc_root will stay until current relocation finished */
+-      if (fs_info->reloc_ctl->merge_reloc_tree &&
++      if (fs_info->reloc_ctl && fs_info->reloc_ctl->merge_reloc_tree &&
+           btrfs_root_refs(root_item) == 0) {
+               set_bit(BTRFS_ROOT_DEAD_RELOC_TREE, &root->state);
+               /*
diff --git a/queue-6.1/btrfs-send-fix-invalid-clone-operation-for-file-that-got-its-size-decreased.patch b/queue-6.1/btrfs-send-fix-invalid-clone-operation-for-file-that-got-its-size-decreased.patch
new file mode 100644 (file)
index 0000000..ac3f221
--- /dev/null
@@ -0,0 +1,128 @@
+From fa630df665aa9ddce3a96ce7b54e10a38e4d2a2b Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Fri, 27 Sep 2024 10:50:12 +0100
+Subject: btrfs: send: fix invalid clone operation for file that got its size decreased
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit fa630df665aa9ddce3a96ce7b54e10a38e4d2a2b upstream.
+
+During an incremental send we may end up sending an invalid clone
+operation, for the last extent of a file which ends at an unaligned offset
+that matches the final i_size of the file in the send snapshot, in case
+the file had its initial size (the size in the parent snapshot) decreased
+in the send snapshot. In this case the destination will fail to apply the
+clone operation because its end offset is not sector size aligned and it
+ends before the current size of the file.
+
+Sending the truncate operation always happens when we finish processing an
+inode, after we process all its extents (and xattrs, names, etc). So fix
+this by ensuring the file has a valid size before we send a clone
+operation for an unaligned extent that ends at the final i_size of the
+file. The size we truncate to matches the start offset of the clone range
+but it could be any value between that start offset and the final size of
+the file since the clone operation will expand the i_size if the current
+size is smaller than the end offset. The start offset of the range was
+chosen because it's always sector size aligned and avoids a truncation
+into the middle of a page, which results in dirtying the page due to
+filling part of it with zeroes and then making the clone operation at the
+receiver trigger IO.
+
+The following test reproduces the issue:
+
+  $ cat test.sh
+  #!/bin/bash
+
+  DEV=/dev/sdi
+  MNT=/mnt/sdi
+
+  mkfs.btrfs -f $DEV
+  mount $DEV $MNT
+
+  # Create a file with a size of 256K + 5 bytes, having two extents, one
+  # with a size of 128K and another one with a size of 128K + 5 bytes.
+  last_ext_size=$((128 * 1024 + 5))
+  xfs_io -f -d -c "pwrite -S 0xab -b 128K 0 128K" \
+         -c "pwrite -S 0xcd -b $last_ext_size 128K $last_ext_size" \
+         $MNT/foo
+
+  # Another file which we will later clone foo into, but initially with
+  # a larger size than foo.
+  xfs_io -f -c "pwrite -S 0xef 0 1M" $MNT/bar
+
+  btrfs subvolume snapshot -r $MNT/ $MNT/snap1
+
+  # Now resize bar and clone foo into it.
+  xfs_io -c "truncate 0" \
+         -c "reflink $MNT/foo" $MNT/bar
+
+  btrfs subvolume snapshot -r $MNT/ $MNT/snap2
+
+  rm -f /tmp/send-full /tmp/send-inc
+  btrfs send -f /tmp/send-full $MNT/snap1
+  btrfs send -p $MNT/snap1 -f /tmp/send-inc $MNT/snap2
+
+  umount $MNT
+  mkfs.btrfs -f $DEV
+  mount $DEV $MNT
+
+  btrfs receive -f /tmp/send-full $MNT
+  btrfs receive -f /tmp/send-inc $MNT
+
+  umount $MNT
+
+Running it before this patch:
+
+  $ ./test.sh
+  (...)
+  At subvol snap1
+  At snapshot snap2
+  ERROR: failed to clone extents to bar: Invalid argument
+
+A test case for fstests will be sent soon.
+
+Reported-by: Ben Millwood <thebenmachine@gmail.com>
+Link: https://lore.kernel.org/linux-btrfs/CAJhrHS2z+WViO2h=ojYvBPDLsATwLbg+7JaNCyYomv0fUxEpQQ@mail.gmail.com/
+Fixes: 46a6e10a1ab1 ("btrfs: send: allow cloning non-aligned extent if it ends at i_size")
+CC: stable@vger.kernel.org # 6.11
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/send.c |   23 ++++++++++++++++++++++-
+ 1 file changed, 22 insertions(+), 1 deletion(-)
+
+--- a/fs/btrfs/send.c
++++ b/fs/btrfs/send.c
+@@ -5941,8 +5941,29 @@ static int send_write_or_clone(struct se
+       if (ret < 0)
+               return ret;
+-      if (clone_root->offset + num_bytes == info.size)
++      if (clone_root->offset + num_bytes == info.size) {
++              /*
++               * The final size of our file matches the end offset, but it may
++               * be that its current size is larger, so we have to truncate it
++               * to any value between the start offset of the range and the
++               * final i_size, otherwise the clone operation is invalid
++               * because it's unaligned and it ends before the current EOF.
++               * We do this truncate to the final i_size when we finish
++               * processing the inode, but it's too late by then. And here we
++               * truncate to the start offset of the range because it's always
++               * sector size aligned while if it were the final i_size it
++               * would result in dirtying part of a page, filling part of a
++               * page with zeroes and then having the clone operation at the
++               * receiver trigger IO and wait for it due to the dirty page.
++               */
++              if (sctx->parent_root != NULL) {
++                      ret = send_truncate(sctx, sctx->cur_ino,
++                                          sctx->cur_inode_gen, offset);
++                      if (ret < 0)
++                              return ret;
++              }
+               goto clone_data;
++      }
+ write_data:
+       ret = send_extent_data(sctx, path, offset, num_bytes);
diff --git a/queue-6.1/btrfs-wait-for-fixup-workers-before-stopping-cleaner-kthread-during-umount.patch b/queue-6.1/btrfs-wait-for-fixup-workers-before-stopping-cleaner-kthread-during-umount.patch
new file mode 100644 (file)
index 0000000..b95546e
--- /dev/null
@@ -0,0 +1,227 @@
+From 41fd1e94066a815a7ab0a7025359e9b40e4b3576 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Tue, 1 Oct 2024 11:06:52 +0100
+Subject: btrfs: wait for fixup workers before stopping cleaner kthread during umount
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit 41fd1e94066a815a7ab0a7025359e9b40e4b3576 upstream.
+
+During unmount, at close_ctree(), we have the following steps in this order:
+
+1) Park the cleaner kthread - this doesn't destroy the kthread, it basically
+   halts its execution (wake ups against it work but do nothing);
+
+2) We stop the cleaner kthread - this results in freeing the respective
+   struct task_struct;
+
+3) We call btrfs_stop_all_workers() which waits for any jobs running in all
+   the work queues and then free the work queues.
+
+Syzbot reported a case where a fixup worker resulted in a crash when doing
+a delayed iput on its inode while attempting to wake up the cleaner at
+btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread
+was already freed. This can happen during unmount because we don't wait
+for any fixup workers still running before we call kthread_stop() against
+the cleaner kthread, which stops and free all its resources.
+
+Fix this by waiting for any fixup workers at close_ctree() before we call
+kthread_stop() against the cleaner and run pending delayed iputs.
+
+The stack traces reported by syzbot were the following:
+
+  BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065
+  Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52
+
+  CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0
+  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
+  Workqueue: btrfs-fixup btrfs_work_helper
+  Call Trace:
+   <TASK>
+   __dump_stack lib/dump_stack.c:94 [inline]
+   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
+   print_address_description mm/kasan/report.c:377 [inline]
+   print_report+0x169/0x550 mm/kasan/report.c:488
+   kasan_report+0x143/0x180 mm/kasan/report.c:601
+   __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065
+   lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825
+   __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
+   _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162
+   class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]
+   try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154
+   btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842
+   btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314
+   process_one_work kernel/workqueue.c:3229 [inline]
+   process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310
+   worker_thread+0x870/0xd30 kernel/workqueue.c:3391
+   kthread+0x2f0/0x390 kernel/kthread.c:389
+   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
+   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
+   </TASK>
+
+  Allocated by task 2:
+   kasan_save_stack mm/kasan/common.c:47 [inline]
+   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
+   unpoison_slab_object mm/kasan/common.c:319 [inline]
+   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345
+   kasan_slab_alloc include/linux/kasan.h:247 [inline]
+   slab_post_alloc_hook mm/slub.c:4086 [inline]
+   slab_alloc_node mm/slub.c:4135 [inline]
+   kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187
+   alloc_task_struct_node kernel/fork.c:180 [inline]
+   dup_task_struct+0x57/0x8c0 kernel/fork.c:1107
+   copy_process+0x5d1/0x3d50 kernel/fork.c:2206
+   kernel_clone+0x223/0x880 kernel/fork.c:2787
+   kernel_thread+0x1bc/0x240 kernel/fork.c:2849
+   create_kthread kernel/kthread.c:412 [inline]
+   kthreadd+0x60d/0x810 kernel/kthread.c:765
+   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
+   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
+
+  Freed by task 61:
+   kasan_save_stack mm/kasan/common.c:47 [inline]
+   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
+   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
+   poison_slab_object mm/kasan/common.c:247 [inline]
+   __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264
+   kasan_slab_free include/linux/kasan.h:230 [inline]
+   slab_free_hook mm/slub.c:2343 [inline]
+   slab_free mm/slub.c:4580 [inline]
+   kmem_cache_free+0x1a2/0x420 mm/slub.c:4682
+   put_task_struct include/linux/sched/task.h:144 [inline]
+   delayed_put_task_struct+0x125/0x300 kernel/exit.c:228
+   rcu_do_batch kernel/rcu/tree.c:2567 [inline]
+   rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823
+   handle_softirqs+0x2c5/0x980 kernel/softirq.c:554
+   __do_softirq kernel/softirq.c:588 [inline]
+   invoke_softirq kernel/softirq.c:428 [inline]
+   __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
+   irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
+   instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1037 [inline]
+   sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1037
+   asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
+
+  Last potentially related work creation:
+   kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
+   __kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541
+   __call_rcu_common kernel/rcu/tree.c:3086 [inline]
+   call_rcu+0x167/0xa70 kernel/rcu/tree.c:3190
+   context_switch kernel/sched/core.c:5318 [inline]
+   __schedule+0x184b/0x4ae0 kernel/sched/core.c:6675
+   schedule_idle+0x56/0x90 kernel/sched/core.c:6793
+   do_idle+0x56a/0x5d0 kernel/sched/idle.c:354
+   cpu_startup_entry+0x42/0x60 kernel/sched/idle.c:424
+   start_secondary+0x102/0x110 arch/x86/kernel/smpboot.c:314
+   common_startup_64+0x13e/0x147
+
+  The buggy address belongs to the object at ffff8880272a8000
+   which belongs to the cache task_struct of size 7424
+  The buggy address is located 2584 bytes inside of
+   freed 7424-byte region [ffff8880272a8000, ffff8880272a9d00)
+
+  The buggy address belongs to the physical page:
+  page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x272a8
+  head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
+  flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
+  page_type: f5(slab)
+  raw: 00fff00000000040 ffff88801bafa500 dead000000000122 0000000000000000
+  raw: 0000000000000000 0000000080040004 00000001f5000000 0000000000000000
+  head: 00fff00000000040 ffff88801bafa500 dead000000000122 0000000000000000
+  head: 0000000000000000 0000000080040004 00000001f5000000 0000000000000000
+  head: 00fff00000000003 ffffea00009caa01 ffffffffffffffff 0000000000000000
+  head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
+  page dumped because: kasan: bad access detected
+  page_owner tracks the page as allocated
+  page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 2, tgid 2 (kthreadd), ts 71247381401, free_ts 71214998153
+   set_page_owner include/linux/page_owner.h:32 [inline]
+   post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537
+   prep_new_page mm/page_alloc.c:1545 [inline]
+   get_page_from_freelist+0x3039/0x3180 mm/page_alloc.c:3457
+   __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4733
+   alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265
+   alloc_slab_page+0x6a/0x120 mm/slub.c:2413
+   allocate_slab+0x5a/0x2f0 mm/slub.c:2579
+   new_slab mm/slub.c:2632 [inline]
+   ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3819
+   __slab_alloc+0x58/0xa0 mm/slub.c:3909
+   __slab_alloc_node mm/slub.c:3962 [inline]
+   slab_alloc_node mm/slub.c:4123 [inline]
+   kmem_cache_alloc_node_noprof+0x1fe/0x320 mm/slub.c:4187
+   alloc_task_struct_node kernel/fork.c:180 [inline]
+   dup_task_struct+0x57/0x8c0 kernel/fork.c:1107
+   copy_process+0x5d1/0x3d50 kernel/fork.c:2206
+   kernel_clone+0x223/0x880 kernel/fork.c:2787
+   kernel_thread+0x1bc/0x240 kernel/fork.c:2849
+   create_kthread kernel/kthread.c:412 [inline]
+   kthreadd+0x60d/0x810 kernel/kthread.c:765
+   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
+   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
+  page last free pid 5230 tgid 5230 stack trace:
+   reset_page_owner include/linux/page_owner.h:25 [inline]
+   free_pages_prepare mm/page_alloc.c:1108 [inline]
+   free_unref_page+0xcd0/0xf00 mm/page_alloc.c:2638
+   discard_slab mm/slub.c:2678 [inline]
+   __put_partials+0xeb/0x130 mm/slub.c:3146
+   put_cpu_partial+0x17c/0x250 mm/slub.c:3221
+   __slab_free+0x2ea/0x3d0 mm/slub.c:4450
+   qlink_free mm/kasan/quarantine.c:163 [inline]
+   qlist_free_all+0x9a/0x140 mm/kasan/quarantine.c:179
+   kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286
+   __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:329
+   kasan_slab_alloc include/linux/kasan.h:247 [inline]
+   slab_post_alloc_hook mm/slub.c:4086 [inline]
+   slab_alloc_node mm/slub.c:4135 [inline]
+   kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4142
+   getname_flags+0xb7/0x540 fs/namei.c:139
+   do_sys_openat2+0xd2/0x1d0 fs/open.c:1409
+   do_sys_open fs/open.c:1430 [inline]
+   __do_sys_openat fs/open.c:1446 [inline]
+   __se_sys_openat fs/open.c:1441 [inline]
+   __x64_sys_openat+0x247/0x2a0 fs/open.c:1441
+   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
+   entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+  Memory state around the buggy address:
+   ffff8880272a8900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+   ffff8880272a8980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+  >ffff8880272a8a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+                              ^
+   ffff8880272a8a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+   ffff8880272a8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
+  ==================================================================
+
+Reported-by: syzbot+8aaf2df2ef0164ffe1fb@syzkaller.appspotmail.com
+Link: https://lore.kernel.org/linux-btrfs/66fb36b1.050a0220.aab67.003b.GAE@google.com/
+CC: stable@vger.kernel.org # 4.19+
+Reviewed-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.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/disk-io.c |   11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/fs/btrfs/disk-io.c
++++ b/fs/btrfs/disk-io.c
+@@ -4642,6 +4642,17 @@ void __cold close_ctree(struct btrfs_fs_
+       btrfs_cleanup_defrag_inodes(fs_info);
+       /*
++       * Wait for any fixup workers to complete.
++       * If we don't wait for them here and they are still running by the time
++       * we call kthread_stop() against the cleaner kthread further below, we
++       * get an use-after-free on the cleaner because the fixup worker adds an
++       * inode to the list of delayed iputs and then attempts to wakeup the
++       * cleaner kthread, which was already stopped and destroyed. We parked
++       * already the cleaner, but below we run all pending delayed iputs.
++       */
++      btrfs_flush_workqueue(fs_info->fixup_workers);
++
++      /*
+        * After we parked the cleaner kthread, ordered extents may have
+        * completed and created new delayed iputs. If one of the async reclaim
+        * tasks is running and in the RUN_DELAYED_IPUTS flush state, then we
diff --git a/queue-6.1/ceph-fix-cap-ref-leak-via-netfs-init_request.patch b/queue-6.1/ceph-fix-cap-ref-leak-via-netfs-init_request.patch
new file mode 100644 (file)
index 0000000..fb9fa5c
--- /dev/null
@@ -0,0 +1,58 @@
+From ccda9910d8490f4fb067131598e4b2e986faa5a0 Mon Sep 17 00:00:00 2001
+From: Patrick Donnelly <pdonnell@redhat.com>
+Date: Wed, 2 Oct 2024 21:05:12 -0400
+Subject: ceph: fix cap ref leak via netfs init_request
+
+From: Patrick Donnelly <pdonnell@redhat.com>
+
+commit ccda9910d8490f4fb067131598e4b2e986faa5a0 upstream.
+
+Log recovered from a user's cluster:
+
+    <7>[ 5413.970692] ceph:  get_cap_refs 00000000958c114b ret 1 got Fr
+    <7>[ 5413.970695] ceph:  start_read 00000000958c114b, no cache cap
+    ...
+    <7>[ 5473.934609] ceph:   my wanted = Fr, used = Fr, dirty -
+    <7>[ 5473.934616] ceph:  revocation: pAsLsXsFr -> pAsLsXs (revoking Fr)
+    <7>[ 5473.934632] ceph:  __ceph_caps_issued 00000000958c114b cap 00000000f7784259 issued pAsLsXs
+    <7>[ 5473.934638] ceph:  check_caps 10000000e68.fffffffffffffffe file_want - used Fr dirty - flushing - issued pAsLsXs revoking Fr retain pAsLsXsFsr  AUTHONLY NOINVAL FLUSH_FORCE
+
+The MDS subsequently complains that the kernel client is late releasing
+caps.
+
+Approximately, a series of changes to this code by commits 49870056005c
+("ceph: convert ceph_readpages to ceph_readahead"), 2de160417315
+("netfs: Change ->init_request() to return an error code") and
+a5c9dc445139 ("ceph: Make ceph_init_request() check caps on readahead")
+resulted in subtle resource cleanup to be missed. The main culprit is
+the change in error handling in 2de160417315 which meant that a failure
+in init_request() would no longer cause cleanup to be called. That
+would prevent the ceph_put_cap_refs() call which would cleanup the
+leaked cap ref.
+
+Cc: stable@vger.kernel.org
+Fixes: a5c9dc445139 ("ceph: Make ceph_init_request() check caps on readahead")
+Link: https://tracker.ceph.com/issues/67008
+Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/addr.c |    5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/fs/ceph/addr.c
++++ b/fs/ceph/addr.c
+@@ -435,8 +435,11 @@ static int ceph_init_request(struct netf
+       rreq->netfs_priv = priv;
+ out:
+-      if (ret < 0)
++      if (ret < 0) {
++              if (got)
++                      ceph_put_cap_refs(ceph_inode(inode), got);
+               kfree(priv);
++      }
+       return ret;
+ }
diff --git a/queue-6.1/gpio-davinci-fix-lazy-disable.patch b/queue-6.1/gpio-davinci-fix-lazy-disable.patch
new file mode 100644 (file)
index 0000000..662fbfd
--- /dev/null
@@ -0,0 +1,61 @@
+From 3360d41f4ac490282fddc3ccc0b58679aa5c065d Mon Sep 17 00:00:00 2001
+From: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
+Date: Wed, 28 Aug 2024 15:32:07 +0200
+Subject: gpio: davinci: fix lazy disable
+
+From: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
+
+commit 3360d41f4ac490282fddc3ccc0b58679aa5c065d upstream.
+
+On a few platforms such as TI's AM69 device, disable_irq() fails to keep
+track of the interrupts that happen between disable_irq() and
+enable_irq() and those interrupts are missed. Use the ->irq_unmask() and
+->irq_mask() methods instead of ->irq_enable() and ->irq_disable() to
+correctly keep track of edges when disable_irq is called.
+
+This solves the issue of disable_irq() not working as expected on such
+platforms.
+
+Fixes: 23265442b02b ("ARM: davinci: irq_data conversion.")
+Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
+Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
+Acked-by: Keerthy <j-keerthy@ti.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240828133207.493961-1-parth105105@gmail.com
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpio/gpio-davinci.c |    8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpio/gpio-davinci.c
++++ b/drivers/gpio/gpio-davinci.c
+@@ -295,7 +295,7 @@ static int davinci_gpio_probe(struct pla
+  * serve as EDMA event triggers.
+  */
+-static void gpio_irq_disable(struct irq_data *d)
++static void gpio_irq_mask(struct irq_data *d)
+ {
+       struct davinci_gpio_regs __iomem *g = irq2regs(d);
+       uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d);
+@@ -304,7 +304,7 @@ static void gpio_irq_disable(struct irq_
+       writel_relaxed(mask, &g->clr_rising);
+ }
+-static void gpio_irq_enable(struct irq_data *d)
++static void gpio_irq_unmask(struct irq_data *d)
+ {
+       struct davinci_gpio_regs __iomem *g = irq2regs(d);
+       uintptr_t mask = (uintptr_t)irq_data_get_irq_handler_data(d);
+@@ -330,8 +330,8 @@ static int gpio_irq_type(struct irq_data
+ static struct irq_chip gpio_irqchip = {
+       .name           = "GPIO",
+-      .irq_enable     = gpio_irq_enable,
+-      .irq_disable    = gpio_irq_disable,
++      .irq_unmask     = gpio_irq_unmask,
++      .irq_mask       = gpio_irq_mask,
+       .irq_set_type   = gpio_irq_type,
+       .flags          = IRQCHIP_SET_TYPE_MASKED | IRQCHIP_SKIP_SET_WAKE,
+ };
index f22b759d8820687bf181f8d77ab0e5795eada96f..5286247ee55c191949db5d3db09b2069db5bfc36 100644 (file)
@@ -603,3 +603,13 @@ rtc-at91sam9-fix-of-node-leak-in-probe-error-path.patch
 input-adp5589-keys-fix-null-pointer-dereference.patch
 input-adp5589-keys-fix-adp5589_gpio_get_value.patch
 cachefiles-fix-dentry-leak-in-cachefiles_open_file.patch
+acpi-resource-add-asus-vivobook-x1704vap-to-irq1_level_low_skip_override.patch
+acpi-resource-add-asus-expertbook-b2502cva-to-irq1_level_low_skip_override.patch
+btrfs-fix-a-null-pointer-dereference-when-failed-to-start-a-new-trasacntion.patch
+btrfs-send-fix-invalid-clone-operation-for-file-that-got-its-size-decreased.patch
+btrfs-wait-for-fixup-workers-before-stopping-cleaner-kthread-during-umount.patch
+gpio-davinci-fix-lazy-disable.patch
+bluetooth-hci_event-align-br-edr-just_works-paring-with-le.patch
+ceph-fix-cap-ref-leak-via-netfs-init_request.patch
+tracing-hwlat-fix-a-race-during-cpuhp-processing.patch
+tracing-timerlat-fix-a-race-during-cpuhp-processing.patch
diff --git a/queue-6.1/tracing-hwlat-fix-a-race-during-cpuhp-processing.patch b/queue-6.1/tracing-hwlat-fix-a-race-during-cpuhp-processing.patch
new file mode 100644 (file)
index 0000000..5804bcc
--- /dev/null
@@ -0,0 +1,46 @@
+From 2a13ca2e8abb12ee43ada8a107dadca83f140937 Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Tue, 24 Sep 2024 17:45:14 +0800
+Subject: tracing/hwlat: Fix a race during cpuhp processing
+
+From: Wei Li <liwei391@huawei.com>
+
+commit 2a13ca2e8abb12ee43ada8a107dadca83f140937 upstream.
+
+The cpuhp online/offline processing race also exists in percpu-mode hwlat
+tracer in theory, apply the fix too. That is:
+
+    T1                       | T2
+    [CPUHP_ONLINE]           | cpu_device_down()
+     hwlat_hotplug_workfn()  |
+                             |     cpus_write_lock()
+                             |     takedown_cpu(1)
+                             |     cpus_write_unlock()
+    [CPUHP_OFFLINE]          |
+        cpus_read_lock()     |
+        start_kthread(1)     |
+        cpus_read_unlock()   |
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Link: https://lore.kernel.org/20240924094515.3561410-5-liwei391@huawei.com
+Fixes: ba998f7d9531 ("trace/hwlat: Support hotplug operations")
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_hwlat.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/trace/trace_hwlat.c
++++ b/kernel/trace/trace_hwlat.c
+@@ -520,6 +520,8 @@ static void hwlat_hotplug_workfn(struct
+       if (!hwlat_busy || hwlat_data.thread_mode != MODE_PER_CPU)
+               goto out_unlock;
++      if (!cpu_online(cpu))
++              goto out_unlock;
+       if (!cpumask_test_cpu(cpu, tr->tracing_cpumask))
+               goto out_unlock;
diff --git a/queue-6.1/tracing-timerlat-fix-a-race-during-cpuhp-processing.patch b/queue-6.1/tracing-timerlat-fix-a-race-during-cpuhp-processing.patch
new file mode 100644 (file)
index 0000000..0044447
--- /dev/null
@@ -0,0 +1,88 @@
+From 829e0c9f0855f26b3ae830d17b24aec103f7e915 Mon Sep 17 00:00:00 2001
+From: Wei Li <liwei391@huawei.com>
+Date: Tue, 24 Sep 2024 17:45:13 +0800
+Subject: tracing/timerlat: Fix a race during cpuhp processing
+
+From: Wei Li <liwei391@huawei.com>
+
+commit 829e0c9f0855f26b3ae830d17b24aec103f7e915 upstream.
+
+There is another found exception that the "timerlat/1" thread was
+scheduled on CPU0, and lead to timer corruption finally:
+
+```
+ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220
+WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0
+Modules linked in:
+CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
+RIP: 0010:debug_print_object+0x7d/0xb0
+...
+Call Trace:
+ <TASK>
+ ? __warn+0x7c/0x110
+ ? debug_print_object+0x7d/0xb0
+ ? report_bug+0xf1/0x1d0
+ ? prb_read_valid+0x17/0x20
+ ? handle_bug+0x3f/0x70
+ ? exc_invalid_op+0x13/0x60
+ ? asm_exc_invalid_op+0x16/0x20
+ ? debug_print_object+0x7d/0xb0
+ ? debug_print_object+0x7d/0xb0
+ ? __pfx_timerlat_irq+0x10/0x10
+ __debug_object_init+0x110/0x150
+ hrtimer_init+0x1d/0x60
+ timerlat_main+0xab/0x2d0
+ ? __pfx_timerlat_main+0x10/0x10
+ kthread+0xb7/0xe0
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork+0x2d/0x40
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork_asm+0x1a/0x30
+ </TASK>
+```
+
+After tracing the scheduling event, it was discovered that the migration
+of the "timerlat/1" thread was performed during thread creation. Further
+analysis confirmed that it is because the CPU online processing for
+osnoise is implemented through workers, which is asynchronous with the
+offline processing. When the worker was scheduled to create a thread, the
+CPU may has already been removed from the cpu_online_mask during the offline
+process, resulting in the inability to select the right CPU:
+
+T1                       | T2
+[CPUHP_ONLINE]           | cpu_device_down()
+osnoise_hotplug_workfn() |
+                         |     cpus_write_lock()
+                         |     takedown_cpu(1)
+                         |     cpus_write_unlock()
+[CPUHP_OFFLINE]          |
+    cpus_read_lock()     |
+    start_kthread(1)     |
+    cpus_read_unlock()   |
+
+To fix this, skip online processing if the CPU is already offline.
+
+Cc: stable@vger.kernel.org
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Link: https://lore.kernel.org/20240924094515.3561410-4-liwei391@huawei.com
+Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations")
+Signed-off-by: Wei Li <liwei391@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_osnoise.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/trace/trace_osnoise.c
++++ b/kernel/trace/trace_osnoise.c
+@@ -1813,6 +1813,8 @@ static void osnoise_hotplug_workfn(struc
+       mutex_lock(&interface_lock);
+       cpus_read_lock();
++      if (!cpu_online(cpu))
++              goto out_unlock;
+       if (!cpumask_test_cpu(cpu, &osnoise_cpumask))
+               goto out_unlock;