From: Greg Kroah-Hartman Date: Fri, 19 Apr 2024 10:43:35 +0000 (+0200) Subject: 6.8-stable patches X-Git-Tag: v5.15.157~75 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8d6f3610eb600ddb9fe92e5de12ccf4587e1d4f9;p=thirdparty%2Fkernel%2Fstable-queue.git 6.8-stable patches added patches: btrfs-do-not-wait-for-short-bulk-allocation.patch btrfs-zoned-do-not-flag-zeroout-on-non-dirty-extent-buffer.patch net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch random-handle-creditable-entropy-from-atomic-process-context.patch revert-vmgenid-emit-uevent-when-vmgenid-updates.patch scsi-core-fix-handling-of-scmd_fail_if_recovering.patch selftests-ftrace-limit-length-in-subsystem-enable-tests.patch sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch --- diff --git a/queue-6.8/btrfs-do-not-wait-for-short-bulk-allocation.patch b/queue-6.8/btrfs-do-not-wait-for-short-bulk-allocation.patch new file mode 100644 index 00000000000..602cc1a5373 --- /dev/null +++ b/queue-6.8/btrfs-do-not-wait-for-short-bulk-allocation.patch @@ -0,0 +1,98 @@ +From 1db7959aacd905e6487d0478ac01d89f86eb1e51 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Tue, 26 Mar 2024 09:16:46 +1030 +Subject: btrfs: do not wait for short bulk allocation + +From: Qu Wenruo + +commit 1db7959aacd905e6487d0478ac01d89f86eb1e51 upstream. + +[BUG] +There is a recent report that when memory pressure is high (including +cached pages), btrfs can spend most of its time on memory allocation in +btrfs_alloc_page_array() for compressed read/write. + +[CAUSE] +For btrfs_alloc_page_array() we always go alloc_pages_bulk_array(), and +even if the bulk allocation failed (fell back to single page +allocation) we still retry but with extra memalloc_retry_wait(). + +If the bulk alloc only returned one page a time, we would spend a lot of +time on the retry wait. + +The behavior was introduced in commit 395cb57e8560 ("btrfs: wait between +incomplete batch memory allocations"). + +[FIX] +Although the commit mentioned that other filesystems do the wait, it's +not the case at least nowadays. + +All the mainlined filesystems only call memalloc_retry_wait() if they +failed to allocate any page (not only for bulk allocation). +If there is any progress, they won't call memalloc_retry_wait() at all. + +For example, xfs_buf_alloc_pages() would only call memalloc_retry_wait() +if there is no allocation progress at all, and the call is not for +metadata readahead. + +So I don't believe we should call memalloc_retry_wait() unconditionally +for short allocation. + +Call memalloc_retry_wait() if it fails to allocate any page for tree +block allocation (which goes with __GFP_NOFAIL and may not need the +special handling anyway), and reduce the latency for +btrfs_alloc_page_array(). + +Reported-by: Julian Taylor +Tested-by: Julian Taylor +Link: https://lore.kernel.org/all/8966c095-cbe7-4d22-9784-a647d1bf27c3@1und1.de/ +Fixes: 395cb57e8560 ("btrfs: wait between incomplete batch memory allocations") +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Sweet Tea Dorminy +Reviewed-by: Filipe Manana +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent_io.c | 18 ++++-------------- + 1 file changed, 4 insertions(+), 14 deletions(-) + +--- a/fs/btrfs/extent_io.c ++++ b/fs/btrfs/extent_io.c +@@ -692,31 +692,21 @@ static void end_bbio_data_read(struct bt + int btrfs_alloc_page_array(unsigned int nr_pages, struct page **page_array, + gfp_t extra_gfp) + { ++ const gfp_t gfp = GFP_NOFS | extra_gfp; + unsigned int allocated; + + for (allocated = 0; allocated < nr_pages;) { + unsigned int last = allocated; + +- allocated = alloc_pages_bulk_array(GFP_NOFS | extra_gfp, +- nr_pages, page_array); +- +- if (allocated == nr_pages) +- return 0; +- +- /* +- * During this iteration, no page could be allocated, even +- * though alloc_pages_bulk_array() falls back to alloc_page() +- * if it could not bulk-allocate. So we must be out of memory. +- */ +- if (allocated == last) { ++ allocated = alloc_pages_bulk_array(gfp, nr_pages, page_array); ++ if (unlikely(allocated == last)) { ++ /* No progress, fail and do cleanup. */ + for (int i = 0; i < allocated; i++) { + __free_page(page_array[i]); + page_array[i] = NULL; + } + return -ENOMEM; + } +- +- memalloc_retry_wait(GFP_NOFS); + } + return 0; + } diff --git a/queue-6.8/btrfs-zoned-do-not-flag-zeroout-on-non-dirty-extent-buffer.patch b/queue-6.8/btrfs-zoned-do-not-flag-zeroout-on-non-dirty-extent-buffer.patch new file mode 100644 index 00000000000..645dd6efe9f --- /dev/null +++ b/queue-6.8/btrfs-zoned-do-not-flag-zeroout-on-non-dirty-extent-buffer.patch @@ -0,0 +1,62 @@ +From 68879386180c0efd5a11e800b0525a01068c9457 Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Tue, 26 Mar 2024 14:39:20 +0900 +Subject: btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer + +From: Naohiro Aota + +commit 68879386180c0efd5a11e800b0525a01068c9457 upstream. + +Btrfs clears the content of an extent buffer marked as +EXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is +introduced to prevent a write hole of an extent buffer, which is once +allocated, marked dirty, but turns out unnecessary and cleaned up within +one transaction operation. + +Currently, btrfs_clear_buffer_dirty() marks the extent buffer as +EXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call +happens while the buffer is under IO (with the WRITEBACK flag set, +without the DIRTY flag), we can add the ZEROOUT flag and clear the +buffer's content just before a bio submission. As a result: + +1) it can lead to adding faulty delayed reference item which leads to a + FS corrupted (EUCLEAN) error, and + +2) it writes out cleared tree node on disk + +The former issue is previously discussed in [1]. The corruption happens +when it runs a delayed reference update. So, on-disk data is safe. + +[1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/ + +The latter one can reach on-disk data. But, as that node is already +processed by btrfs_clear_buffer_dirty(), that will be invalidated in the +next transaction commit anyway. So, the chance of hitting the corruption +is relatively small. + +Anyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to +keep the content under IO intact. + +Fixes: aa6313e6ff2b ("btrfs: zoned: don't clear dirty flag of extent buffer") +CC: stable@vger.kernel.org # 6.8 +Link: https://lore.kernel.org/linux-btrfs/oadvdekkturysgfgi4qzuemd57zudeasynswurjxw3ocdfsef6@sjyufeugh63f/ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Naohiro Aota +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent_io.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/extent_io.c ++++ b/fs/btrfs/extent_io.c +@@ -4130,7 +4130,7 @@ void btrfs_clear_buffer_dirty(struct btr + * The actual zeroout of the buffer will happen later in + * btree_csum_one_bio. + */ +- if (btrfs_is_zoned(fs_info)) { ++ if (btrfs_is_zoned(fs_info) && test_bit(EXTENT_BUFFER_DIRTY, &eb->bflags)) { + set_bit(EXTENT_BUFFER_ZONED_ZEROOUT, &eb->bflags); + return; + } diff --git a/queue-6.8/net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch b/queue-6.8/net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch new file mode 100644 index 00000000000..f8cb7c900d6 --- /dev/null +++ b/queue-6.8/net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch @@ -0,0 +1,64 @@ +From 56f78615bcb1c3ba58a5d9911bad3d9185cf141b Mon Sep 17 00:00:00 2001 +From: Jose Ignacio Tornos Martinez +Date: Wed, 17 Apr 2024 10:55:13 +0200 +Subject: net: usb: ax88179_178a: avoid writing the mac address before first reading + +From: Jose Ignacio Tornos Martinez + +commit 56f78615bcb1c3ba58a5d9911bad3d9185cf141b upstream. + +After the commit d2689b6a86b9 ("net: usb: ax88179_178a: avoid two +consecutive device resets"), reset operation, in which the default mac +address from the device is read, is not executed from bind operation and +the random address, that is pregenerated just in case, is direclty written +the first time in the device, so the default one from the device is not +even read. This writing is not dangerous because is volatile and the +default mac address is not missed. + +In order to avoid this and keep the simplification to have only one +reset and reduce the delays, restore the reset from bind operation and +remove the reset that is commanded from open operation. The behavior is +the same but everything is ready for usbnet_probe. + +Tested with ASIX AX88179 USB Gigabit Ethernet devices. +Restore the old behavior for the rest of possible devices because I don't +have the hardware to test. + +cc: stable@vger.kernel.org # 6.6+ +Fixes: d2689b6a86b9 ("net: usb: ax88179_178a: avoid two consecutive device resets") +Reported-by: Jarkko Palviainen +Signed-off-by: Jose Ignacio Tornos Martinez +Link: https://lore.kernel.org/r/20240417085524.219532-1-jtornosm@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/ax88179_178a.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/usb/ax88179_178a.c ++++ b/drivers/net/usb/ax88179_178a.c +@@ -1317,6 +1317,8 @@ static int ax88179_bind(struct usbnet *d + + netif_set_tso_max_size(dev->net, 16384); + ++ ax88179_reset(dev); ++ + return 0; + } + +@@ -1695,7 +1697,6 @@ static const struct driver_info ax88179_ + .unbind = ax88179_unbind, + .status = ax88179_status, + .link_reset = ax88179_link_reset, +- .reset = ax88179_reset, + .stop = ax88179_stop, + .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .rx_fixup = ax88179_rx_fixup, +@@ -1708,7 +1709,6 @@ static const struct driver_info ax88178a + .unbind = ax88179_unbind, + .status = ax88179_status, + .link_reset = ax88179_link_reset, +- .reset = ax88179_reset, + .stop = ax88179_stop, + .flags = FLAG_ETHER | FLAG_FRAMING_AX, + .rx_fixup = ax88179_rx_fixup, diff --git a/queue-6.8/random-handle-creditable-entropy-from-atomic-process-context.patch b/queue-6.8/random-handle-creditable-entropy-from-atomic-process-context.patch new file mode 100644 index 00000000000..a6b6dadbcfd --- /dev/null +++ b/queue-6.8/random-handle-creditable-entropy-from-atomic-process-context.patch @@ -0,0 +1,94 @@ +From e871abcda3b67d0820b4182ebe93435624e9c6a4 Mon Sep 17 00:00:00 2001 +From: "Jason A. Donenfeld" +Date: Wed, 17 Apr 2024 13:38:29 +0200 +Subject: random: handle creditable entropy from atomic process context + +From: Jason A. Donenfeld + +commit e871abcda3b67d0820b4182ebe93435624e9c6a4 upstream. + +The entropy accounting changes a static key when the RNG has +initialized, since it only ever initializes once. Static key changes, +however, cannot be made from atomic context, so depending on where the +last creditable entropy comes from, the static key change might need to +be deferred to a worker. + +Previously the code used the execute_in_process_context() helper +function, which accounts for whether or not the caller is +in_interrupt(). However, that doesn't account for the case where the +caller is actually in process context but is holding a spinlock. + +This turned out to be the case with input_handle_event() in +drivers/input/input.c contributing entropy: + + [] die+0xa8/0x2fc + [] bug_handler+0x44/0xec + [] brk_handler+0x90/0x144 + [] do_debug_exception+0xa0/0x148 + [] el1_dbg+0x60/0x7c + [] el1h_64_sync_handler+0x38/0x90 + [] el1h_64_sync+0x64/0x6c + [] __might_resched+0x1fc/0x2e8 + [] __might_sleep+0x44/0x7c + [] cpus_read_lock+0x1c/0xec + [] static_key_enable+0x14/0x38 + [] crng_set_ready+0x14/0x28 + [] execute_in_process_context+0xb8/0xf8 + [] _credit_init_bits+0x118/0x1dc + [] add_timer_randomness+0x264/0x270 + [] add_input_randomness+0x38/0x48 + [] input_handle_event+0x2b8/0x490 + [] input_event+0x6c/0x98 + +According to Guoyong, it's not really possible to refactor the various +drivers to never hold a spinlock there. And in_atomic() isn't reliable. + +So, rather than trying to be too fancy, just punt the change in the +static key to a workqueue always. There's basically no drawback of doing +this, as the code already needed to account for the static key not +changing immediately, and given that it's just an optimization, there's +not exactly a hurry to change the static key right away, so deferal is +fine. + +Reported-by: Guoyong Wang +Cc: stable@vger.kernel.org +Fixes: f5bda35fba61 ("random: use static branch for crng_ready()") +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + drivers/char/random.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/char/random.c ++++ b/drivers/char/random.c +@@ -702,7 +702,7 @@ static void extract_entropy(void *buf, s + + static void __cold _credit_init_bits(size_t bits) + { +- static struct execute_work set_ready; ++ static DECLARE_WORK(set_ready, crng_set_ready); + unsigned int new, orig, add; + unsigned long flags; + +@@ -718,8 +718,8 @@ static void __cold _credit_init_bits(siz + + if (orig < POOL_READY_BITS && new >= POOL_READY_BITS) { + crng_reseed(NULL); /* Sets crng_init to CRNG_READY under base_crng.lock. */ +- if (static_key_initialized) +- execute_in_process_context(crng_set_ready, &set_ready); ++ if (static_key_initialized && system_unbound_wq) ++ queue_work(system_unbound_wq, &set_ready); + atomic_notifier_call_chain(&random_ready_notifier, 0, NULL); + wake_up_interruptible(&crng_init_wait); + kill_fasync(&fasync, SIGIO, POLL_IN); +@@ -890,8 +890,8 @@ void __init random_init(void) + + /* + * If we were initialized by the cpu or bootloader before jump labels +- * are initialized, then we should enable the static branch here, where +- * it's guaranteed that jump labels have been initialized. ++ * or workqueues are initialized, then we should enable the static ++ * branch here, where it's guaranteed that these have been initialized. + */ + if (!static_branch_likely(&crng_is_ready) && crng_init >= CRNG_READY) + crng_set_ready(NULL); diff --git a/queue-6.8/revert-vmgenid-emit-uevent-when-vmgenid-updates.patch b/queue-6.8/revert-vmgenid-emit-uevent-when-vmgenid-updates.patch new file mode 100644 index 00000000000..e769c749b17 --- /dev/null +++ b/queue-6.8/revert-vmgenid-emit-uevent-when-vmgenid-updates.patch @@ -0,0 +1,49 @@ +From 3aadf100f93d80815685493d60cd8cab206403df Mon Sep 17 00:00:00 2001 +From: "Jason A. Donenfeld" +Date: Thu, 18 Apr 2024 13:45:17 +0200 +Subject: Revert "vmgenid: emit uevent when VMGENID updates" + +From: Jason A. Donenfeld + +commit 3aadf100f93d80815685493d60cd8cab206403df upstream. + +This reverts commit ad6bcdad2b6724e113f191a12f859a9e8456b26d. I had +nak'd it, and Greg said on the thread that it links that he wasn't going +to take it either, especially since it's not his code or his tree, but +then, seemingly accidentally, it got pushed up some months later, in +what looks like a mistake, with no further discussion in the linked +thread. So revert it, since it's clearly not intended. + +Fixes: ad6bcdad2b67 ("vmgenid: emit uevent when VMGENID updates") +Cc: stable@vger.kernel.org +Acked-by: Greg Kroah-Hartman +Link: https://lore.kernel.org/r/20230531095119.11202-2-bchalios@amazon.es +Signed-off-by: Jason A. Donenfeld +Signed-off-by: Greg Kroah-Hartman +--- + drivers/virt/vmgenid.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c +index b67a28da4702..a1c467a0e9f7 100644 +--- a/drivers/virt/vmgenid.c ++++ b/drivers/virt/vmgenid.c +@@ -68,7 +68,6 @@ static int vmgenid_add(struct acpi_device *device) + static void vmgenid_notify(struct acpi_device *device, u32 event) + { + struct vmgenid_state *state = acpi_driver_data(device); +- char *envp[] = { "NEW_VMGENID=1", NULL }; + u8 old_id[VMGENID_SIZE]; + + memcpy(old_id, state->this_id, sizeof(old_id)); +@@ -76,7 +75,6 @@ static void vmgenid_notify(struct acpi_device *device, u32 event) + if (!memcmp(old_id, state->this_id, sizeof(old_id))) + return; + add_vmfork_randomness(state->this_id, sizeof(state->this_id)); +- kobject_uevent_env(&device->dev.kobj, KOBJ_CHANGE, envp); + } + + static const struct acpi_device_id vmgenid_ids[] = { +-- +2.44.0 + diff --git a/queue-6.8/scsi-core-fix-handling-of-scmd_fail_if_recovering.patch b/queue-6.8/scsi-core-fix-handling-of-scmd_fail_if_recovering.patch new file mode 100644 index 00000000000..e35a5fb2472 --- /dev/null +++ b/queue-6.8/scsi-core-fix-handling-of-scmd_fail_if_recovering.patch @@ -0,0 +1,40 @@ +From ca91259b775f6fd98ae5d23bb4eec101d468ba8d Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Mon, 25 Mar 2024 15:44:17 -0700 +Subject: scsi: core: Fix handling of SCMD_FAIL_IF_RECOVERING + +From: Bart Van Assche + +commit ca91259b775f6fd98ae5d23bb4eec101d468ba8d upstream. + +There is code in the SCSI core that sets the SCMD_FAIL_IF_RECOVERING +flag but there is no code that clears this flag. Instead of only clearing +SCMD_INITIALIZED in scsi_end_request(), clear all flags. It is never +necessary to preserve any command flags inside scsi_end_request(). + +Cc: stable@vger.kernel.org +Fixes: 310bcaef6d7e ("scsi: core: Support failing requests while recovering") +Signed-off-by: Bart Van Assche +Link: https://lore.kernel.org/r/20240325224417.1477135-1-bvanassche@acm.org +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/scsi_lib.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +--- a/drivers/scsi/scsi_lib.c ++++ b/drivers/scsi/scsi_lib.c +@@ -543,10 +543,9 @@ static bool scsi_end_request(struct requ + if (blk_queue_add_random(q)) + add_disk_randomness(req->q->disk); + +- if (!blk_rq_is_passthrough(req)) { +- WARN_ON_ONCE(!(cmd->flags & SCMD_INITIALIZED)); +- cmd->flags &= ~SCMD_INITIALIZED; +- } ++ WARN_ON_ONCE(!blk_rq_is_passthrough(req) && ++ !(cmd->flags & SCMD_INITIALIZED)); ++ cmd->flags = 0; + + /* + * Calling rcu_barrier() is not necessary here because the diff --git a/queue-6.8/selftests-ftrace-limit-length-in-subsystem-enable-tests.patch b/queue-6.8/selftests-ftrace-limit-length-in-subsystem-enable-tests.patch new file mode 100644 index 00000000000..550d5e47bb3 --- /dev/null +++ b/queue-6.8/selftests-ftrace-limit-length-in-subsystem-enable-tests.patch @@ -0,0 +1,55 @@ +From 1a4ea83a6e67f1415a1f17c1af5e9c814c882bb5 Mon Sep 17 00:00:00 2001 +From: Yuanhe Shu +Date: Mon, 26 Feb 2024 11:18:16 +0800 +Subject: selftests/ftrace: Limit length in subsystem-enable tests + +From: Yuanhe Shu + +commit 1a4ea83a6e67f1415a1f17c1af5e9c814c882bb5 upstream. + +While sched* events being traced and sched* events continuously happen, +"[xx] event tracing - enable/disable with subsystem level files" would +not stop as on some slower systems it seems to take forever. +Select the first 100 lines of output would be enough to judge whether +there are more than 3 types of sched events. + +Fixes: 815b18ea66d6 ("ftracetest: Add basic event tracing test cases") +Cc: stable@vger.kernel.org +Signed-off-by: Yuanhe Shu +Acked-by: Masami Hiramatsu (Google) +Acked-by: Steven Rostedt (Google) +Signed-off-by: Shuah Khan +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc ++++ b/tools/testing/selftests/ftrace/test.d/event/subsystem-enable.tc +@@ -18,7 +18,7 @@ echo 'sched:*' > set_event + + yield + +-count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` ++count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` + if [ $count -lt 3 ]; then + fail "at least fork, exec and exit events should be recorded" + fi +@@ -29,7 +29,7 @@ echo 1 > events/sched/enable + + yield + +-count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` ++count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` + if [ $count -lt 3 ]; then + fail "at least fork, exec and exit events should be recorded" + fi +@@ -40,7 +40,7 @@ echo 0 > events/sched/enable + + yield + +-count=`cat trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` ++count=`head -n 100 trace | grep -v ^# | awk '{ print $5 }' | sort -u | wc -l` + if [ $count -ne 0 ]; then + fail "any of scheduler events should not be recorded" + fi diff --git a/queue-6.8/series b/queue-6.8/series index fe38f11e8f2..0f30baf3405 100644 --- a/queue-6.8/series +++ b/queue-6.8/series @@ -1,2 +1,10 @@ io_uring-fix-io_cqring_wait-not-restoring-sigmask-on-get_timespec64-failure.patch drm-i915-cdclk-fix-voltage_level-programming-edge-ca.patch +revert-vmgenid-emit-uevent-when-vmgenid-updates.patch +sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch +selftests-ftrace-limit-length-in-subsystem-enable-tests.patch +random-handle-creditable-entropy-from-atomic-process-context.patch +scsi-core-fix-handling-of-scmd_fail_if_recovering.patch +net-usb-ax88179_178a-avoid-writing-the-mac-address-before-first-reading.patch +btrfs-do-not-wait-for-short-bulk-allocation.patch +btrfs-zoned-do-not-flag-zeroout-on-non-dirty-extent-buffer.patch diff --git a/queue-6.8/sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch b/queue-6.8/sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch new file mode 100644 index 00000000000..dcbe6cd0fc5 --- /dev/null +++ b/queue-6.8/sunrpc-fix-rpcgss_context-trace-event-acceptor-field.patch @@ -0,0 +1,54 @@ +From a4833e3abae132d613ce7da0e0c9a9465d1681fa Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Wed, 10 Apr 2024 12:38:13 -0400 +Subject: SUNRPC: Fix rpcgss_context trace event acceptor field + +From: Steven Rostedt (Google) + +commit a4833e3abae132d613ce7da0e0c9a9465d1681fa upstream. + +The rpcgss_context trace event acceptor field is a dynamically sized +string that records the "data" parameter. But this parameter is also +dependent on the "len" field to determine the size of the data. + +It needs to use __string_len() helper macro where the length can be passed +in. It also incorrectly uses strncpy() to save it instead of +__assign_str(). As these macros can change, it is not wise to open code +them in trace events. + +As of commit c759e609030c ("tracing: Remove __assign_str_len()"), +__assign_str() can be used for both __string() and __string_len() fields. +Before that commit, __assign_str_len() is required to be used. This needs +to be noted for backporting. (In actuality, commit c1fa617caeb0 ("tracing: +Rework __assign_str() and __string() to not duplicate getting the string") +is the commit that makes __string_str_len() obsolete). + +Cc: stable@vger.kernel.org +Fixes: 0c77668ddb4e ("SUNRPC: Introduce trace points in rpc_auth_gss.ko") +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Chuck Lever +Signed-off-by: Greg Kroah-Hartman +--- + include/trace/events/rpcgss.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/include/trace/events/rpcgss.h ++++ b/include/trace/events/rpcgss.h +@@ -609,7 +609,7 @@ TRACE_EVENT(rpcgss_context, + __field(unsigned int, timeout) + __field(u32, window_size) + __field(int, len) +- __string(acceptor, data) ++ __string_len(acceptor, data, len) + ), + + TP_fast_assign( +@@ -618,7 +618,7 @@ TRACE_EVENT(rpcgss_context, + __entry->timeout = timeout; + __entry->window_size = window_size; + __entry->len = len; +- strncpy(__get_str(acceptor), data, len); ++ __assign_str(acceptor, data); + ), + + TP_printk("win_size=%u expiry=%lu now=%lu timeout=%u acceptor=%.*s",