From: Greg Kroah-Hartman Date: Fri, 20 Oct 2023 16:56:38 +0000 (+0200) Subject: 6.5-stable patches X-Git-Tag: v4.14.328~93 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=5d0d7c2806920f0980506c244bbc6d5d1bdf76aa;p=thirdparty%2Fkernel%2Fstable-queue.git 6.5-stable patches added patches: btrfs-fix-stripe-length-calculation-for-non-zoned-data-chunk-allocation.patch ice-reset-first-in-crash-dump-kernels.patch kvm-x86-mask-lvtpc-when-handling-a-pmi.patch net-smc-return-the-right-falback-reason-when-prefix-checks-fail.patch nfc-nci-fix-possible-null-pointer-dereference-in-send_acknowledge.patch regmap-fix-null-deref-on-lookup.patch --- diff --git a/queue-6.5/btrfs-fix-stripe-length-calculation-for-non-zoned-data-chunk-allocation.patch b/queue-6.5/btrfs-fix-stripe-length-calculation-for-non-zoned-data-chunk-allocation.patch new file mode 100644 index 00000000000..7a587be656c --- /dev/null +++ b/queue-6.5/btrfs-fix-stripe-length-calculation-for-non-zoned-data-chunk-allocation.patch @@ -0,0 +1,230 @@ +From 8a540e990d7da36813cb71a4a422712bfba448a4 Mon Sep 17 00:00:00 2001 +From: Zygo Blaxell +Date: Sat, 7 Oct 2023 01:14:21 -0400 +Subject: btrfs: fix stripe length calculation for non-zoned data chunk allocation + +From: Zygo Blaxell + +commit 8a540e990d7da36813cb71a4a422712bfba448a4 upstream. + +Commit f6fca3917b4d "btrfs: store chunk size in space-info struct" +broke data chunk allocations on non-zoned multi-device filesystems when +using default chunk_size. Commit 5da431b71d4b "btrfs: fix the max chunk +size and stripe length calculation" partially fixed that, and this patch +completes the fix for that case. + +After commit f6fca3917b4d and 5da431b71d4b, the sequence of events for +a data chunk allocation on a non-zoned filesystem is: + + 1. btrfs_create_chunk calls init_alloc_chunk_ctl, which copies + space_info->chunk_size (default 10 GiB) to ctl->max_stripe_len + unmodified. Before f6fca3917b4d, ctl->max_stripe_len value was + 1 GiB for non-zoned data chunks and not configurable. + + 2. btrfs_create_chunk calls gather_device_info which consumes + and produces more fields of chunk_ctl. + + 3. gather_device_info multiplies ctl->max_stripe_len by + ctl->dev_stripes (which is 1 in all cases except dup) + and calls find_free_dev_extent with that number as num_bytes. + + 4. find_free_dev_extent locates the first dev_extent hole on + a device which is at least as large as num_bytes. With default + max_chunk_size from f6fca3917b4d, it finds the first hole which is + longer than 10 GiB, or the largest hole if that hole is shorter + than 10 GiB. This is different from the pre-f6fca3917b4d + behavior, where num_bytes is 1 GiB, and find_free_dev_extent + may choose a different hole. + + 5. gather_device_info repeats step 4 with all devices to find + the first or largest dev_extent hole that can be allocated on + each device. + + 6. gather_device_info sorts the device list by the hole size + on each device, using total unallocated space on each device to + break ties, then returns to btrfs_create_chunk with the list. + + 7. btrfs_create_chunk calls decide_stripe_size_regular. + + 8. decide_stripe_size_regular finds the largest stripe_len that + fits across the first nr_devs device dev_extent holes that were + found by gather_device_info (and satisfies other constraints + on stripe_len that are not relevant here). + + 9. decide_stripe_size_regular caps the length of the stripe it + computed at 1 GiB. This cap appeared in 5da431b71d4b to correct + one of the other regressions introduced in f6fca3917b4d. + + 10. btrfs_create_chunk creates a new chunk with the above + computed size and number of devices. + +At step 4, gather_device_info() has found a location where stripe up to +10 GiB in length could be allocated on several devices, and selected +which devices should have a dev_extent allocated on them, but at step +9, only 1 GiB of the space that was found on each device can be used. +This mismatch causes new suboptimal chunk allocation cases that did not +occur in pre-f6fca3917b4d kernels. + +Consider a filesystem using raid1 profile with 3 devices. After some +balances, device 1 has 10x 1 GiB unallocated space, while devices 2 +and 3 have 1x 10 GiB unallocated space, i.e. the same total amount of +space, but distributed across different numbers of dev_extent holes. +For visualization, let's ignore all the chunks that were allocated before +this point, and focus on the remaining holes: + + Device 1: [_] [_] [_] [_] [_] [_] [_] [_] [_] [_] (10x 1 GiB unallocated) + Device 2: [__________] (10 GiB contig unallocated) + Device 3: [__________] (10 GiB contig unallocated) + +Before f6fca3917b4d, the allocator would fill these optimally by +allocating chunks with dev_extents on devices 1 and 2 ([12]), 1 and 3 +([13]), or 2 and 3 ([23]): + + [after 0 chunk allocations] + Device 1: [_] [_] [_] [_] [_] [_] [_] [_] [_] [_] (10 GiB) + Device 2: [__________] (10 GiB) + Device 3: [__________] (10 GiB) + + [after 1 chunk allocation] + Device 1: [12] [_] [_] [_] [_] [_] [_] [_] [_] [_] + Device 2: [12] [_________] (9 GiB) + Device 3: [__________] (10 GiB) + + [after 2 chunk allocations] + Device 1: [12] [13] [_] [_] [_] [_] [_] [_] [_] [_] (8 GiB) + Device 2: [12] [_________] (9 GiB) + Device 3: [13] [_________] (9 GiB) + + [after 3 chunk allocations] + Device 1: [12] [13] [12] [_] [_] [_] [_] [_] [_] [_] (7 GiB) + Device 2: [12] [12] [________] (8 GiB) + Device 3: [13] [_________] (9 GiB) + + [...] + + [after 12 chunk allocations] + Device 1: [12] [13] [12] [13] [12] [13] [12] [13] [_] [_] (2 GiB) + Device 2: [12] [12] [23] [23] [12] [12] [23] [23] [__] (2 GiB) + Device 3: [13] [13] [23] [23] [13] [23] [13] [23] [__] (2 GiB) + + [after 13 chunk allocations] + Device 1: [12] [13] [12] [13] [12] [13] [12] [13] [12] [_] (1 GiB) + Device 2: [12] [12] [23] [23] [12] [12] [23] [23] [12] [_] (1 GiB) + Device 3: [13] [13] [23] [23] [13] [23] [13] [23] [__] (2 GiB) + + [after 14 chunk allocations] + Device 1: [12] [13] [12] [13] [12] [13] [12] [13] [12] [13] (full) + Device 2: [12] [12] [23] [23] [12] [12] [23] [23] [12] [_] (1 GiB) + Device 3: [13] [13] [23] [23] [13] [23] [13] [23] [13] [_] (1 GiB) + + [after 15 chunk allocations] + Device 1: [12] [13] [12] [13] [12] [13] [12] [13] [12] [13] (full) + Device 2: [12] [12] [23] [23] [12] [12] [23] [23] [12] [23] (full) + Device 3: [13] [13] [23] [23] [13] [23] [13] [23] [13] [23] (full) + +This allocates all of the space with no waste. The sorting function used +by gather_device_info considers free space holes above 1 GiB in length +to be equal to 1 GiB, so once find_free_dev_extent locates a sufficiently +long hole on each device, all the holes appear equal in the sort, and the +comparison falls back to sorting devices by total free space. This keeps +usable space on each device equal so they can all be filled completely. + +After f6fca3917b4d, the allocator prefers the devices with larger holes +over the devices with more free space, so it makes bad allocation choices: + + [after 1 chunk allocation] + Device 1: [_] [_] [_] [_] [_] [_] [_] [_] [_] [_] (10 GiB) + Device 2: [23] [_________] (9 GiB) + Device 3: [23] [_________] (9 GiB) + + [after 2 chunk allocations] + Device 1: [_] [_] [_] [_] [_] [_] [_] [_] [_] [_] (10 GiB) + Device 2: [23] [23] [________] (8 GiB) + Device 3: [23] [23] [________] (8 GiB) + + [after 3 chunk allocations] + Device 1: [_] [_] [_] [_] [_] [_] [_] [_] [_] [_] (10 GiB) + Device 2: [23] [23] [23] [_______] (7 GiB) + Device 3: [23] [23] [23] [_______] (7 GiB) + + [...] + + [after 9 chunk allocations] + Device 1: [_] [_] [_] [_] [_] [_] [_] [_] [_] [_] (10 GiB) + Device 2: [23] [23] [23] [23] [23] [23] [23] [23] [23] [_] (1 GiB) + Device 3: [23] [23] [23] [23] [23] [23] [23] [23] [23] [_] (1 GiB) + + [after 10 chunk allocations] + Device 1: [12] [_] [_] [_] [_] [_] [_] [_] [_] [_] (9 GiB) + Device 2: [23] [23] [23] [23] [23] [23] [23] [23] [12] (full) + Device 3: [23] [23] [23] [23] [23] [23] [23] [23] [_] (1 GiB) + + [after 11 chunk allocations] + Device 1: [12] [13] [_] [_] [_] [_] [_] [_] [_] [_] (8 GiB) + Device 2: [23] [23] [23] [23] [23] [23] [23] [23] [12] (full) + Device 3: [23] [23] [23] [23] [23] [23] [23] [23] [13] (full) + +No further allocations are possible, with 8 GiB wasted (4 GiB of data +space). The sort in gather_device_info now considers free space in +holes longer than 1 GiB to be distinct, so it will prefer devices 2 and +3 over device 1 until all but 1 GiB is allocated on devices 2 and 3. +At that point, with only 1 GiB unallocated on every device, the largest +hole length on each device is equal at 1 GiB, so the sort finally moves +to ordering the devices with the most free space, but by this time it +is too late to make use of the free space on device 1. + +Note that it's possible to contrive a case where the pre-f6fca3917b4d +allocator fails the same way, but these cases generally have extensive +dev_extent fragmentation as a precondition (e.g. many holes of 768M +in length on one device, and few holes 1 GiB in length on the others). +With the regression in f6fca3917b4d, bad chunk allocation can occur even +under optimal conditions, when all dev_extent holes are exact multiples +of stripe_len in length, as in the example above. + +Also note that post-f6fca3917b4d kernels do treat dev_extent holes +larger than 10 GiB as equal, so the bad behavior won't show up on a +freshly formatted filesystem; however, as the filesystem ages and fills +up, and holes ranging from 1 GiB to 10 GiB in size appear, the problem +can show up as a failure to balance after adding or removing devices, +or an unexpected shortfall in available space due to unequal allocation. + +To fix the regression and make data chunk allocation work +again, set ctl->max_stripe_len back to the original SZ_1G, or +space_info->chunk_size if that's smaller (the latter can happen if the +user set space_info->chunk_size to less than 1 GiB via sysfs, or it's +a 32 MiB system chunk with a hardcoded chunk_size and stripe_len). + +While researching the background of the earlier commits, I found that an +identical fix was already proposed at: + + https://lore.kernel.org/linux-btrfs/de83ac46-a4a3-88d3-85ce-255b7abc5249@gmx.com/ + +The previous review missed one detail: ctl->max_stripe_len is used +before decide_stripe_size_regular() is called, when it is too late for +the changes in that function to have any effect. ctl->max_stripe_len is +not used directly by decide_stripe_size_regular(), but the parameter +does heavily influence the per-device free space data presented to +the function. + +Fixes: f6fca3917b4d ("btrfs: store chunk size in space-info struct") +CC: stable@vger.kernel.org # 6.1+ +Link: https://lore.kernel.org/linux-btrfs/20231007051421.19657-1-ce3g8jdj@umail.furryterror.org/ +Reviewed-by: Qu Wenruo +Signed-off-by: Zygo Blaxell +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/volumes.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -5125,7 +5125,7 @@ static void init_alloc_chunk_ctl_policy_ + ASSERT(space_info); + + ctl->max_chunk_size = READ_ONCE(space_info->chunk_size); +- ctl->max_stripe_size = ctl->max_chunk_size; ++ ctl->max_stripe_size = min_t(u64, ctl->max_chunk_size, SZ_1G); + + if (ctl->type & BTRFS_BLOCK_GROUP_SYSTEM) + ctl->devs_max = min_t(int, ctl->devs_max, BTRFS_MAX_DEVS_SYS_CHUNK); diff --git a/queue-6.5/ice-reset-first-in-crash-dump-kernels.patch b/queue-6.5/ice-reset-first-in-crash-dump-kernels.patch new file mode 100644 index 00000000000..4bb1f67ca75 --- /dev/null +++ b/queue-6.5/ice-reset-first-in-crash-dump-kernels.patch @@ -0,0 +1,71 @@ +From 0288c3e709e5fabd51e84715c5c798a02f43061a Mon Sep 17 00:00:00 2001 +From: Jesse Brandeburg +Date: Wed, 11 Oct 2023 16:33:33 -0700 +Subject: ice: reset first in crash dump kernels + +From: Jesse Brandeburg + +commit 0288c3e709e5fabd51e84715c5c798a02f43061a upstream. + +When the system boots into the crash dump kernel after a panic, the ice +networking device may still have pending transactions that can cause errors +or machine checks when the device is re-enabled. This can prevent the crash +dump kernel from loading the driver or collecting the crash data. + +To avoid this issue, perform a function level reset (FLR) on the ice device +via PCIe config space before enabling it on the crash kernel. This will +clear any outstanding transactions and stop all queues and interrupts. +Restore the config space after the FLR, otherwise it was found in testing +that the driver wouldn't load successfully. + +The following sequence causes the original issue: +- Load the ice driver with modprobe ice +- Enable SR-IOV with 2 VFs: echo 2 > /sys/class/net/eth0/device/sriov_num_vfs +- Trigger a crash with echo c > /proc/sysrq-trigger +- Load the ice driver again (or let it load automatically) with modprobe ice +- The system crashes again during pcim_enable_device() + +Fixes: 837f08fdecbe ("ice: Add basic driver framework for Intel(R) E800 Series") +Reported-by: Vishal Agrawal +Reviewed-by: Jay Vosburgh +Reviewed-by: Przemek Kitszel +Signed-off-by: Jesse Brandeburg +Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) +Link: https://lore.kernel.org/r/20231011233334.336092-3-jacob.e.keller@intel.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/ice/ice_main.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/drivers/net/ethernet/intel/ice/ice_main.c ++++ b/drivers/net/ethernet/intel/ice/ice_main.c +@@ -6,6 +6,7 @@ + #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + + #include ++#include + #include "ice.h" + #include "ice_base.h" + #include "ice_lib.h" +@@ -4966,6 +4967,20 @@ ice_probe(struct pci_dev *pdev, const st + return -EINVAL; + } + ++ /* when under a kdump kernel initiate a reset before enabling the ++ * device in order to clear out any pending DMA transactions. These ++ * transactions can cause some systems to machine check when doing ++ * the pcim_enable_device() below. ++ */ ++ if (is_kdump_kernel()) { ++ pci_save_state(pdev); ++ pci_clear_master(pdev); ++ err = pcie_flr(pdev); ++ if (err) ++ return err; ++ pci_restore_state(pdev); ++ } ++ + /* this driver uses devres, see + * Documentation/driver-api/driver-model/devres.rst + */ diff --git a/queue-6.5/kvm-x86-mask-lvtpc-when-handling-a-pmi.patch b/queue-6.5/kvm-x86-mask-lvtpc-when-handling-a-pmi.patch new file mode 100644 index 00000000000..fb227e42c7d --- /dev/null +++ b/queue-6.5/kvm-x86-mask-lvtpc-when-handling-a-pmi.patch @@ -0,0 +1,53 @@ +From a16eb25b09c02a54c1c1b449d4b6cfa2cf3f013a Mon Sep 17 00:00:00 2001 +From: Jim Mattson +Date: Mon, 25 Sep 2023 17:34:47 +0000 +Subject: KVM: x86: Mask LVTPC when handling a PMI + +From: Jim Mattson + +commit a16eb25b09c02a54c1c1b449d4b6cfa2cf3f013a upstream. + +Per the SDM, "When the local APIC handles a performance-monitoring +counters interrupt, it automatically sets the mask flag in the LVT +performance counter register." Add this behavior to KVM's local APIC +emulation. + +Failure to mask the LVTPC entry results in spurious PMIs, e.g. when +running Linux as a guest, PMI handlers that do a "late_ack" spew a large +number of "dazed and confused" spurious NMI warnings. + +Fixes: f5132b01386b ("KVM: Expose a version 2 architectural PMU to a guests") +Cc: stable@vger.kernel.org +Signed-off-by: Jim Mattson +Tested-by: Mingwei Zhang +Signed-off-by: Mingwei Zhang +Link: https://lore.kernel.org/r/20230925173448.3518223-3-mizhang@google.com +[sean: massage changelog, correct Fixes] +Signed-off-by: Sean Christopherson +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/lapic.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/arch/x86/kvm/lapic.c ++++ b/arch/x86/kvm/lapic.c +@@ -2738,13 +2738,17 @@ int kvm_apic_local_deliver(struct kvm_la + { + u32 reg = kvm_lapic_get_reg(apic, lvt_type); + int vector, mode, trig_mode; ++ int r; + + if (kvm_apic_hw_enabled(apic) && !(reg & APIC_LVT_MASKED)) { + vector = reg & APIC_VECTOR_MASK; + mode = reg & APIC_MODE_MASK; + trig_mode = reg & APIC_LVT_LEVEL_TRIGGER; +- return __apic_accept_irq(apic, mode, vector, 1, trig_mode, +- NULL); ++ ++ r = __apic_accept_irq(apic, mode, vector, 1, trig_mode, NULL); ++ if (r && lvt_type == APIC_LVTPC) ++ kvm_lapic_set_reg(apic, APIC_LVTPC, reg | APIC_LVT_MASKED); ++ return r; + } + return 0; + } diff --git a/queue-6.5/net-smc-return-the-right-falback-reason-when-prefix-checks-fail.patch b/queue-6.5/net-smc-return-the-right-falback-reason-when-prefix-checks-fail.patch new file mode 100644 index 00000000000..ebc957c71da --- /dev/null +++ b/queue-6.5/net-smc-return-the-right-falback-reason-when-prefix-checks-fail.patch @@ -0,0 +1,38 @@ +From 4abbd2e3c1db671fa1286390f1310aec78386f1d Mon Sep 17 00:00:00 2001 +From: Dust Li +Date: Thu, 12 Oct 2023 20:37:29 +0800 +Subject: net/smc: return the right falback reason when prefix checks fail + +From: Dust Li + +commit 4abbd2e3c1db671fa1286390f1310aec78386f1d upstream. + +In the smc_listen_work(), if smc_listen_prfx_check() failed, +the real reason: SMC_CLC_DECL_DIFFPREFIX was dropped, and +SMC_CLC_DECL_NOSMCDEV was returned. + +Althrough this is also kind of SMC_CLC_DECL_NOSMCDEV, but return +the real reason is much friendly for debugging. + +Fixes: e49300a6bf62 ("net/smc: add listen processing for SMC-Rv2") +Signed-off-by: Dust Li +Reviewed-by: Alexandra Winter +Reviewed-by: Wenjia Zhang +Link: https://lore.kernel.org/r/20231012123729.29307-1-dust.li@linux.alibaba.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/smc/af_smc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/smc/af_smc.c ++++ b/net/smc/af_smc.c +@@ -2335,7 +2335,7 @@ static int smc_listen_find_device(struct + smc_find_ism_store_rc(rc, ini); + return (!rc) ? 0 : ini->rc; + } +- return SMC_CLC_DECL_NOSMCDEV; ++ return prfx_rc; + } + + /* listen worker: finish RDMA setup */ diff --git a/queue-6.5/nfc-nci-fix-possible-null-pointer-dereference-in-send_acknowledge.patch b/queue-6.5/nfc-nci-fix-possible-null-pointer-dereference-in-send_acknowledge.patch new file mode 100644 index 00000000000..3be9c776076 --- /dev/null +++ b/queue-6.5/nfc-nci-fix-possible-null-pointer-dereference-in-send_acknowledge.patch @@ -0,0 +1,38 @@ +From 7937609cd387246aed994e81aa4fa951358fba41 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Fri, 13 Oct 2023 20:41:29 +0200 +Subject: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Krzysztof Kozlowski + +commit 7937609cd387246aed994e81aa4fa951358fba41 upstream. + +Handle memory allocation failure from nci_skb_alloc() (calling +alloc_skb()) to avoid possible NULL pointer dereference. + +Reported-by: 黄思聪 +Fixes: 391d8a2da787 ("NFC: Add NCI over SPI receive") +Cc: +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20231013184129.18738-1-krzysztof.kozlowski@linaro.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/nfc/nci/spi.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/nfc/nci/spi.c ++++ b/net/nfc/nci/spi.c +@@ -151,6 +151,8 @@ static int send_acknowledge(struct nci_s + int ret; + + skb = nci_skb_alloc(nspi->ndev, 0, GFP_KERNEL); ++ if (!skb) ++ return -ENOMEM; + + /* add the NCI SPI header to the start of the buffer */ + hdr = skb_push(skb, NCI_SPI_HDR_LEN); diff --git a/queue-6.5/regmap-fix-null-deref-on-lookup.patch b/queue-6.5/regmap-fix-null-deref-on-lookup.patch new file mode 100644 index 00000000000..a6579839e7e --- /dev/null +++ b/queue-6.5/regmap-fix-null-deref-on-lookup.patch @@ -0,0 +1,35 @@ +From c6df843348d6b71ea986266c12831cb60c2cf325 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 6 Oct 2023 10:21:04 +0200 +Subject: regmap: fix NULL deref on lookup + +From: Johan Hovold + +commit c6df843348d6b71ea986266c12831cb60c2cf325 upstream. + +Not all regmaps have a name so make sure to check for that to avoid +dereferencing a NULL pointer when dev_get_regmap() is used to lookup a +named regmap. + +Fixes: e84861fec32d ("regmap: dev_get_regmap_match(): fix string comparison") +Cc: stable@vger.kernel.org # 5.8 +Cc: Marc Kleine-Budde +Signed-off-by: Johan Hovold +Link: https://lore.kernel.org/r/20231006082104.16707-1-johan+linaro@kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/regmap/regmap.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/base/regmap/regmap.c ++++ b/drivers/base/regmap/regmap.c +@@ -1572,7 +1572,7 @@ static int dev_get_regmap_match(struct d + + /* If the user didn't specify a name match any */ + if (data) +- return !strcmp((*r)->name, data); ++ return (*r)->name && !strcmp((*r)->name, data); + else + return 1; + } diff --git a/queue-6.5/series b/queue-6.5/series index 85425ed0703..f1aa1afad5d 100644 --- a/queue-6.5/series +++ b/queue-6.5/series @@ -7,3 +7,9 @@ bluetooth-avoid-memcmp-out-of-bounds-warning.patch bluetooth-hci_conn-fix-modifying-handle-while-aborting.patch ice-fix-over-shifted-variable.patch ice-fix-safe-mode-when-ddp-is-missing.patch +ice-reset-first-in-crash-dump-kernels.patch +net-smc-return-the-right-falback-reason-when-prefix-checks-fail.patch +btrfs-fix-stripe-length-calculation-for-non-zoned-data-chunk-allocation.patch +nfc-nci-fix-possible-null-pointer-dereference-in-send_acknowledge.patch +regmap-fix-null-deref-on-lookup.patch +kvm-x86-mask-lvtpc-when-handling-a-pmi.patch