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

[PATCH] powerpc/pasemi: Fix error handling in pasemi_dma_init

by Miaoqian Lin

Add missing pci_dev_put(iob_pdev) to drop the reference count obtained by pci_get_device() in case of error. Found via static analysis and code review. Fixes: 8ee9d8577935 ("pasemi: DMA engine management library") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/powerpc/platforms/pasemi/dma_lib.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/pasemi/dma_lib.c b/arch/powerpc/platforms/pasemi/dma_lib.c index 1be1f18f6f09..b824bfe97ce8 100644 --- a/arch/powerpc/platforms/pasemi/dma_lib.c +++ b/arch/powerpc/platforms/pasemi/dma_lib.c @@ -530,6 +530,7 @@ int pasemi_dma_init(void) BUG(); pr_warn("Can't find DMA controller\n"); err = -ENODEV; + pci_dev_put(iob_pdev); goto out; } dma_regs = map_onedev(dma_pdev, 0); -- 2.25.1

6 days, 18 hours

1
0
0 0

[PATCH] input: lkkbd: cancel pending work before freeing device

by Minseong Kim

lkkbd_interrupt() schedules lk->tq with schedule_work(), and the work handler lkkbd_reinit() dereferences the lkkbd structure and its serio/input_dev fields. lkkbd_disconnect() frees the lkkbd structure without cancelling this work, so the work can run after the structure has been freed, leading to a potential use-after-free. Cancel the pending work in lkkbd_disconnect() before unregistering and freeing the device, following the same pattern as sunkbd. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Minseong Kim <ii4gsp(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Minseong Kim <ii4gsp(a)gmail.com> --- drivers/input/keyboard/lkkbd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/input/keyboard/lkkbd.c b/drivers/input/keyboard/lkkbd.c index c035216dd27c..72c477aab1fc 100644 --- a/drivers/input/keyboard/lkkbd.c +++ b/drivers/input/keyboard/lkkbd.c @@ -684,6 +684,8 @@ static void lkkbd_disconnect(struct serio *serio) { struct lkkbd *lk = serio_get_drvdata(serio); + cancel_work_sync(&lk->tq); + input_get_device(lk->dev); input_unregister_device(lk->dev); serio_close(serio); -- 2.39.5

6 days, 18 hours

2
5
0 0

[tip: x86/urgent] 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/urgent branch of tip: Commit-ID: 4368a3b96c427ea3299be8cedb28684ba4157529 Gitweb: https://git.kernel.org/tip/4368a3b96c427ea3299be8cedb28684ba4157529 Author: Yazen Ghannam <yazen.ghannam(a)amd.com> AuthorDate: Tue, 11 Nov 2025 14:53:57 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Fri, 12 Dec 2025 09:38:30 +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> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> 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 f55ea3c..23190a7 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> @@ -236,20 +235,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++; }

6 days, 18 hours

1
0
0 0

[PATCH v4 0/2] Enable 1GHz OPP am335x-bonegreen-eco

by Kory Maincent (TI.com)

The vdd_mpu regulator maximum voltage was previously limited to 1.2985V, which prevented the CPU from reaching the 1GHz operating point. This limitation was put in place because voltage changes were not working correctly, causing the board to stall when attempting higher frequencies. Increase the maximum voltage to 1.3515V to allow the full 1GHz OPP to be used. Add a TPS65219 PMIC driver fixes that properly implement the LOCK register handling, to make voltage transitions work reliably. Changes in v4: - Move the registers unlock in the probe instead of a custom regmap write operation. - Link to v3: https://lore.kernel.org/r/20251112-fix_tps65219-v3-0-e49bab4c01ce@bootlin.c… Changes in v3: - Remove an unused variable - Link to v2: https://lore.kernel.org/r/20251106-fix_tps65219-v2-0-a7d608c4272f@bootlin.c… Changes in v2: - Setup a custom regmap_bus only for the TPS65214 instead of checking the chip_id every time reg_write is called. - Add the am335x-bonegreen-eco devicetree change in the same patch series. Signed-off-by: Kory Maincent (TI.com) <kory.maincent(a)bootlin.com> --- Kory Maincent (TI.com) (2): mfd: tps65219: Implement LOCK register handling for TPS65214 ARM: dts: am335x-bonegreen-eco: Enable 1GHz OPP by increasing vdd_mpu voltage arch/arm/boot/dts/ti/omap/am335x-bonegreen-eco.dts | 2 +- drivers/mfd/tps65219.c | 7 +++++++ include/linux/mfd/tps65219.h | 2 ++ 3 files changed, 10 insertions(+), 1 deletion(-) --- base-commit: 1c353dc8d962de652bc7ad2ba2e63f553331391c change-id: 20251106-fix_tps65219-dd62141d22cf Best regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com

6 days, 20 hours

5
7
0 0

[PATCH] spi: cadence-quadspi: Fix clock enable underflows due to runtime PM

by Mark Brown

The recent refactoring of where runtime PM is enabled done in commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") made the fact that when we do a pm_runtime_disable() in the error paths of probe() we can trigger a runtime disable which in turn results in duplicate clock disables. Early on in the probe function we do a pm_runtime_get_noresume() since the probe function leaves the device in a powered up state but in the error path we can't assume that PM is enabled so we also manually disable everything, including clocks. This means that when runtime PM is active both it and the probe function release the same reference to the main clock for the IP, triggering warnings from the clock subsystem: [ 8.693719] clk:75:7 already disabled [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb ... [ 8.694261] clk_core_disable+0xa0/0xb4 (P) [ 8.694272] clk_disable+0x38/0x60 [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi] [ 8.694309] platform_probe+0x5c/0xa4 Avoid this confused ownership by moving the pm_runtime_get_noresume() to after the last point at which the probe() function can fail. Reported-by: Francesco Dolcini <francesco(a)dolcini.it> Closes: https://lore.kernel.org/r/20251201072844.GA6785@francesco-nb Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/spi/spi-cadence-quadspi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-quadspi.c index af6d050da1c8..0833b6f666d0 100644 --- a/drivers/spi/spi-cadence-quadspi.c +++ b/drivers/spi/spi-cadence-quadspi.c @@ -1985,7 +1985,6 @@ static int cqspi_probe(struct platform_device *pdev) pm_runtime_enable(dev); pm_runtime_set_autosuspend_delay(dev, CQSPI_AUTOSUSPEND_TIMEOUT); pm_runtime_use_autosuspend(dev); - pm_runtime_get_noresume(dev); } ret = cqspi_setup_flash(cqspi); @@ -2012,6 +2011,7 @@ static int cqspi_probe(struct platform_device *pdev) } if (!(ddata && (ddata->quirks & CQSPI_DISABLE_RUNTIME_PM))) { + pm_runtime_get_noresume(dev); pm_runtime_mark_last_busy(dev); pm_runtime_put_autosuspend(dev); } --- base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449 change-id: 20251202-spi-cadence-qspi-runtime-pm-imbalance-657740cf7eae Best regards, -- Mark Brown <broonie(a)kernel.org>

6 days, 20 hours

5
18
0 0

[PATCH v2 1/4] mm/hugetlb: fix hugetlb_pmd_shared()

by David Hildenbrand (Red Hat)

We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->pt_share_count to identify sharing. We didn't convert hugetlb_pmd_shared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table. Page migration, like mbind() or migrate_pages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the pagemap interface. Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared(). Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count") Reviewed-by: Rik van Riel <riel(a)surriel.com> Reviewed-by: Lance Yang <lance.yang(a)linux.dev> Tested-by: Lance Yang <lance.yang(a)linux.dev> Reviewed-by: Harry Yoo <harry.yoo(a)oracle.com> Tested-by: Laurence Oberman <loberman(a)redhat.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Acked-by: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Cc: Liu Shixin <liushixin2(a)huawei.com> Signed-off-by: David Hildenbrand (Red Hat) <david(a)kernel.org> --- include/linux/hugetlb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 019a1c5281e4e..03c8725efa289 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -1326,7 +1326,7 @@ static inline __init void hugetlb_cma_reserve(int order) #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING static inline bool hugetlb_pmd_shared(pte_t *pte) { - return page_count(virt_to_page(pte)) > 1; + return ptdesc_pmd_is_shared(virt_to_ptdesc(pte)); } #else static inline bool hugetlb_pmd_shared(pte_t *pte) -- 2.52.0

6 days, 20 hours

1
0
0 0

[PATCH AUTOSEL 6.18-5.10] alpha: don't reference obsolete termio struct for TC* constants

by Sasha Levin

From: Sam James <sam(a)gentoo.org> [ Upstream commit 9aeed9041929812a10a6d693af050846942a1d16 ] Similar in nature to ab107276607af90b13a5994997e19b7b9731e251. glibc-2.42 drops the legacy termio struct, but the ioctls.h header still defines some TC* constants in terms of termio (via sizeof). Hardcode the values instead. This fixes building Python for example, which falls over like: ./Modules/termios.c:1119:16: error: invalid application of 'sizeof' to incomplete type 'struct termio' Link: https://bugs.gentoo.org/961769 Link: https://bugs.gentoo.org/962600 Signed-off-by: Sam James <sam(a)gentoo.org> Reviewed-by: Magnus Lindholm <linmag7(a)gmail.com> Link: https://lore.kernel.org/r/6ebd3451908785cad53b50ca6bc46cfe9d6bc03c.17649224… Signed-off-by: Magnus Lindholm <linmag7(a)gmail.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Analysis Summary ### 1. COMMIT MESSAGE ANALYSIS This commit addresses a **userspace build failure** caused by glibc-2.42 removing the legacy `struct termio` definition. The kernel's uapi header `arch/alpha/include/uapi/asm/ioctls.h` uses `sizeof(struct termio)` in macro expansions, which fails when that struct is undefined. **Key signals:** - Links to two real bug reports (Gentoo bugs #961769 and #962600) - References a prior fix (ab107276607af) for powerpc with the exact same issue - Has `Reviewed-by:` tag - Demonstrates real-world impact: Python build failure ### 2. CODE CHANGE ANALYSIS **What the change does:** ```c // Before: Uses sizeof(struct termio) in macro expansion #define TCGETA _IOR('t', 23, struct termio) // After: Pre-computed constant #define TCGETA 0x40127417 ``` **Verification of the hardcoded values:** Looking at `arch/alpha/include/uapi/asm/ioctl.h`, the ioctl encoding on alpha is: - `_IOC_SIZESHIFT` = 16, `_IOC_DIRSHIFT` = 29 - `_IOC_READ` = 2, `_IOC_WRITE` = 4 For `TCGETA = _IOR('t', 23, struct termio)`: - dir=2, type=0x74, nr=0x17, size=18(0x12) - Result: `(2<<29)|(0x74<<8)|(0x17)|(0x12<<16)` = **0x40127417** ✓ The hardcoded values are mathematically correct. ### 3. CLASSIFICATION **Category: BUILD FIX** This falls under the **build fixes** exception category - it's critical for users who need to build userspace software with modern glibc. Other architectures (powerpc, sh, xtensa) already have identical fixes in the tree. ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed:** 4 - **Files touched:** 1 (alpha-specific uapi header) - **Risk: EXTREMELY LOW** - No runtime behavior change - only affects compilation - The ioctl numbers are identical (pre-computed vs macro-computed) - Pattern already established in other architectures ### 5. USER IMPACT - **Affected users:** Anyone on alpha using glibc 2.42+ (e.g., Gentoo users) - **Severity:** Critical for affected users - cannot build Python, and potentially many other programs that use termios - **Scope:** Limited to alpha architecture, but complete blocker for those users ### 6. STABILITY INDICATORS - Has `Reviewed-by:` tag - Same pattern accepted for powerpc (commit ab107276607af) - Documented with actual bug reports showing real users affected - No runtime changes - purely compile-time fix ### 7. DEPENDENCY CHECK - **No dependencies** - standalone fix - The affected file exists in all stable trees (uapi header) - Clean application expected ### Final Assessment **Pros:** - Fixes a real, documented build breakage with modern glibc - Extremely small and localized (4 lines, 1 file) - Zero runtime risk - mathematically equivalent values - Established precedent with powerpc fix - Has review tag and bug report links **Cons:** - No explicit `Cc: stable(a)vger.kernel.org` tag - Alpha is a niche architecture **Verdict:** This is textbook stable material. It's a build fix that: 1. Is obviously correct (values are mathematically equivalent) 2. Fixes a real bug (complete build failure) 3. Is small and contained (4 lines) 4. Has no runtime risk whatsoever 5. Follows established precedent from other architectures The lack of a stable tag is not disqualifying - many valid stable patches don't have it. Build compatibility with modern toolchains is exactly what stable trees need to maintain. **YES** arch/alpha/include/uapi/asm/ioctls.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/alpha/include/uapi/asm/ioctls.h b/arch/alpha/include/uapi/asm/ioctls.h index 971311605288f..a09d04b49cc65 100644 --- a/arch/alpha/include/uapi/asm/ioctls.h +++ b/arch/alpha/include/uapi/asm/ioctls.h @@ -23,10 +23,10 @@ #define TCSETSW _IOW('t', 21, struct termios) #define TCSETSF _IOW('t', 22, struct termios) -#define TCGETA _IOR('t', 23, struct termio) -#define TCSETA _IOW('t', 24, struct termio) -#define TCSETAW _IOW('t', 25, struct termio) -#define TCSETAF _IOW('t', 28, struct termio) +#define TCGETA 0x40127417 +#define TCSETA 0x80127418 +#define TCSETAW 0x80127419 +#define TCSETAF 0x8012741c #define TCSBRK _IO('t', 29) #define TCXONC _IO('t', 30) -- 2.51.0

6 days, 21 hours

1
4
0 0

[PATCH 5.15] drm/i915/selftests: fix subtraction overflow bug

by Rajani Kantha

From: Andrzej Hajda <andrzej.hajda(a)intel.com> [ Upstream commit ab3edc679c552a466e4bf0b11af3666008bd65a2 ] On some machines hole_end can be small enough to cause subtraction overflow. On the other side (addr + 2 * min_alignment) can overflow in case of mock tests. This patch should handle both cases. Fixes: e1c5f754067b59 ("drm/i915: Avoid overflow in computing pot_hole loop termination") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3674 Signed-off-by: Andrzej Hajda <andrzej.hajda(a)intel.com> Reviewed-by: Andi Shyti <andi.shyti(a)linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti(a)linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624113528.2159210-1-andr… Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> [ Using I915_GTT_PAGE_SIZE instead of min_alignment due to 5.15 missing commit:87bd701ee268 ("drm/i915: enforce min GTT alignment for discrete cards")] Signed-off-by: Rajani Kantha <681739313(a)139.com> --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index df3934a990d0..cd0494b84959 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -715,7 +715,7 @@ static int pot_hole(struct i915_address_space *vm, u64 addr; for (addr = round_up(hole_start + I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE; - addr <= round_down(hole_end - 2*I915_GTT_PAGE_SIZE, step) - I915_GTT_PAGE_SIZE; + hole_end > addr && hole_end - addr >= 2 * I915_GTT_PAGE_SIZE; addr += step) { err = i915_vma_pin(vma, 0, 0, addr | flags); if (err) { -- 2.17.1

6 days, 21 hours

1
0
0 0

[PATCH v5.10.y] bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself

by HarinadhD

From: Jakub Sitnicki <jakub(a)cloudflare.com> [ Upstream commit 5b4a79ba65a1ab479903fff2e604865d229b70a9 ] sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ Suggested-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Jakub Sitnicki <jakub(a)cloudflare.com> Acked-by: John Fastabend <john.fastabend(a)gmail.com> Link: https://lore.kernel.org/r/20230113-sockmap-fix-v2-1-1e0ee7ac2f90@cloudflare… Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [ Harinadh: Modified to apply on v5.10.y ] Signed-off-by: HarinadhD <Harinadh.Dommaraju(a)broadcom.com> --- net/core/sock_map.c | 53 +++++++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 23 deletions(-) diff --git a/net/core/sock_map.c b/net/core/sock_map.c index 3a9e0046a780..438bbef5ff75 100644 --- a/net/core/sock_map.c +++ b/net/core/sock_map.c @@ -1558,15 +1558,16 @@ void sock_map_unhash(struct sock *sk) psock = sk_psock(sk); if (unlikely(!psock)) { rcu_read_unlock(); - if (sk->sk_prot->unhash) - sk->sk_prot->unhash(sk); - return; + saved_unhash = READ_ONCE(sk->sk_prot)->unhash; + } else { + saved_unhash = psock->saved_unhash; + sock_map_remove_links(sk, psock); + rcu_read_unlock(); } - - saved_unhash = psock->saved_unhash; - sock_map_remove_links(sk, psock); - rcu_read_unlock(); - saved_unhash(sk); + if (WARN_ON_ONCE(saved_unhash == sock_map_unhash)) + return; + if (saved_unhash) + saved_unhash(sk); } void sock_map_destroy(struct sock *sk) @@ -1578,16 +1579,17 @@ void sock_map_destroy(struct sock *sk) psock = sk_psock_get(sk); if (unlikely(!psock)) { rcu_read_unlock(); - if (sk->sk_prot->destroy) - sk->sk_prot->destroy(sk); - return; + saved_destroy = READ_ONCE(sk->sk_prot)->destroy; + } else { + saved_destroy = psock->saved_destroy; + sock_map_remove_links(sk, psock); + rcu_read_unlock(); + sk_psock_put(sk, psock); } - - saved_destroy = psock->saved_destroy; - sock_map_remove_links(sk, psock); - rcu_read_unlock(); - sk_psock_put(sk, psock); - saved_destroy(sk); + if (WARN_ON_ONCE(saved_destroy == sock_map_destroy)) + return; + if (saved_destroy) + saved_destroy(sk); } EXPORT_SYMBOL_GPL(sock_map_destroy); @@ -1602,13 +1604,18 @@ void sock_map_close(struct sock *sk, long timeout) if (unlikely(!psock)) { rcu_read_unlock(); release_sock(sk); - return sk->sk_prot->close(sk, timeout); + saved_close = READ_ONCE(sk->sk_prot)->close; + } else { + saved_close = psock->saved_close; + sock_map_remove_links(sk, psock); + rcu_read_unlock(); + release_sock(sk); } - - saved_close = psock->saved_close; - sock_map_remove_links(sk, psock); - rcu_read_unlock(); - release_sock(sk); + /* Make sure we do not recurse. This is a bug. + * Leak the socket instead of crashing on a stack overflow. + */ + if (WARN_ON_ONCE(saved_close == sock_map_close)) + return; saved_close(sk, timeout); } -- 2.43.7

6 days, 23 hours

1
0
0 0

[PATCH 1/1] phy: tegra: xusb: Explicitly configure HS_DISCON_LEVEL to 0x7

by Wayne Chang

The USB2 Bias Pad Control register manages analog parameters for signal detection. Previously, the HS_DISCON_LEVEL relied on hardware reset values, which may lead to the detection failure. Explicitly configure HS_DISCON_LEVEL to 0x7. This ensures the disconnect threshold is sufficient to guarantee reliable detection. Fixes: bbf711682cd5 ("phy: tegra: xusb: Add Tegra186 support") Cc: stable(a)vger.kernel.org Signed-off-by: Wayne Chang <waynec(a)nvidia.com> --- drivers/phy/tegra/xusb-tegra186.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/phy/tegra/xusb-tegra186.c b/drivers/phy/tegra/xusb-tegra186.c index e818f6c3980e..bec9616c4a2e 100644 --- a/drivers/phy/tegra/xusb-tegra186.c +++ b/drivers/phy/tegra/xusb-tegra186.c @@ -84,6 +84,7 @@ #define XUSB_PADCTL_USB2_BIAS_PAD_CTL0 0x284 #define BIAS_PAD_PD BIT(11) #define HS_SQUELCH_LEVEL(x) (((x) & 0x7) << 0) +#define HS_DISCON_LEVEL(x) (((x) & 0x7) << 3) #define XUSB_PADCTL_USB2_BIAS_PAD_CTL1 0x288 #define USB2_TRK_START_TIMER(x) (((x) & 0x7f) << 12) @@ -623,6 +624,8 @@ static void tegra186_utmi_bias_pad_power_on(struct tegra_xusb_padctl *padctl) value &= ~BIAS_PAD_PD; value &= ~HS_SQUELCH_LEVEL(~0); value |= HS_SQUELCH_LEVEL(priv->calib.hs_squelch); + value &= ~HS_DISCON_LEVEL(~0); + value |= HS_DISCON_LEVEL(0x7); padctl_writel(padctl, value, XUSB_PADCTL_USB2_BIAS_PAD_CTL0); udelay(1); -- 2.25.1

1 week

1
0
0 0

[PATCH v2 4/5] media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors

by Hans de Goede

The Dell XPS 13 9350 and XPS 16 9640 both have an upside-down mounted OV02C10 sensor. This rotation of 180° is reported in neither the SSDB nor the _PLD for the sensor (both report a rotation of 0°). Add a DMI quirk mechanism for upside-down sensors and add 2 initial entries to the DMI quirk list for these 2 laptops. Note the OV02C10 driver was originally developed on a XPS 16 9640 which resulted in inverted vflip + hflip settings making it look like the sensor was upright on the XPS 16 9640 and upside down elsewhere this has been fixed in commit 69fe27173396 ("media: ov02c10: Fix default vertical flip"). This makes this commit a regression fix since now the video is upside down on these Dell XPS models where it was not before. Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip") Cc: stable(a)vger.kernel.org Reviewed-by: Bryan O'Donoghue <bod(a)kernel.org> Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- Changes in v2: - Fix fixes tag to use the correct commit hash - Drop || COMPILE_TEST from Kconfig to fix compile errors when ACPI is disabled --- drivers/media/pci/intel/Kconfig | 2 +- drivers/media/pci/intel/ipu-bridge.c | 29 ++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/intel/Kconfig b/drivers/media/pci/intel/Kconfig index d9fcddce028b..3f14ca110d06 100644 --- a/drivers/media/pci/intel/Kconfig +++ b/drivers/media/pci/intel/Kconfig @@ -6,7 +6,7 @@ source "drivers/media/pci/intel/ivsc/Kconfig" config IPU_BRIDGE tristate "Intel IPU Bridge" - depends on ACPI || COMPILE_TEST + depends on ACPI depends on I2C help The IPU bridge is a helper library for Intel IPU drivers to diff --git a/drivers/media/pci/intel/ipu-bridge.c b/drivers/media/pci/intel/ipu-bridge.c index 58ea01d40c0d..6463b2a47d78 100644 --- a/drivers/media/pci/intel/ipu-bridge.c +++ b/drivers/media/pci/intel/ipu-bridge.c @@ -5,6 +5,7 @@ #include <acpi/acpi_bus.h> #include <linux/cleanup.h> #include <linux/device.h> +#include <linux/dmi.h> #include <linux/i2c.h> #include <linux/mei_cl_bus.h> #include <linux/platform_device.h> @@ -99,6 +100,28 @@ static const struct ipu_sensor_config ipu_supported_sensors[] = { IPU_SENSOR_CONFIG("XMCC0003", 1, 321468000), }; +/* + * DMI matches for laptops which have their sensor mounted upside-down + * without reporting a rotation of 180° in neither the SSDB nor the _PLD. + */ +static const struct dmi_system_id upside_down_sensor_dmi_ids[] = { + { + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 13 9350"), + }, + .driver_data = "OVTI02C1", + }, + { + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "XPS 16 9640"), + }, + .driver_data = "OVTI02C1", + }, + {} /* Terminating entry */ +}; + static const struct ipu_property_names prop_names = { .clock_frequency = "clock-frequency", .rotation = "rotation", @@ -249,6 +272,12 @@ static int ipu_bridge_read_acpi_buffer(struct acpi_device *adev, char *id, static u32 ipu_bridge_parse_rotation(struct acpi_device *adev, struct ipu_sensor_ssdb *ssdb) { + const struct dmi_system_id *dmi_id; + + dmi_id = dmi_first_match(upside_down_sensor_dmi_ids); + if (dmi_id && acpi_dev_hid_match(adev, dmi_id->driver_data)) + return 180; + switch (ssdb->degree) { case IPU_SENSOR_ROTATION_NORMAL: return 0; -- 2.52.0

1 week

2
1
0 0

[PATCH v2 3/5] media: ov02c10: Fix the horizontal flip control

by Hans de Goede

During sensor calibration I noticed that with the hflip control set to false/disabled the image was mirrored. The horizontal flip control is inverted and needs to be set to 1 to not flip. This is something which seems to be common with various recent Omnivision sensors, the ov01a10 and ov08x40 also have an inverted mirror control. Invert the hflip control to fix the sensor mirroring by default. Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip") Cc: stable(a)vger.kernel.org Cc: Sebastian Reichel <sre(a)kernel.org> Reviewed-by: Bryan O'Donoghue <bod(a)kernel.org> Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- drivers/media/i2c/ov02c10.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c index 384c2f0b1608..f912ae142040 100644 --- a/drivers/media/i2c/ov02c10.c +++ b/drivers/media/i2c/ov02c10.c @@ -170,7 +170,7 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = { {0x3816, 0x01}, {0x3817, 0x01}, - {0x3820, 0xa0}, + {0x3820, 0xa8}, {0x3821, 0x00}, {0x3822, 0x80}, {0x3823, 0x08}, @@ -462,9 +462,9 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl) case V4L2_CID_HFLIP: cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL, - ctrl->val ? 1 : 2, &ret); + ctrl->val ? 2 : 1, &ret); cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL, - BIT(3), ov02c10->hflip->val << 3, &ret); + BIT(3), ctrl->val ? 0 : BIT(3), &ret); break; case V4L2_CID_VFLIP: -- 2.52.0

1 week

2
1
0 0

[PATCH v2 2/5] media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern

by Hans de Goede

The ov02c10 is capable of having its (crop) window shifted around with 1 pixel precision while streaming. This allows changing the x/y window coordinates when changing flipping to preserve the bayer-pattern. __v4l2_ctrl_handler_setup() will now write the window coordinates at 0x3810 and 0x3812 so these can be dropped from sensor_1928x1092_30fps_setting. Since the bayer-pattern is now unchanged, the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag can be dropped from the flip controls. Note the original use of the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag was incomplete, besides setting the flag the driver should also have reported a different mbus code when getting the source pad's format depending on the hflip / vflip settings see the ov2680.c driver for example. Fixes: b7cd2ba3f692 ("media: ov02c10: Support hflip and vflip") Cc: stable(a)vger.kernel.org Cc: Sebastian Reichel <sre(a)kernel.org> Reviewed-by: Bryan O'Donoghue <bod(a)kernel.org> Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- drivers/media/i2c/ov02c10.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c index 6369841de88b..384c2f0b1608 100644 --- a/drivers/media/i2c/ov02c10.c +++ b/drivers/media/i2c/ov02c10.c @@ -165,10 +165,6 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = { {0x3809, 0x88}, {0x380a, 0x04}, {0x380b, 0x44}, - {0x3810, 0x00}, - {0x3811, 0x02}, - {0x3812, 0x00}, - {0x3813, 0x01}, {0x3814, 0x01}, {0x3815, 0x01}, {0x3816, 0x01}, @@ -465,11 +461,15 @@ static int ov02c10_set_ctrl(struct v4l2_ctrl *ctrl) break; case V4L2_CID_HFLIP: + cci_write(ov02c10->regmap, OV02C10_ISP_X_WIN_CONTROL, + ctrl->val ? 1 : 2, &ret); cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL, BIT(3), ov02c10->hflip->val << 3, &ret); break; case V4L2_CID_VFLIP: + cci_write(ov02c10->regmap, OV02C10_ISP_Y_WIN_CONTROL, + ctrl->val ? 2 : 1, &ret); cci_update_bits(ov02c10->regmap, OV02C10_ROTATE_CONTROL, BIT(4), ov02c10->vflip->val << 4, &ret); break; @@ -551,13 +551,9 @@ static int ov02c10_init_controls(struct ov02c10 *ov02c10) ov02c10->hflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops, V4L2_CID_HFLIP, 0, 1, 1, 0); - if (ov02c10->hflip) - ov02c10->hflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT; ov02c10->vflip = v4l2_ctrl_new_std(ctrl_hdlr, &ov02c10_ctrl_ops, V4L2_CID_VFLIP, 0, 1, 1, 0); - if (ov02c10->vflip) - ov02c10->vflip->flags |= V4L2_CTRL_FLAG_MODIFY_LAYOUT; v4l2_ctrl_new_std_menu_items(ctrl_hdlr, &ov02c10_ctrl_ops, V4L2_CID_TEST_PATTERN, -- 2.52.0

1 week

2
1
0 0

[PATCH AUTOSEL 6.18-5.15] platform/x86/intel/hid: Add Dell Pro Rugged 10/12 tablet to VGBS DMI quirks

by Sasha Levin

From: "Chia-Lin Kao (AceLan)" <acelan.kao(a)canonical.com> [ Upstream commit b169e1733cadb614e87f69d7a5ae1b186c50d313 ] Dell Pro Rugged 10/12 tablets has a reliable VGBS method. If VGBS is not called on boot, the on-screen keyboard won't appear if the device is booted without a keyboard. Call VGBS on boot on thess devices to get the initial state of SW_TABLET_MODE in a reliable way. Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao(a)canonical.com> Reviewed-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> Link: https://patch.msgid.link/20251127070407.656463-1-acelan.kao@canonical.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Summary Analysis ### What This Commit Does This commit adds two Dell tablet models (Dell Pro Rugged 10 Tablet RA00260 and Dell Pro Rugged 12 Tablet RA02260) to the `dmi_vgbs_allow_list` DMI quirk table. When a device matches this list, the driver calls the VGBS ACPI method at probe time to properly detect the initial SW_TABLET_MODE state. ### The Bug Being Fixed Without this quirk, on these Dell tablets: - The VGBS method isn't called at boot - The kernel doesn't know the device is in tablet mode - The on-screen keyboard won't appear if the device is booted without a physical keyboard attached - This makes the device difficult/impossible to use in tablet-only mode ### Classification: Hardware Quirk/Workaround This falls squarely into the **QUIRKS and WORKAROUNDS** category which is explicitly allowed for stable backporting: - It's a DMI-based allowlist entry for specific hardware models - The pattern is identical to existing entries (HP Spectre, Microsoft Surface Go, HP Dragonfly G2) - The mechanism has been stable since Linux 5.10 ### Risk Assessment **Risk Level: EXTREMELY LOW** - **Lines changed**: ~12 lines (just two DMI match entries) - **Files touched**: 1 file - **Scope**: Only affects Dell Pro Rugged 10/12 tablets - **Cannot regress other hardware**: DMI matching is device-specific - **Pattern proven**: Same structure as existing entries that have worked for years ### Stability Indicators - **Reviewed-by:** Hans de Goede (well-known x86 platform maintainer) - **Reviewed-by:** Ilpo Järvinen (Intel platform maintainer) - The `dmi_vgbs_allow_list` infrastructure has existed since v5.10-rc1 (commit 537b0dd4729e7) ### Stable Tree Criteria Assessment | Criterion | Status | |-----------|--------| | Obviously correct | ✅ Yes - trivial data addition | | Fixes real bug | ✅ Yes - on-screen keyboard not working | | Small and contained | ✅ Yes - ~12 lines in 1 file | | No new features | ✅ Yes - enables existing functionality | | Applies cleanly | ✅ Yes - simple addition to allowlist | ### Concerns 1. **No explicit "Cc: stable" tag** - However, DMI quirk additions are commonly appropriate for stable even without explicit tags 2. **No "Fixes:" tag** - This is adding new device support rather than fixing a regression in existing code ### Verdict This commit is appropriate for stable backporting because: 1. It's a minimal, surgical hardware quirk that only affects two specific Dell tablet models 2. It fixes a real usability issue for affected users (tablet becomes difficult to use without keyboard) 3. Zero risk of regression for any other hardware 4. The pattern exactly matches existing stable entries 5. The infrastructure has been stable since v5.10, available in all current LTS kernels 6. Well-reviewed by experienced platform maintainers The lack of explicit stable tags is not disqualifying - this is a textbook example of a hardware quirk addition that should go to stable trees to enable proper device functionality. **YES** drivers/platform/x86/intel/hid.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/platform/x86/intel/hid.c b/drivers/platform/x86/intel/hid.c index 9c07a7faf18fe..560cc063198e1 100644 --- a/drivers/platform/x86/intel/hid.c +++ b/drivers/platform/x86/intel/hid.c @@ -177,6 +177,18 @@ static const struct dmi_system_id dmi_vgbs_allow_list[] = { DMI_MATCH(DMI_PRODUCT_NAME, "HP Elite Dragonfly G2 Notebook PC"), }, }, + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Dell Pro Rugged 10 Tablet RA00260"), + }, + }, + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "Dell Pro Rugged 12 Tablet RA02260"), + }, + }, { } }; -- 2.51.0

1 week

1
7
0 0

[PATCH AUTOSEL 6.18-6.12] clk: qcom: dispcc-sm7150: Fix dispcc_mdss_pclk0_clk_src

by Sasha Levin

From: Jens Reidel <adrian(a)mainlining.org> [ Upstream commit e3c13e0caa8ceb7dec1a7c4fcfd9dbef56a69fbe ] Set CLK_OPS_PARENT_ENABLE to ensure the parent gets prepared and enabled when switching to it, fixing an "rcg didn't update its configuration" warning. Signed-off-by: Jens Reidel <adrian(a)mainlining.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250919-sm7150-dispcc-fixes-v1-3-308ad47c5fce@ma… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ### 3. Technical Understanding The `CLK_OPS_PARENT_ENABLE` flag (BIT(12) in clk-provider.h) ensures that "parents need enable during gate/ungate, set rate and re-parent." Without this flag, when the pixel clock source tries to switch to a new parent clock, the parent might not be enabled, causing the RCG (Root Clock Generator) to fail to update its configuration. This is a well-known pattern in Qualcomm clock drivers - pixel clocks dynamically switch parents during display panel initialization, and the parent must be running for the configuration switch to complete. ### 4. Scope and Risk Assessment - **Lines changed**: 1 line (adding a single flag) - **Files touched**: 1 file - **Complexity**: Very low - **Risk**: Very low - this is an established pattern used across many Qualcomm dispcc/gcc drivers ### 5. User Impact - Affects SM7150-based devices (mobile phones) - The warning indicates clock configuration issues that could affect display initialization - Limited scope - only SM7150 platform users ### 6. Stable Tree Applicability - Driver was added in **v6.11** (commit 3829c412197e1) - Only applicable to v6.11.y, v6.12.y, and newer stable trees - NOT applicable to LTS kernels: 6.6.y, 6.1.y, 5.15.y (driver doesn't exist) ### 7. Key Observations **Against backporting:** 1. **No "Cc: stable(a)vger.kernel.org" tag** - The maintainers did not request stable backport 2. **No "Fixes:" tag** - Doesn't reference the original commit where the bug was introduced 3. **Very new driver** - SM7150 dispcc was added in v6.11, limiting stable applicability 4. **Not a critical issue** - A warning message, not a crash, panic, or data corruption 5. **Mobile SoC** - Users running stable kernels rarely use cutting-edge mobile phone support **For backporting:** 1. Valid bug fix with proven pattern 2. Extremely small and low-risk change 3. Has proper review from Qualcomm clock maintainers drivers/clk/qcom/dispcc-sm7150.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/qcom/dispcc-sm7150.c b/drivers/clk/qcom/dispcc-sm7150.c index bdfff246ed3fe..ddc7230b8aea7 100644 --- a/drivers/clk/qcom/dispcc-sm7150.c +++ b/drivers/clk/qcom/dispcc-sm7150.c @@ -356,7 +356,7 @@ static struct clk_rcg2 dispcc_mdss_pclk0_clk_src = { .name = "dispcc_mdss_pclk0_clk_src", .parent_data = dispcc_parent_data_4, .num_parents = ARRAY_SIZE(dispcc_parent_data_4), - .flags = CLK_SET_RATE_PARENT, + .flags = CLK_SET_RATE_PARENT | CLK_OPS_PARENT_ENABLE, .ops = &clk_pixel_ops, }, }; -- 2.51.0

1 week

1
0
0 0

[PATCH v2 1/5] media: ov02c10: Fix bayer-pattern change after default vflip change

by Hans de Goede

After commit d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip") the reported bayer-pattern of MEDIA_BUS_FMT_SGRBG10_1X10 is no longer correct. Change the 16-bit x-win register (0x3810) value from 2 to 1 so that the sensor will generate data in GRBG bayer-order again. Fixes: d5ebe3f7d13d ("media: ov02c10: Fix default vertical flip") Cc: stable(a)vger.kernel.org Cc: Sebastian Reichel <sre(a)kernel.org> Reviewed-by: Bryan O'Donoghue <bod(a)kernel.org> Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- drivers/media/i2c/ov02c10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov02c10.c b/drivers/media/i2c/ov02c10.c index b1e540eb8326..6369841de88b 100644 --- a/drivers/media/i2c/ov02c10.c +++ b/drivers/media/i2c/ov02c10.c @@ -168,7 +168,7 @@ static const struct reg_sequence sensor_1928x1092_30fps_setting[] = { {0x3810, 0x00}, {0x3811, 0x02}, {0x3812, 0x00}, - {0x3813, 0x02}, + {0x3813, 0x01}, {0x3814, 0x01}, {0x3815, 0x01}, {0x3816, 0x01}, -- 2.52.0

1 week

2
1
0 0

[PATCH] tracing: Fix error handling in event_hist_trigger_parse

by Miaoqian Lin

Memory allocated with trigger_data_alloc() require trigger_data_free() for proper cleanup. Replace kfree() with trigger_data_free() to fix this. Found via static analysis and code review. Fixes: e1f187d09e11 ("tracing: Have existing event_command.parse() implementations use helpers") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- kernel/trace/trace_events_hist.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index 5e6e70540eef..f9886fff7123 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -6902,7 +6902,7 @@ static int event_hist_trigger_parse(struct event_command *cmd_ops, remove_hist_vars(hist_data); - kfree(trigger_data); + trigger_data_free(trigger_data); destroy_hist_data(hist_data); goto out; -- 2.25.1

1 week

2
1
0 0

[PATCH v2] usb: dwc3: gadget: Prevent EPs resource conflict during StartTransfer

by Selvarasu Ganesan

The below “No resource for ep” warning appears when a StartTransfer command is issued for bulk or interrupt endpoints in `dwc3_gadget_ep_enable` while a previous StartTransfer on the same endpoint is still in progress. The gadget functions drivers can invoke `usb_ep_enable` (which triggers a new StartTransfer command) before the earlier transfer has completed. Because the previous StartTransfer is still active, `dwc3_gadget_ep_disable` can skip the required `EndTransfer` due to `DWC3_EP_DELAY_STOP`, leading to the endpoint resources are busy for previous StartTransfer and warning ("No resource for ep") from dwc3 driver. To resolve this, a check is added to `dwc3_gadget_ep_enable` that checks the `DWC3_EP_TRANSFER_STARTED` flag before issuing a new StartTransfer. By preventing a second StartTransfer on an already busy endpoint, the resource conflict is eliminated, the warning disappears, and potential kernel panics caused by `panic_on_warn` are avoided. ------------[ cut here ]------------ dwc3 13200000.dwc3: No resource for ep1out WARNING: CPU: 0 PID: 700 at drivers/usb/dwc3/gadget.c:398 dwc3_send_gadget_ep_cmd+0x2f8/0x76c Call trace: dwc3_send_gadget_ep_cmd+0x2f8/0x76c __dwc3_gadget_ep_enable+0x490/0x7c0 dwc3_gadget_ep_enable+0x6c/0xe4 usb_ep_enable+0x5c/0x15c mp_eth_stop+0xd4/0x11c __dev_close_many+0x160/0x1c8 __dev_change_flags+0xfc/0x220 dev_change_flags+0x24/0x70 devinet_ioctl+0x434/0x524 inet_ioctl+0xa8/0x224 sock_do_ioctl+0x74/0x128 sock_ioctl+0x3bc/0x468 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x38/0x88 el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac Fixes: a97ea994605e ("usb: dwc3: gadget: offset Start Transfer latency for bulk EPs") Cc: stable(a)vger.kernel.org Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Removed change-id. - Updated commit message. Link to v1: https://lore.kernel.org/linux-usb/20251117152812.622-1-selvarasu.g@samsung.… --- drivers/usb/dwc3/gadget.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 1f67fb6aead5..8d3caa71ea12 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -963,8 +963,9 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep, unsigned int action) * Issue StartTransfer here with no-op TRB so we can always rely on No * Response Update Transfer command. */ - if (usb_endpoint_xfer_bulk(desc) || - usb_endpoint_xfer_int(desc)) { + if ((usb_endpoint_xfer_bulk(desc) || + usb_endpoint_xfer_int(desc)) && + !(dep->flags & DWC3_EP_TRANSFER_STARTED)) { struct dwc3_gadget_ep_cmd_params params; struct dwc3_trb *trb; dma_addr_t trb_dma; -- 2.34.1

1 week

3
18
0 0

[PATCH v2] wifi: mt76: mt7925: fix AMPDU state handling in mt7925_tx_check_aggr

by Quan Zhou

Previously, the AMPDU state bit for a given TID was set before attempting to start a BA session, which could result in the AMPDU state being marked active even if ieee80211_start_tx_ba_session() failed. This patch changes the logic to only set the AMPDU state bit after successfully starting a BA session, ensuring proper synchronization between AMPDU state and BA session status. This fixes potential issues with aggregation state tracking and improves compatibility with mac80211 BA session management. Fixes: 44eb173bdd4f ("wifi: mt76: mt7925: add link handling in mt7925_txwi_free") Cc: stable(a)vger.kernel.org Signed-off-by: Quan Zhou <quan.zhou(a)mediatek.com> --- v2: modify to avoid weakening atomicity --- drivers/net/wireless/mediatek/mt76/mt7925/mac.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c index 871b67101976..5e5b1df78633 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mac.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mac.c @@ -881,8 +881,10 @@ static void mt7925_tx_check_aggr(struct ieee80211_sta *sta, struct sk_buff *skb, else mlink = &msta->deflink; - if (!test_and_set_bit(tid, &mlink->wcid.ampdu_state)) - ieee80211_start_tx_ba_session(sta, tid, 0); + if (!test_and_set_bit(tid, &mlink->wcid.ampdu_state)) { + if (ieee80211_start_tx_ba_session(sta, tid, 0)) + clear_bit(tid, &mlink->wcid.ampdu_state); + } } static bool -- 2.45.2

1 week

2
1
0 0

[PATCH 1/2] btrfs: fix beyond-EOF write handling

by Qu Wenruo

[BUG] For the following write sequence with 64K page size and 4K fs block size, it will lead to file extent items to be inserted without any data checksum: mkfs.btrfs -s 4k -f $dev > /dev/null mount $dev $mnt xfs_io -f -c "pwrite 0 16k" -c "pwrite 32k 4k" -c pwrite "60k 64K" \ -c "truncate 16k" $mnt/foobar umount $mnt This will result the following 2 file extent items to be inserted (extra trace point added to insert_ordered_extent_file_extent()): btrfs_finish_one_ordered: root=5 ino=257 file_off=61440 num_bytes=4096 csum_bytes=0 btrfs_finish_one_ordered: root=5 ino=257 file_off=0 num_bytes=16384 csum_bytes=16384 Note for file offset 60K, we're inserting an file extent without any data checksum. Also note that range [32K, 36K) didn't reach insert_ordered_extent_file_extent(), which is the correct behavior as that OE is fully truncated, should not result any file extent. Although file extent at 60K will be later dropped by btrfs_truncate(), if the transaction got committed after file extent inserted but before the file extent dropping, we will have a small window where we have a file extent beyond EOF and without any data checksum. That will cause "btrfs check" to report error. [CAUSE] The sequence happens like this: - Buffered write dirtied the page cache and updated isize Now the inode size is 64K, with the following page cache layout: 0 16K 32K 48K 64K |/////////////| |//| |//| - Truncate the inode to 16K Which will trigger writeback through: btrfs_setsize() |- truncate_setsize() | Now the inode size is set to 16K | |- btrfs_truncacte() |- btrfs_wait_ordered_range() for [16K, u64(-1)] |- btrfs_fdatawrite_range() for [16K, u64(-1)} |- extent_writepage() for folio 0 |- writepage_delalloc() | Generated OE for [0, 16K), [32K, 36K] and [60K, 64K) | |- extent_writepage_io() Then inside extent_writepage_io(), the dirty fs blocks are handled differently: - Submit write for range [0, 16K) As they are still inside the inode size (16K). - Mark OE [32K, 36K) as truncated Since we only call btrfs_lookup_first_ordered_range() once, which returned the first OE after file offset 16K. - Mark all OEs inside range [16K, 64K) as finished Which will mark OE ranges [32K, 36K) and [60K, 64K) as finished. For OE [32K, 36K) since it's already marked as truncated, and its truncated length is 0, no file extent will be inserted. For OE [60K, 64K) it has never been submitted thus has no data checksum, and we insert the file extent as usual. This is the root cause of file extent at 60K to be inserted without any data checksum. - Clear dirty flags for range [16K, 64K) It is the function btrfs_folio_clear_dirty() which search and clear any dirty blocks inside that range. [FIX] The bug itself is introduced a long time ago, way before subpage and larger folio support. At that time, fs block size must match page size, thus the range [cur, end) is just one fs block. But later with subpage and larger folios, the same range [cur, end) can have multiple blocks and ordered extents. Later commit 18de34daa7c6 ("btrfs: truncate ordered extent when skipping writeback past i_size") is fixing a bug related to subpage/larger folios, but it's still utilizing the old range [cur, end), meaning only the first OE will be marked as truncated. The proper fix here is to make EOF handling block-by-block, not trying to handle the whole range to @end. By this we always locate and truncate the OE for every dirty block. Cc: stable(a)vger.kernel.org # 5.15+ Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/extent_io.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 629fd5af4286..a4b74023618d 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -1728,7 +1728,7 @@ static noinline_for_stack int extent_writepage_io(struct btrfs_inode *inode, struct btrfs_ordered_extent *ordered; ordered = btrfs_lookup_first_ordered_range(inode, cur, - folio_end - cur); + fs_info->sectorsize); /* * We have just run delalloc before getting here, so * there must be an ordered extent. @@ -1742,7 +1742,7 @@ static noinline_for_stack int extent_writepage_io(struct btrfs_inode *inode, btrfs_put_ordered_extent(ordered); btrfs_mark_ordered_io_finished(inode, folio, cur, - end - cur, true); + fs_info->sectorsize, true); /* * This range is beyond i_size, thus we don't need to * bother writing back. @@ -1751,8 +1751,8 @@ static noinline_for_stack int extent_writepage_io(struct btrfs_inode *inode, * writeback the sectors with subpage dirty bits, * causing writeback without ordered extent. */ - btrfs_folio_clear_dirty(fs_info, folio, cur, end - cur); - break; + btrfs_folio_clear_dirty(fs_info, folio, cur, fs_info->sectorsize); + continue; } ret = submit_one_sector(inode, folio, cur, bio_ctrl, i_size); if (unlikely(ret < 0)) { -- 2.52.0

1 week

3
2
0 0

[PATCH v2] drm/nouveau/dispnv50: Don't call drm_atomic_get_crtc_state() in prepare_fb

by Lyude Paul

Since we recently started warning about uses of this function after the atomic check phase completes, we've started getting warnings about this in nouveau. It appears a misplaced drm_atomic_get_crtc_state() call has been hiding in our .prepare_fb callback for a while. So, fix this by adding a new nv50_head_atom_get_new() function and use that in our .prepare_fb callback instead. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files") Cc: <stable(a)vger.kernel.org> # v4.18+ --- V2: * Don't call IS_ERR against the return value of drm_atomic_get_new_crtc_state(), it doesn't return pointer errors. Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/atom.h | 13 +++++++++++++ drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h b/drivers/gpu/drm/nouveau/dispnv50/atom.h index 93f8f4f645784..b43c4f9bbcdf5 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/atom.h +++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h @@ -152,8 +152,21 @@ static inline struct nv50_head_atom * nv50_head_atom_get(struct drm_atomic_state *state, struct drm_crtc *crtc) { struct drm_crtc_state *statec = drm_atomic_get_crtc_state(state, crtc); + if (IS_ERR(statec)) return (void *)statec; + + return nv50_head_atom(statec); +} + +static inline struct nv50_head_atom * +nv50_head_atom_get_new(struct drm_atomic_state *state, struct drm_crtc *crtc) +{ + struct drm_crtc_state *statec = drm_atomic_get_new_crtc_state(state, crtc); + + if (!statec) + return NULL; + return nv50_head_atom(statec); } diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c index ef9e410babbfb..9a2c20fce0f3e 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c @@ -583,7 +583,7 @@ nv50_wndw_prepare_fb(struct drm_plane *plane, struct drm_plane_state *state) asyw->image.offset[0] = nvbo->offset; if (wndw->func->prepare) { - asyh = nv50_head_atom_get(asyw->state.state, asyw->state.crtc); + asyh = nv50_head_atom_get_new(asyw->state.state, asyw->state.crtc); if (IS_ERR(asyh)) return PTR_ERR(asyh); base-commit: c7685d11108acb387e44e3d81194d0d8959eaa44 -- 2.52.0

1 week

1
0
0 0

[PATCH] KVM: x86/pmu: Do not accidentally create BTS events

by Fernand Sieber

From: Jan H. Schönherr <jschoenh(a)amazon.de> It is possible to degrade host performance by manipulating performance counters from a VM and tricking the host hypervisor to enable branch tracing. When the guest programs a CPU to track branch instructions and deliver an interrupt after exactly one branch instruction, the value one is handled by the host KVM/perf subsystems and treated incorrectly as a special value to enable the branch trace store (BTS) subsystem. It should not be possible to enable BTS from a guest. When BTS is enabled, it leads to general host performance degradation to both VMs and host. Perf considers the combination of PERF_COUNT_HW_BRANCH_INSTRUCTIONS with a sample_period of 1 a special case and handles this as a BTS event (see intel_pmu_has_bts_period()) -- a deviation from the usual semantic, where the sample_period represents the amount of branch instructions to encounter before the overflow handler is invoked. Nothing prevents a guest from programming its vPMU with the above settings (count branch, interrupt after one branch), which causes KVM to erroneously instruct perf to create a BTS event within pmc_reprogram_counter(), which does not have the desired semantics. The guest could also do more benign actions and request an interrupt after a more reasonable number of branch instructions via its vPMU. In that case counting works initially. However, KVM occasionally pauses and resumes the created performance counters. If the remaining amount of branch instructions until interrupt has reached 1 exactly, pmc_resume_counter() fails to resume the counter and a BTS event is created instead with its incorrect semantics. Fix this behavior by not passing the special value "1" as sample_period to perf. Instead, perform the same quirk that happens later in x86_perf_event_set_period() anyway, when the performance counter is transferred to the actual PMU: bump the sample_period to 2. Testing: From guest: `./wrmsr -p 12 0x186 0x1100c4` `./wrmsr -p 12 0xc1 0xffffffffffff` `./wrmsr -p 12 0x186 0x5100c4` This sequence sets up branch instruction counting, initializes the counter to overflow after one event (0xffffffffffff), and then enables edge detection (bit 18) for branch events. ./wrmsr -p 12 0x186 0x1100c4 Writes to IA32_PERFEVTSEL0 (0x186) Value 0x1100c4 breaks down as: Event = 0xC4 (Branch instructions) Bits 16-17: 0x1 (User mode only) Bit 22: 1 (Enable counter) ./wrmsr -p 12 0xc1 0xffffffffffff Writes to IA32_PMC0 (0xC1) Sets counter to maximum value (0xffffffffffff) This effectively sets up the counter to overflow on the next branch ./wrmsr -p 12 0x186 0x5100c4 Updates IA32_PERFEVTSEL0 again Similar to first command but adds bit 18 (0x4 to 0x5) Enables edge detection (bit 18) These MSR writes are trapped by the hypervisor in KVM and forwarded to the perf subsystem to create corresponding monitoring events. It is possible to repro this problem in a more realistic guest scenario: `perf record -e branches:u -c 2 -a &` `perf record -e branches:u -c 2 -a &` This presumably triggers the issue by KVM pausing and resuming the performance counter at the wrong moment, when its value is about to overflow. Signed-off-by: Jan H. Schönherr <jschoenh(a)amazon.de> Signed-off-by: Fernand Sieber <sieberf(a)amazon.com> Reviewed-by: David Woodhouse <dwmw(a)amazon.co.uk> Reviewed-by: Hendrik Borghorst <hborghor(a)amazon.de> Link: https://lore.kernel.org/r/20251124100220.238177-1-sieberf@amazon.com --- arch/x86/kvm/pmu.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c index 487ad19a236e..547512028e24 100644 --- a/arch/x86/kvm/pmu.c +++ b/arch/x86/kvm/pmu.c @@ -225,6 +225,19 @@ static u64 get_sample_period(struct kvm_pmc *pmc, u64 counter_value) { u64 sample_period = (-counter_value) & pmc_bitmask(pmc); + /* + * A sample_period of 1 might get mistaken by perf for a BTS event, see + * intel_pmu_has_bts_period(). This would prevent re-arming the counter + * via pmc_resume_counter(), followed by the accidental creation of an + * actual BTS event, which we do not want. + * + * Avoid this by bumping the sampling period. Note, that we do not lose + * any precision, because the same quirk happens later anyway (for + * different reasons) in x86_perf_event_set_period(). + */ + if (sample_period == 1) + sample_period = 2; + if (!sample_period) sample_period = pmc_bitmask(pmc) + 1; return sample_period; -- 2.43.0 Amazon Development Centre (South Africa) (Proprietary) Limited 29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa Registration Number: 2004 / 034463 / 07

1 week

5
11
0 0

[PATCH v2] fjes: Add missing iounmap in fjes_hw_init()

by Haoxiang Li

In error paths, add fjes_hw_iounmap() to release the resource acquired by fjes_hw_iomap(). Add a goto label to do so. Fixes: 8cdc3f6c5d22 ("fjes: Hardware initialization routine") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> Signed-off-by: Simon Horman <horms(a)kernel.org> --- Changes in v2: - Use an idiomatic goto to do the error hanlding. - Thanks for pointing out the issues with the patch, Simon! --- drivers/net/fjes/fjes_hw.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/net/fjes/fjes_hw.c b/drivers/net/fjes/fjes_hw.c index b9b5554ea862..5ad2673f213d 100644 --- a/drivers/net/fjes/fjes_hw.c +++ b/drivers/net/fjes/fjes_hw.c @@ -334,7 +334,7 @@ int fjes_hw_init(struct fjes_hw *hw) ret = fjes_hw_reset(hw); if (ret) - return ret; + goto err_iounmap; fjes_hw_set_irqmask(hw, REG_ICTL_MASK_ALL, true); @@ -347,8 +347,10 @@ int fjes_hw_init(struct fjes_hw *hw) hw->max_epid = fjes_hw_get_max_epid(hw); hw->my_epid = fjes_hw_get_my_epid(hw); - if ((hw->max_epid == 0) || (hw->my_epid >= hw->max_epid)) - return -ENXIO; + if ((hw->max_epid == 0) || (hw->my_epid >= hw->max_epid)) { + ret = -ENXIO; + goto err_iounmap; + } ret = fjes_hw_setup(hw); @@ -356,6 +358,10 @@ int fjes_hw_init(struct fjes_hw *hw) hw->hw_info.trace_size = FJES_DEBUG_BUFFER_SIZE; return ret; + +err_iounmap: + fjes_hw_iounmap(hw); + return ret; } void fjes_hw_exit(struct fjes_hw *hw) -- 2.25.1

1 week

4
3
0 0

[PATCH v2] media: dvb-frontends: Fix out of bound for buffer

by Ilya Krutskih

Result of pointer shifting is out of bound for buffer 'prev_swp_freq' because of incrementation inside 'while' cycle in case more than 20 steps of it. Add check: prev_freq_num < 20 Cc: stable(a)vger.kernel.org # v5.10+ Fixes: 9a0bf528b4d6 ([media] move the dvb/frontends to drivers/media/dvb-frontends) Signed-off-by: Ilya Krutskih <devsec(a)tpz.ru> --- drivers/media/dvb-frontends/mb86a16.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/mb86a16.c b/drivers/media/dvb-frontends/mb86a16.c index 9033e39d75f4..da8985b91475 100644 --- a/drivers/media/dvb-frontends/mb86a16.c +++ b/drivers/media/dvb-frontends/mb86a16.c @@ -1188,7 +1188,7 @@ static int mb86a16_set_fe(struct mb86a16_state *state) signal_dupl = 0; for (j = 0; j < prev_freq_num; j++) { - if ((abs(prev_swp_freq[j] - swp_freq)) < (swp_ofs * 3 / 2)) { + if ((prev_freq_num < 20) && (abs(prev_swp_freq[j] - swp_freq)) < (swp_ofs * 3 / 2)) { signal_dupl = 1; dprintk(verbose, MB86A16_INFO, 1, "Probably Duplicate Signal, j = %d", j); } -- 2.43.0

1 week

1
0
0 0

[PATCH v3] zstd: fixed possible 'rtbTable' underflow in FSE_normalizeCount()

by Ilya Krutskih

'rtbTable' may be underflowed because 'proba' is used without checking for a non-negative as index of rtbTable[]. Add check: proba >= 0 Cc: stable(a)vger.kernel.org # v5.10+ Fixes: e0c1b49f5b67 ("lib: zstd: Upgrade to latest upstream zstd version 1.4.10") Signed-off-by: Ilya Krutskih <devsec(a)tpz.ru> --- lib/zstd/compress/fse_compress.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lib/zstd/compress/fse_compress.c b/lib/zstd/compress/fse_compress.c index 44a3c10becf2..6b83f8bc943a 100644 --- a/lib/zstd/compress/fse_compress.c +++ b/lib/zstd/compress/fse_compress.c @@ -492,9 +492,10 @@ size_t FSE_normalizeCount (short* normalizedCounter, unsigned tableLog, stillToDistribute--; } else { short proba = (short)((count[s]*step) >> scale); - if (proba<8) { - U64 restToBeat = vStep * rtbTable[proba]; - proba += (count[s]*step) - ((U64)proba<<scale) > restToBeat; + if ((proba >= 0) && (proba < 8)) { + U64 restToBeat = vStep * rtbTable[proba]; + + proba += (count[s]*step) - ((U64)proba<<scale) > restToBeat; } if (proba > largestP) { largestP=proba; largest=s; } normalizedCounter[s] = proba; -- 2.43.0

1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror