- Linux-stable-mirror - lists.linaro.org

Re: Request to backport data corruption fix to stable

by Steve French

Sasha, Also wanted to make sure stable gets this patch from David Howells that fixes a regression that was mentioned in some of the same email threads. It fixes an important stable regression in cifs_readv when cache=none. Bharath has also reviewed and tested it with 6.6 stable. See attached. On Fri, Nov 14, 2025 at 9:00 AM Sasha Levin <sashal(a)kernel.org> wrote: > > On Fri, Nov 14, 2025 at 04:42:57PM +0530, Shyam Prasad N wrote: > >Hi Greg/Sasha, > > > >Over the last few months, a few users have reported a data corruption > >with Linux SMB kernel client filesystem. This is one such report: > >https://lore.kernel.org/linux-cifs/36fb31bf2c854cdc930a3415f5551dcd@izw-ber… > > > >The issue is now well understood. Attached is a fix for this issue. > >I've made sure that the fix is stopping the data corruption and also > >not regressing other write patterns. > > > >The regression seems to have been introduced during a refactoring of > >this code path during the v6.3 and continued to exist till v6.9, > >before the code was refactored again with netfs helper library > >integration in v6.10. > > > >I request you to include this change in all stable trees for > >v6.3..v6.9. I've done my testing on stable-6.6. Please let me know if > >you want this tested on any other kernels. > > I'll queue it up for 6.6, thanks! > > -- > Thanks, > Sasha -- Thanks, Steve

1 month, 1 week

2
1
0 0

[PATCH] Bluetooth: btusb: Add one more ID 0x13d3:0x3612 for Realtek 8852CE

by Levi Zim via B4 Relay

From: Levi Zim <rsworktech(a)outlook.com> Devices with ID 13d3:3612 are found in ASUS TUF Gaming A16 (2025) and ASUS TX Gaming FA608FM. The corresponding device info from /sys/kernel/debug/usb/devices is T: Bus=03 Lev=02 Prnt=03 Port=02 Cnt=02 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3612 Rev= 0.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms Signed-off-by: Levi Zim <rsworktech(a)outlook.com> --- drivers/bluetooth/btusb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index 8085fabadde8ff01171783b59226589757bbbbbc..d1e62b3158166a33153a6dfaade03fd3fb7d8231 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -552,6 +552,8 @@ static const struct usb_device_id quirks_table[] = { BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x13d3, 0x3592), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, + { USB_DEVICE(0x13d3, 0x3612), .driver_info = BTUSB_REALTEK | + BTUSB_WIDEBAND_SPEECH }, { USB_DEVICE(0x0489, 0xe122), .driver_info = BTUSB_REALTEK | BTUSB_WIDEBAND_SPEECH }, --- base-commit: 302a1f674c00dd5581ab8e493ef44767c5101aab change-id: 20250927-ble-13d3-3612-53a2246e4862 Best regards, -- Levi Zim <rsworktech(a)outlook.com>

1 month, 1 week

4
3
0 0

Re: Compile Error fs/nfsd/nfs4state.o - clamp() low limit slotsize greater than high limit total_avail/scale_factor

by Mike-SPC via Bugspray Bot

Mike-SPC writes via Kernel.org Bugzilla: Hi there, at first: Thanks for patching and investigation. I've tested the patch mentioned in https://lkml.org/lkml/2025/11/10/12 and it works (for me). Thanks again and regards, Michael View: https://bugzilla.kernel.org/show_bug.cgi?id=220745#c17 You can reply to this message to join the discussion. -- Deet-doot-dot, I am a bot. Kernel.org Bugzilla (bugspray 0.1-dev)

1 month, 1 week

1
0
0 0

Get the Fruit Attraction 2025 Attendee List!

by Karlee Howell

Hi, We’re offering exclusive access to the Fruit Attraction 2025 Visitor Contact List — your direct connection to verified buyers, importers, exporters, and industry leaders from the global fresh produce, logistics, and agri-innovation market. We have 97,137 verified visitor contacts in our database. You’ll receive full contact data: Individual Email Address, Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, LinkedIn Profile, and more. All data is fully 100% GDPR-compliant and ethically sourced 20% Off—Respond Before Nov 20. Let me know if you are Interested to see the pricing? Reply “Send me Pricing.” Best regards, Karlee Howell Sr. Marketing Manager Prefer not to receive these emails? Just reply “NOT INTERESTED”.

1 month, 1 week

1
0
0 0

Sports bags, backpacks, sportswear

by HILL APEX

Hi linux-stable-mirror(a)lists.linaro.org We make sublimated sports bags, backpacks, and sportswear. To get delivery prices, please: 1. Visit hillapex.com and pick an item. 2. Let us know your order quantity. 3. Provide your country name. Best regards, Saad Afzal Founder | Hill Apex 📧 Email: saad(a)hillapex.com 🌐 Website: hillapex.com 📞 Phone/WhatsApp: +92 300 7101027 📍 Address: Chenab Ranger’s Road, 51310 Sialkot, Pakistan

1 month, 2 weeks

1
0
0 0

[tip: x86/boot] x86/acpi/boot: Correct acpi_is_processor_usable() check again

by tip-bot2 for Yazen Ghannam

The following commit has been merged into the x86/boot branch of tip: Commit-ID: 1c7ac68c05bc0327d725dd10aa05f5120f868250 Gitweb: https://git.kernel.org/tip/1c7ac68c05bc0327d725dd10aa05f5120f868250 Author: Yazen Ghannam <yazen.ghannam(a)amd.com> AuthorDate: Tue, 11 Nov 2025 14:53:57 Committer: Borislav Petkov (AMD) <bp(a)alien8.de> CommitterDate: Fri, 14 Nov 2025 21:00:26 +01:00 x86/acpi/boot: Correct acpi_is_processor_usable() check again ACPI v6.3 defined a new "Online Capable" MADT LAPIC flag. This bit is used in conjunction with the "Enabled" MADT LAPIC flag to determine if a CPU can be enabled/hotplugged by the OS after boot. Before the new bit was defined, the "Enabled" bit was explicitly described like this (ACPI v6.0 wording provided): "If zero, this processor is unusable, and the operating system support will not attempt to use it" This means that CPU hotplug (based on MADT) is not possible. Many BIOS implementations follow this guidance. They may include LAPIC entries in MADT for unavailable CPUs, but since these entries are marked with "Enabled=0" it is expected that the OS will completely ignore these entries. However, QEMU will do the same (include entries with "Enabled=0") for the purpose of allowing CPU hotplug within the guest. Comment from QEMU function pc_madt_cpu_entry(): /* ACPI spec says that LAPIC entry for non present * CPU may be omitted from MADT or it must be marked * as disabled. However omitting non present CPU from * MADT breaks hotplug on linux. So possible CPUs * should be put in MADT but kept disabled. */ Recent Linux topology changes broke the QEMU use case. A following fix for the QEMU use case broke bare metal topology enumeration. Rework the Linux MADT LAPIC flags check to allow the QEMU use case only for guests and to maintain the ACPI spec behavior for bare metal. Remove an unnecessary check added to fix a bare metal case introduced by the QEMU "fix". [ bp: Change logic as Michal suggested. ] Fixes: fed8d8773b8e ("x86/acpi/boot: Correct acpi_is_processor_usable() check") Fixes: f0551af02130 ("x86/topology: Ignore non-present APIC IDs in a present package") Closes: https://lore.kernel.org/r/20251024204658.3da9bf3f.michal.pecio@gmail.com Reported-by: Michal Pecio <michal.pecio(a)gmail.com> Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Tested-by: Michal Pecio <michal.pecio(a)gmail.com> Tested-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/20251111145357.4031846-1-yazen.ghannam@amd.com --- arch/x86/kernel/acpi/boot.c | 12 ++++++++---- arch/x86/kernel/cpu/topology.c | 15 --------------- 2 files changed, 8 insertions(+), 19 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 9fa321a..d6138b2 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -35,6 +35,7 @@ #include <asm/smp.h> #include <asm/i8259.h> #include <asm/setup.h> +#include <asm/hypervisor.h> #include "sleep.h" /* To include x86_acpi_suspend_lowlevel */ static int __initdata acpi_force = 0; @@ -164,11 +165,14 @@ static bool __init acpi_is_processor_usable(u32 lapic_flags) if (lapic_flags & ACPI_MADT_ENABLED) return true; - if (!acpi_support_online_capable || - (lapic_flags & ACPI_MADT_ONLINE_CAPABLE)) - return true; + if (acpi_support_online_capable) + return lapic_flags & ACPI_MADT_ONLINE_CAPABLE; - return false; + /* + * QEMU expects legacy "Enabled=0" LAPIC entries to be counted as usable + * in order to support CPU hotplug in guests. + */ + return !hypervisor_is_type(X86_HYPER_NATIVE); } static int __init diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 6073a16..425404e 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -27,7 +27,6 @@ #include <xen/xen.h> #include <asm/apic.h> -#include <asm/hypervisor.h> #include <asm/io_apic.h> #include <asm/mpspec.h> #include <asm/msr.h> @@ -240,20 +239,6 @@ static __init void topo_register_apic(u32 apic_id, u32 acpi_id, bool present) cpuid_to_apicid[cpu] = apic_id; topo_set_cpuids(cpu, apic_id, acpi_id); } else { - u32 pkgid = topo_apicid(apic_id, TOPO_PKG_DOMAIN); - - /* - * Check for present APICs in the same package when running - * on bare metal. Allow the bogosity in a guest. - */ - if (hypervisor_is_type(X86_HYPER_NATIVE) && - topo_unit_count(pkgid, TOPO_PKG_DOMAIN, phys_cpu_present_map)) { - pr_info_once("Ignoring hot-pluggable APIC ID %x in present package.\n", - apic_id); - topo_info.nr_rejected_cpus++; - return; - } - topo_info.nr_disabled_cpus++; }

1 month, 2 weeks

1
0
0 0

btrfs task hung in `lock_extent` syzbot report and CVE-2024-35784

by Andrey Kalachev

Hi. I've check c-repro [1] on 6.1.y branch and found that repro still produce the crash on 6.1.y. I notice that syzbot bisection result [2] is incorrect: indeed, the hung was fixed by upstream commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). Also, I saw CVE-2024-35784 [3][4] vulnerability, that have direct relation with that syzbot report. Therefore, syzbot reproducer provided additional way to check for CVE-2024-35784. I attempted to fix CVE-2024-35784 in stable 6.1.y (over v6.1.157), and found that the initial fix commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") introduced regressions [5][6]. IMHO here is the minimum patch series to eliminate CVE-2024-35784 from 6.1.y: b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") (Initial fix of the CVE-2024-35784) a1a4a9ca77f1 ("btrfs: fix race between ordered extent completion and fiemap") (Fixes: b0ad381fa769) 978b63f7464a ("btrfs: fix race when detecting delalloc ranges during fiemap") (Fixes: b0ad381fa769) 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") (Optimization: 978b63f7464a) 53e24158684b ("btrfs: set start on clone before calling copy_extent_buffer_full") (Fixes: 1cab1375ba6d) Required patches attached. Only two patches in the series have minor backport modifications due to v6.1.157 btrfs code differences. The remaining patches are identical to the upstream. Regards, AK Reported-by: syzbot+f8217aae382555004877(a)syzkaller.appspotmail.com ---- [1] https://syzkaller.appspot.com/text?tag=ReproC&x=12b4c88b280000 [2] https://syzkaller.appspot.com/bug?extid=f8217aae382555004877 [3] https://lore.kernel.org/all/2024051704-CVE-2024-35784-6dec@gregkh/ [4] https://cve.org/CVERecord/?id=CVE-2024-35784 [5] https://lore.kernel.org/linux-btrfs/cover.1709202499.git.fdmanana@suse.com/ [6] https://lore.kernel.org/all/20240304211551.880347593@linuxfoundation.org/

1 month, 2 weeks

1
12
0 0

[PATCH 0/6] Hello,

by Miquel Raynal

Here is a series adding support for 6 Winbond SPI NOR chips. Describing these chips is needed otherwise the block protection feature is not available. Everything else looks fine otherwise. In practice I am only adding 6 very similar IDs but I split the commits because the amount of meta data to show proof that all the chips have been tested and work is pretty big. As the commits simply add an ID, I am Cc'ing stable with the hope to get these backported to LTS kernels as allowed by the stable rules (see link below, but I hope I am doing this right). Link: https://elixir.bootlin.com/linux/v6.17.7/source/Documentation/process/stabl… Thanks, Miquèl --- Miquel Raynal (6): mtd: spi-nor: winbond: Add support for W25Q01NWxxIQ chips mtd: spi-nor: winbond: Add support for W25Q01NWxxIM chips mtd: spi-nor: winbond: Add support for W25Q02NWxxIM chips mtd: spi-nor: winbond: Add support for W25H512NWxxAM chips mtd: spi-nor: winbond: Add support for W25H01NWxxAM chips mtd: spi-nor: winbond: Add support for W25H02NWxxAM chips drivers/mtd/spi-nor/winbond.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) --- base-commit: 479ba7fc704936b74a91ee352fe113d6391d562f change-id: 20251105-winbond-v6-18-rc1-spi-nor-7f78cb2785d6 Best regards, -- Miquel Raynal <miquel.raynal(a)bootlin.com>

1 month, 2 weeks

4
13
0 0

[PATCH RFC 0/2] ASoC: codecs: pm4125: Two minor fixes for potential issues

by Krzysztof Kozlowski

I marked these as fixes, but the issue is not likely to trigger in normal conditions. Not tested on hardware, please kindly provide tested-by, the best with some probe bind/unbind cycle. Best regards, Krzysztof --- Krzysztof Kozlowski (2): ASoC: codecs: pm4125: Fix potential conflict when probing two devices ASoC: codecs: pm4125: Remove irq_chip on component unbind sound/soc/codecs/pm4125.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) --- base-commit: d22122bd89bc5ce7b3e057d99679ca50a72a8245 change-id: 20251023-asoc-regmap-irq-chip-bb2053c32168 Best regards, -- Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org>

1 month, 2 weeks

2
4
0 0

[PATCH] amba: tegra-ahb: fix device leak on smmu enable

by Johan Hovold

Make sure to drop the reference taken to the ahb platform device when looking up its driver data while enabling the smmu. Note that holding a reference to a device does not prevent its driver data from going away. Fixes: 89c788bab1f0 ("ARM: tegra: Add SMMU enabler in AHB") Cc: stable(a)vger.kernel.org # 3.5 Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/amba/tegra-ahb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/amba/tegra-ahb.c b/drivers/amba/tegra-ahb.c index c0e8b765522d..f23c3ed01810 100644 --- a/drivers/amba/tegra-ahb.c +++ b/drivers/amba/tegra-ahb.c @@ -144,6 +144,7 @@ int tegra_ahb_enable_smmu(struct device_node *dn) if (!dev) return -EPROBE_DEFER; ahb = dev_get_drvdata(dev); + put_device(dev); val = gizmo_readl(ahb, AHB_ARBITRATION_XBAR_CTRL); val |= AHB_ARBITRATION_XBAR_CTRL_SMMU_INIT_DONE; gizmo_writel(ahb, val, AHB_ARBITRATION_XBAR_CTRL); -- 2.49.1

1 month, 2 weeks

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror