--- /dev/null
+From stable+bounces-120016-greg=kroah.com@vger.kernel.org Sun Mar 2 13:47:38 2025
+From: fdmanana@kernel.org
+Date: Sun, 2 Mar 2025 12:47:27 +0000
+Subject: btrfs: bring back the incorrectly removed extent buffer lock recursion support
+To: linux-btrfs@vger.kernel.org
+Cc: pkoroau@gmail.com, dsterba@suse.com, stable@vger.kernel.org
+Message-ID: <10637efdde5420993dd0611e3d3d5d8de6937e3b.1740919455.git.fdmanana@suse.com>
+
+From: Filipe Manana <fdmanana@suse.com>
+
+Commit 51b03b7473a0 ("btrfs: locking: remove the recursion handling code")
+from the 5.10.233 stable tree removed the support for extent buffer lock
+recursion, but we need that code because in 5.10.x we load the free space
+cache synchronously - while modifying the extent tree and holding a write
+lock on some extent buffer, we may need to load the free space cache,
+which requires acquiring read locks on the extent tree and therefore
+result in a deadlock in case we need to read lock an extent buffer we had
+write locked while modifying the extent tree.
+
+Backporting that commit from Linus' tree is therefore wrong, and was done
+so in order to backport upstream commit 97e86631bccd ("btrfs: don't set
+lock_owner when locking extent buffer for reading"). However we should
+have instead had the commit adapted to the 5.10 stable tree instead.
+
+Note that the backport of that dependency is ok only for stable trees
+5.11+, because in those tree the space cache loading code is not
+synchronous anymore, so there is no need to have the lock recursion
+and indeed there are no users of the extent buffer lock recursion
+support. In other words, the backport is only valid for kernel releases
+that have the asynchrounous free space cache loading support, which
+was introduced in kernel 5.11 with commit e747853cae3a ("btrfs: load
+free space cache asynchronously").
+
+This was causing deadlocks and reported by a user (see below Link tag).
+
+So revert commit 51b03b7473a0 ("btrfs: locking: remove the recursion
+handling code") while not undoing what commit d5a30a6117ea ("btrfs: don't
+set lock_owner when locking extent buffer for reading") from the 5.10.x
+stable tree did.
+
+Reported-by: pk <pkoroau@gmail.com>
+Link: https://lore.kernel.org/linux-btrfs/CAMNwjEKH6znTHE5hMc5er2dFs5ypw4Szx6TMDMb0H76yFq5DGQ@mail.gmail.com/
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/btrfs/locking.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++----
+ 1 file changed, 64 insertions(+), 4 deletions(-)
+
+--- a/fs/btrfs/locking.c
++++ b/fs/btrfs/locking.c
+@@ -25,18 +25,43 @@
+ * - reader/reader sharing
+ * - try-lock semantics for readers and writers
+ *
+- * The rwsem implementation does opportunistic spinning which reduces number of
+- * times the locking task needs to sleep.
++ * Additionally we need one level nesting recursion, see below. The rwsem
++ * implementation does opportunistic spinning which reduces number of times the
++ * locking task needs to sleep.
++ *
++ *
++ * Lock recursion
++ * --------------
++ *
++ * A write operation on a tree might indirectly start a look up on the same
++ * tree. This can happen when btrfs_cow_block locks the tree and needs to
++ * lookup free extents.
++ *
++ * btrfs_cow_block
++ * ..
++ * alloc_tree_block_no_bg_flush
++ * btrfs_alloc_tree_block
++ * btrfs_reserve_extent
++ * ..
++ * load_free_space_cache
++ * ..
++ * btrfs_lookup_file_extent
++ * btrfs_search_slot
++ *
+ */
+
+ /*
+ * __btrfs_tree_read_lock - lock extent buffer for read
+ * @eb: the eb to be locked
+ * @nest: the nesting level to be used for lockdep
+- * @recurse: unused
++ * @recurse: if this lock is able to be recursed
+ *
+ * This takes the read lock on the extent buffer, using the specified nesting
+ * level for lockdep purposes.
++ *
++ * If you specify recurse = true, then we will allow this to be taken if we
++ * currently own the lock already. This should only be used in specific
++ * usecases, and the subsequent unlock will not change the state of the lock.
+ */
+ void __btrfs_tree_read_lock(struct extent_buffer *eb, enum btrfs_lock_nesting nest,
+ bool recurse)
+@@ -46,7 +71,31 @@ void __btrfs_tree_read_lock(struct exten
+ if (trace_btrfs_tree_read_lock_enabled())
+ start_ns = ktime_get_ns();
+
++ if (unlikely(recurse)) {
++ /* First see if we can grab the lock outright */
++ if (down_read_trylock(&eb->lock))
++ goto out;
++
++ /*
++ * Ok still doesn't necessarily mean we are already holding the
++ * lock, check the owner.
++ */
++ if (eb->lock_owner != current->pid) {
++ down_read_nested(&eb->lock, nest);
++ goto out;
++ }
++
++ /*
++ * Ok we have actually recursed, but we should only be recursing
++ * once, so blow up if we're already recursed, otherwise set
++ * ->lock_recursed and carry on.
++ */
++ BUG_ON(eb->lock_recursed);
++ eb->lock_recursed = true;
++ goto out;
++ }
+ down_read_nested(&eb->lock, nest);
++out:
+ trace_btrfs_tree_read_lock(eb, start_ns);
+ }
+
+@@ -85,11 +134,22 @@ int btrfs_try_tree_write_lock(struct ext
+ }
+
+ /*
+- * Release read lock.
++ * Release read lock. If the read lock was recursed then the lock stays in the
++ * original state that it was before it was recursively locked.
+ */
+ void btrfs_tree_read_unlock(struct extent_buffer *eb)
+ {
+ trace_btrfs_tree_read_unlock(eb);
++ /*
++ * if we're nested, we have the write lock. No new locking
++ * is needed as long as we are the lock owner.
++ * The write unlock will do a barrier for us, and the lock_recursed
++ * field only matters to the lock owner.
++ */
++ if (eb->lock_recursed && current->pid == eb->lock_owner) {
++ eb->lock_recursed = false;
++ return;
++ }
+ up_read(&eb->lock);
+ }
+
--- /dev/null
+From stable+bounces-119388-greg=kroah.com@vger.kernel.org Mon Feb 24 17:20:13 2025
+From: Ben Hutchings <benh@debian.org>
+Date: Mon, 24 Feb 2025 16:57:20 +0100
+Subject: perf cs-etm: Add missing variable in cs_etm__process_queues()
+To: stable@vger.kernel.org
+Cc: James Clark <james.clark@linaro.org>
+Message-ID: <Z7yW4FuPxoZyl7Ga@decadent.org.uk>
+Content-Disposition: inline
+
+From: Ben Hutchings <benh@debian.org>
+
+Commit 5afd032961e8 "perf cs-etm: Don't flush when packet_queue fills
+up" uses i as a loop counter in cs_etm__process_queues(). It was
+backported to the 5.4 and 5.10 stable branches, but the i variable
+doesn't exist there as it was only added in 5.15.
+
+Declare i with the expected type.
+
+Fixes: 1ed167325c32 ("perf cs-etm: Don't flush when packet_queue fills up")
+Fixes: 26db806fa23e ("perf cs-etm: Don't flush when packet_queue fills up")
+Signed-off-by: Ben Hutchings <benh@debian.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/perf/util/cs-etm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/tools/perf/util/cs-etm.c
++++ b/tools/perf/util/cs-etm.c
+@@ -2171,7 +2171,7 @@ static int cs_etm__process_timeless_queu
+ static int cs_etm__process_queues(struct cs_etm_auxtrace *etm)
+ {
+ int ret = 0;
+- unsigned int cs_queue_nr, queue_nr;
++ unsigned int cs_queue_nr, queue_nr, i;
+ u8 trace_chan_id;
+ u64 timestamp;
+ struct auxtrace_queue *queue;
sched-sch_cake-add-bounds-checks-to-host-bulk-flow-fairness-counts.patch
kbuild-userprogs-use-correct-lld-when-linking-through-clang.patch
crypto-hisilicon-qm-inject-error-before-stopping-queue.patch
+btrfs-bring-back-the-incorrectly-removed-extent-buffer-lock-recursion-support.patch
+usb-xhci-enable-the-trb-overfetch-quirk-on-via-vl805.patch
+perf-cs-etm-add-missing-variable-in-cs_etm__process_queues.patch
+udf-fix-use-of-check_add_overflow-with-mixed-type-arguments.patch
--- /dev/null
+From stable+bounces-119387-greg=kroah.com@vger.kernel.org Mon Feb 24 17:02:42 2025
+From: Ben Hutchings <benh@debian.org>
+Date: Mon, 24 Feb 2025 17:00:27 +0100
+Subject: udf: Fix use of check_add_overflow() with mixed type arguments
+To: stable@vger.kernel.org
+Cc: Jan Kara <jack@suse.cz>
+Message-ID: <Z7yXm_Vo1Y0Gjx_X@decadent.org.uk>
+Content-Disposition: inline
+
+From: Ben Hutchings <benh@debian.org>
+
+Commit ebbe26fd54a9 "udf: Avoid excessive partition lengths"
+introduced a use of check_add_overflow() with argument types u32,
+size_t, and u32 *.
+
+This was backported to the 5.x stable branches, where in 64-bit
+configurations it results in a build error (with older compilers) or a
+warning. Before commit d219d2a9a92e "overflow: Allow mixed type
+arguments", which went into Linux 6.1, mixed type arguments are not
+supported. That cannot be backported to 5.4 or 5.10 as it would raise
+the minimum compiler version for these kernel versions.
+
+Add a cast to make the argument types compatible.
+
+Fixes: 1497a4484cdb ("udf: Avoid excessive partition lengths")
+Fixes: 551966371e17 ("udf: Avoid excessive partition lengths")
+Signed-off-by: Ben Hutchings <benh@debian.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/udf/super.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/udf/super.c
++++ b/fs/udf/super.c
+@@ -1153,7 +1153,7 @@ static int udf_fill_partdesc_info(struct
+ map->s_partition_flags |= UDF_PART_FLAG_UNALLOC_BITMAP;
+ /* Check whether math over bitmap won't overflow. */
+ if (check_add_overflow(map->s_partition_len,
+- sizeof(struct spaceBitmapDesc) << 3,
++ (u32)(sizeof(struct spaceBitmapDesc) << 3),
+ &sum)) {
+ udf_err(sb, "Partition %d is too long (%u)\n", p_index,
+ map->s_partition_len);
--- /dev/null
+From c133ec0e5717868c9967fa3df92a55e537b1aead Mon Sep 17 00:00:00 2001
+From: Michal Pecio <michal.pecio@gmail.com>
+Date: Tue, 25 Feb 2025 11:59:27 +0200
+Subject: usb: xhci: Enable the TRB overfetch quirk on VIA VL805
+
+From: Michal Pecio <michal.pecio@gmail.com>
+
+commit c133ec0e5717868c9967fa3df92a55e537b1aead upstream.
+
+Raspberry Pi is a major user of those chips and they discovered a bug -
+when the end of a transfer ring segment is reached, up to four TRBs can
+be prefetched from the next page even if the segment ends with link TRB
+and on page boundary (the chip claims to support standard 4KB pages).
+
+It also appears that if the prefetched TRBs belong to a different ring
+whose doorbell is later rung, they may be used without refreshing from
+system RAM and the endpoint will stay idle if their cycle bit is stale.
+
+Other users complain about IOMMU faults on x86 systems, unsurprisingly.
+
+Deal with it by using existing quirk which allocates a dummy page after
+each transfer ring segment. This was seen to resolve both problems. RPi
+came up with a more efficient solution, shortening each segment by four
+TRBs, but it complicated the driver and they ditched it for this quirk.
+
+Also rename the quirk and add VL805 device ID macro.
+
+Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
+Link: https://github.com/raspberrypi/linux/issues/4685
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=215906
+CC: stable@vger.kernel.org
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20250225095927.2512358-2-mathias.nyman@linux.intel.com
+[ Michal: merge conflict with white space and an unrelated quirk ]
+Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mem.c | 3 ++-
+ drivers/usb/host/xhci-pci.c | 9 ++++++---
+ drivers/usb/host/xhci.h | 2 +-
+ 3 files changed, 9 insertions(+), 5 deletions(-)
+
+--- a/drivers/usb/host/xhci-mem.c
++++ b/drivers/usb/host/xhci-mem.c
+@@ -2494,7 +2494,8 @@ int xhci_mem_init(struct xhci_hcd *xhci,
+ * and our use of dma addresses in the trb_address_map radix tree needs
+ * TRB_SEGMENT_SIZE alignment, so we pick the greater alignment need.
+ */
+- if (xhci->quirks & XHCI_ZHAOXIN_TRB_FETCH)
++ if (xhci->quirks & XHCI_TRB_OVERFETCH)
++ /* Buggy HC prefetches beyond segment bounds - allocate dummy space at the end */
+ xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
+ TRB_SEGMENT_SIZE * 2, TRB_SEGMENT_SIZE * 2, xhci->page_size * 2);
+ else
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -37,6 +37,8 @@
+ #define PCI_DEVICE_ID_EJ168 0x7023
+ #define PCI_DEVICE_ID_EJ188 0x7052
+
++#define PCI_DEVICE_ID_VIA_VL805 0x3483
++
+ #define PCI_DEVICE_ID_INTEL_LYNXPOINT_XHCI 0x8c31
+ #define PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI 0x9c31
+ #define PCI_DEVICE_ID_INTEL_WILDCATPOINT_LP_XHCI 0x9cb1
+@@ -296,8 +298,9 @@ static void xhci_pci_quirks(struct devic
+ pdev->device == 0x3432)
+ xhci->quirks |= XHCI_BROKEN_STREAMS;
+
+- if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == 0x3483) {
++ if (pdev->vendor == PCI_VENDOR_ID_VIA && pdev->device == PCI_DEVICE_ID_VIA_VL805) {
+ xhci->quirks |= XHCI_LPM_SUPPORT;
++ xhci->quirks |= XHCI_TRB_OVERFETCH;
+ xhci->quirks |= XHCI_EP_CTX_BROKEN_DCS;
+ }
+
+@@ -347,11 +350,11 @@ static void xhci_pci_quirks(struct devic
+
+ if (pdev->device == 0x9202) {
+ xhci->quirks |= XHCI_RESET_ON_RESUME;
+- xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH;
++ xhci->quirks |= XHCI_TRB_OVERFETCH;
+ }
+
+ if (pdev->device == 0x9203)
+- xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH;
++ xhci->quirks |= XHCI_TRB_OVERFETCH;
+ }
+
+ /* xHC spec requires PCI devices to support D3hot and D3cold */
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1902,7 +1902,7 @@ struct xhci_hcd {
+ #define XHCI_EP_CTX_BROKEN_DCS BIT_ULL(42)
+ #define XHCI_SUSPEND_RESUME_CLKS BIT_ULL(43)
+ #define XHCI_RESET_TO_DEFAULT BIT_ULL(44)
+-#define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45)
++#define XHCI_TRB_OVERFETCH BIT_ULL(45)
+ #define XHCI_ZHAOXIN_HOST BIT_ULL(46)
+
+ unsigned int num_active_eps;
projects / thirdparty / kernel / stable-queue.git / commitdiff
