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

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 week, 3 days

1
0
0 0

[PATCH v1 v6.12.y] nfsd: Replace clamp_t in nfsd4_get_drc_mem()

by Chuck Lever

From: NeilBrown <neil(a)brown.name> A recent change to clamp_t() in 6.1.y caused fs/nfsd/nfs4state.c to fail to compile with gcc-9. The code in nfsd4_get_drc_mem() was written with the assumption that when "max < min", clamp(val, min, max) would return max. This assumption is not documented as an API promise and the change caused a compile failure if it could be statically determined that "max < min". The relevant code was no longer present upstream when commit 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()") landed there, so there is no upstream change to nfsd4_get_drc_mem() to backport. There is no clear case that the existing code in nfsd4_get_drc_mem() is functioning incorrectly. The goal of this patch is to permit the clean application of commit 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()"), and any commits that depend on it, to LTS kernels without affecting the ability to compile those kernels. This is done by open-coding the __clamp() macro sans the built-in type checking. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220745#c0 Signed-off-by: NeilBrown <neil(a)brown.name> Stable-dep-of: 1519fbc8832b ("minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- fs/nfsd/nfs4state.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Changes since Neil's post: * Editorial changes to the commit message * Attempt to address David's review comments * Applied to linux-6.12.y, passed NFSD upstream CI suite This patch is intended to be applied to linux-6.12.y, and should apply cleanly to other LTS kernels since nfsd4_get_drc_mem hasn't changed since v5.4. diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 7b0fabf8c657..41545933dd18 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -1983,8 +1983,10 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca, struct nfsd_net *nn */ scale_factor = max_t(unsigned int, 8, nn->nfsd_serv->sv_nrthreads); - avail = clamp_t(unsigned long, avail, slotsize, - total_avail/scale_factor); + if (avail > total_avail / scale_factor) + avail = total_avail / scale_factor; + else if (avail < slotsize) + avail = slotsize; num = min_t(int, num, avail / slotsize); num = max_t(int, num, 1); nfsd_drc_mem_used += num * slotsize; -- 2.51.0

1 week, 4 days

2
1
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 week, 4 days

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 week, 4 days

1
0
0 0

[PATCH 1/2] x86/amd_node: fix integer divide by zero during init

by Steven Noonan

On a Xen dom0 boot, this feature does not behave, and we end up calculating: num_roots = 1 num_nodes = 2 roots_per_node = 0 This causes a divide-by-zero in the modulus inside the loop. This change adds a couple of guards for invalid states where we might get a divide-by-zero. Signed-off-by: Steven Noonan <steven(a)uplinklabs.net> Signed-off-by: Ariadne Conill <ariadne(a)ariadne.space> CC: Yazen Ghannam <yazen.ghannam(a)amd.com> CC: x86(a)vger.kernel.org CC: stable(a)vger.kernel.org --- arch/x86/kernel/amd_node.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/kernel/amd_node.c b/arch/x86/kernel/amd_node.c index 3d0a4768d603c..cdc6ba224d4ad 100644 --- a/arch/x86/kernel/amd_node.c +++ b/arch/x86/kernel/amd_node.c @@ -282,6 +282,17 @@ static int __init amd_smn_init(void) return -ENODEV; num_nodes = amd_num_nodes(); + + if (!num_nodes) + return -ENODEV; + + /* Possibly a virtualized environment (e.g. Xen) where we wi ll get + * roots_per_node=0 if the number of roots is fewer than number of + * nodes + */ + if (num_roots < num_nodes) + return -ENODEV; + amd_roots = kcalloc(num_nodes, sizeof(*amd_roots), GFP_KERNEL); if (!amd_roots) return -ENOMEM; -- 2.51.2

1 week, 4 days

1
1
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 week, 4 days

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 week, 4 days

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 week, 4 days

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 week, 4 days

3
3
0 0

[PATCH] soc/tegra: fuse: Do not register SoC device on ACPI boot

by Kartik Rajput

On Tegra platforms using ACPI, the SMCCC driver already registers the SoC device. This makes the registration performed by the Tegra fuse driver redundant. When booted via ACPI, skip registering the SoC device and suppress printing SKU information from the Tegra fuse driver, as this information is already provided by the SMCCC driver. Fixes: 972167c69080 ("soc/tegra: fuse: Add ACPI support for Tegra194 and Tegra234") Cc: stable(a)vger.kernel.org Signed-off-by: Kartik Rajput <kkartik(a)nvidia.com> --- drivers/soc/tegra/fuse/fuse-tegra.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c b/drivers/soc/tegra/fuse/fuse-tegra.c index d27667283846..74d2fedea71c 100644 --- a/drivers/soc/tegra/fuse/fuse-tegra.c +++ b/drivers/soc/tegra/fuse/fuse-tegra.c @@ -182,8 +182,6 @@ static int tegra_fuse_probe(struct platform_device *pdev) } fuse->soc->init(fuse); - tegra_fuse_print_sku_info(&tegra_sku_info); - tegra_soc_device_register(); err = tegra_fuse_add_lookups(fuse); if (err) -- 2.43.0

1 week, 4 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror