Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

63 participants
123758 discussions

[PATCH] media: cx88: Add missing unmap in snd_cx88_hw_params()

by Haoxiang Li

In error path, add cx88_alsa_dma_unmap() to release resource acquired by cx88_alsa_dma_map(). Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx88/cx88-alsa.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/cx88/cx88-alsa.c b/drivers/media/pci/cx88/cx88-alsa.c index 29fb1311e443..4e574d8390b4 100644 --- a/drivers/media/pci/cx88/cx88-alsa.c +++ b/drivers/media/pci/cx88/cx88-alsa.c @@ -483,8 +483,10 @@ static int snd_cx88_hw_params(struct snd_pcm_substream *substream, ret = cx88_risc_databuffer(chip->pci, &buf->risc, buf->sglist, chip->period_size, chip->num_periods, 1); - if (ret < 0) + if (ret < 0) { + cx88_alsa_dma_unmap(chip); goto error; + } /* Loop back to start of program */ buf->risc.jmp[0] = cpu_to_le32(RISC_JUMP | RISC_IRQ1 | RISC_CNT_INC); -- 2.25.1

3 weeks, 3 days

[PATCH] media: cx25821: Add missing unmap in snd_cx25821_hw_params()

by Haoxiang Li

In error path, add cx25821_alsa_dma_unmap() to release the resource acquired by cx25821_alsa_dma_map() Fixes: b2c75abde0de ("[media] cx88: drop videobuf abuse in cx88-alsa") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/media/pci/cx25821/cx25821-alsa.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/pci/cx25821/cx25821-alsa.c b/drivers/media/pci/cx25821/cx25821-alsa.c index a42f0c03a7ca..f463365163b7 100644 --- a/drivers/media/pci/cx25821/cx25821-alsa.c +++ b/drivers/media/pci/cx25821/cx25821-alsa.c @@ -535,6 +535,7 @@ static int snd_cx25821_hw_params(struct snd_pcm_substream *substream, chip->period_size, chip->num_periods, 1); if (ret < 0) { pr_info("DEBUG: ERROR after cx25821_risc_databuffer_audio()\n"); + cx25821_alsa_dma_unmap(chip); goto error; } -- 2.25.1

3 weeks, 3 days

[PATCH v2] x86/elf: Fix core dump truncation on CPUs with no extended xfeatures

by yongxin.liu＠windriver.com

From: Yongxin Liu <yongxin.liu(a)windriver.com> Zero can be a valid value of num_records. For example, on Intel Atom x6425RE, only x87 and SSE are supported (features 0, 1), and fpu_user_cfg.max_features is 3. The for_each_extended_xfeature() loop only iterates feature 2, which is not enabled, so num_records = 0. This is valid and should not cause core dump failure. The issue is that dump_xsave_layout_desc() returns 0 for both genuine errors (dump_emit() failure) and valid cases (no extended features). Use negative return values for errors and only abort on genuine failures. Cc: stable(a)vger.kernel.org Fixes: ba386777a30b ("x86/elf: Add a new FPU buffer layout info to x86 core files") Signed-off-by: Yongxin Liu <yongxin.liu(a)windriver.com> --- V2: Keep error checking but use negative value for genuine error V1: Remove error checking entirely --- arch/x86/kernel/fpu/xstate.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 48113c5193aa..76153dfb58c9 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1946,7 +1946,7 @@ static int dump_xsave_layout_desc(struct coredump_params *cprm) }; if (!dump_emit(cprm, &xc, sizeof(xc))) - return 0; + return -1; num_records++; } @@ -1984,7 +1984,7 @@ int elf_coredump_extra_notes_write(struct coredump_params *cprm) return 1; num_records = dump_xsave_layout_desc(cprm); - if (!num_records) + if (num_records < 0) return 1; /* Total size should be equal to the number of records */ -- 2.46.2

3 weeks, 3 days

[PATCH] x86/elf: Fix core dump truncation on CPUs with no extended xfeatures

by yongxin.liu＠windriver.com

From: Yongxin Liu <yongxin.liu(a)windriver.com> Zero can be a valid value of num_records. For example, on Intel Atom x6425RE, only x87 and SSE are supported (features 0, 1), and fpu_user_cfg.max_features is 3. The for_each_extended_xfeature() loop only iterates feature 2, which is not enabled, so num_records = 0. This is valid and should not cause core dump failure. The size check already validates consistency: if num_records = 0, then en.n_descsz = 0, so the check passes. Cc: stable(a)vger.kernel.org Fixes: ba386777a30b ("x86/elf: Add a new FPU buffer layout info to x86 core files") Signed-off-by: Yongxin Liu <yongxin.liu(a)windriver.com> --- arch/x86/kernel/fpu/xstate.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 48113c5193aa..b1dd30eb21a8 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1984,8 +1984,6 @@ int elf_coredump_extra_notes_write(struct coredump_params *cprm) return 1; num_records = dump_xsave_layout_desc(cprm); - if (!num_records) - return 1; /* Total size should be equal to the number of records */ if ((sizeof(struct x86_xfeat_component) * num_records) != en.n_descsz) -- 2.46.2

3 weeks, 3 days

[PATCH v5 1/6] drm/amdgpu: Fix gfx9 update PTE mtype flag

by Philip Yang

Fix copy&paste error, that should have been an assignment instead of an or, otherwise MTYPE_UC 0x3 can not be updated to MTYPE_RW 0x1. CC stables. cc: stable(a)vger.kernel.org Signed-off-by: Philip Yang <Philip.Yang(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c index 97a04e3171f2..205c34eb8d11 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c @@ -1204,16 +1204,16 @@ static void gmc_v9_0_get_vm_pte(struct amdgpu_device *adev, *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_NC); break; case AMDGPU_VM_MTYPE_WC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_WC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_WC); break; case AMDGPU_VM_MTYPE_RW: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_RW); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_RW); break; case AMDGPU_VM_MTYPE_CC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_CC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_CC); break; case AMDGPU_VM_MTYPE_UC: - *flags |= AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_UC); + *flags = AMDGPU_PTE_MTYPE_VG10(*flags, MTYPE_UC); break; } -- 2.50.1

3 weeks, 3 days

[PATCH] lib/crypto: riscv: Depend on RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS

by Eric Biggers

Replace the RISCV_ISA_V dependency of the RISC-V crypto code with RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS, which implies RISCV_ISA_V as well as vector unaligned accesses being efficient. This is necessary because this code assumes that vector unaligned accesses are supported and are efficient. (It does so to avoid having to use lots of extra vsetvli instructions to switch the element width back and forth between 8 and either 32 or 64.) This was omitted from the code originally just because the RISC-V kernel support for detecting this feature didn't exist yet. Support has now been added, but it's fragmented into per-CPU runtime detection, a command-line parameter, and a kconfig option. The kconfig option is the only reasonable way to do it, though, so let's just rely on that. Fixes: eb24af5d7a05 ("crypto: riscv - add vector crypto accelerated AES-{ECB,CBC,CTR,XTS}") Fixes: bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCha20") Fixes: 600a3853dfa0 ("crypto: riscv - add vector crypto accelerated GHASH") Fixes: 8c8e40470ffe ("crypto: riscv - add vector crypto accelerated SHA-{256,224}") Fixes: b3415925a08b ("crypto: riscv - add vector crypto accelerated SHA-{512,384}") Fixes: 563a5255afa2 ("crypto: riscv - add vector crypto accelerated SM3") Fixes: b8d06352bbf3 ("crypto: riscv - add vector crypto accelerated SM4") Cc: stable(a)vger.kernel.org Signed-off-by: Eric Biggers <ebiggers(a)kernel.org> --- arch/riscv/crypto/Kconfig | 12 ++++++++---- lib/crypto/Kconfig | 9 ++++++--- 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/arch/riscv/crypto/Kconfig b/arch/riscv/crypto/Kconfig index a75d6325607b..14c5acb935e9 100644 --- a/arch/riscv/crypto/Kconfig +++ b/arch/riscv/crypto/Kconfig @@ -2,11 +2,12 @@ menu "Accelerated Cryptographic Algorithms for CPU (riscv)" config CRYPTO_AES_RISCV64 tristate "Ciphers: AES, modes: ECB, CBC, CTS, CTR, XTS" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_ALGAPI select CRYPTO_LIB_AES select CRYPTO_SKCIPHER help Block cipher: AES cipher algorithms @@ -18,21 +19,23 @@ config CRYPTO_AES_RISCV64 - Zvkb vector crypto extension (CTR) - Zvkg vector crypto extension (XTS) config CRYPTO_GHASH_RISCV64 tristate "Hash functions: GHASH" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_GCM help GCM GHASH function (NIST SP 800-38D) Architecture: riscv64 using: - Zvkg vector crypto extension config CRYPTO_SM3_RISCV64 tristate "Hash functions: SM3 (ShangMi 3)" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_HASH select CRYPTO_LIB_SM3 help SM3 (ShangMi 3) secure hash function (OSCCA GM/T 0004-2012) @@ -40,11 +43,12 @@ config CRYPTO_SM3_RISCV64 - Zvksh vector crypto extension - Zvkb vector crypto extension config CRYPTO_SM4_RISCV64 tristate "Ciphers: SM4 (ShangMi 4)" - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS select CRYPTO_ALGAPI select CRYPTO_SM4 help SM4 block cipher algorithm (OSCCA GB/T 32907-2016, ISO/IEC 18033-3:2010/Amd 1:2021) diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig index a3647352bff6..6871a41e5069 100644 --- a/lib/crypto/Kconfig +++ b/lib/crypto/Kconfig @@ -59,11 +59,12 @@ config CRYPTO_LIB_CHACHA_ARCH depends on CRYPTO_LIB_CHACHA && !UML && !KMSAN default y if ARM default y if ARM64 && KERNEL_MODE_NEON default y if MIPS && CPU_MIPS32_R2 default y if PPC64 && CPU_LITTLE_ENDIAN && VSX - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS default y if S390 default y if X86_64 config CRYPTO_LIB_CURVE25519 tristate @@ -182,11 +183,12 @@ config CRYPTO_LIB_SHA256_ARCH depends on CRYPTO_LIB_SHA256 && !UML default y if ARM && !CPU_V7M default y if ARM64 default y if MIPS && CPU_CAVIUM_OCTEON default y if PPC && SPE - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS default y if S390 default y if SPARC64 default y if X86_64 config CRYPTO_LIB_SHA512 @@ -200,11 +202,12 @@ config CRYPTO_LIB_SHA512_ARCH bool depends on CRYPTO_LIB_SHA512 && !UML default y if ARM && !CPU_V7M default y if ARM64 default y if MIPS && CPU_CAVIUM_OCTEON - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS default y if S390 default y if SPARC64 default y if X86_64 config CRYPTO_LIB_SHA3 base-commit: 43dfc13ca972988e620a6edb72956981b75ab6b0 -- 2.52.0

3 weeks, 3 days

[PATCH 1/2] drm/xe: Use generic_handle_irq_safe inside heci gsc irq handler

by Maarten Lankhorst

This makes the irq handler safe on PREEMPT-RT too. This is similar to the i915 commit 8cadce97bf26 ("drm/i915/gsc: mei interrupt top half should be in irq disabled context"). Fixes: 87a4c85d3a3e ("drm/xe/gsc: add gsc device support") Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> --- drivers/gpu/drm/xe/xe_heci_gsc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_heci_gsc.c b/drivers/gpu/drm/xe/xe_heci_gsc.c index 2b3d49dd394c0..495cdd4f948d5 100644 --- a/drivers/gpu/drm/xe/xe_heci_gsc.c +++ b/drivers/gpu/drm/xe/xe_heci_gsc.c @@ -223,7 +223,7 @@ void xe_heci_gsc_irq_handler(struct xe_device *xe, u32 iir) if (xe->heci_gsc.irq < 0) return; - ret = generic_handle_irq(xe->heci_gsc.irq); + ret = generic_handle_irq_safe(xe->heci_gsc.irq); if (ret) drm_err_ratelimited(&xe->drm, "error handling GSC irq: %d\n", ret); } @@ -243,7 +243,7 @@ void xe_heci_csc_irq_handler(struct xe_device *xe, u32 iir) if (xe->heci_gsc.irq < 0) return; - ret = generic_handle_irq(xe->heci_gsc.irq); + ret = generic_handle_irq_safe(xe->heci_gsc.irq); if (ret) drm_err_ratelimited(&xe->drm, "error handling GSC irq: %d\n", ret); } -- 2.51.0

3 weeks, 3 days

[PATCH v6 0/9] Error recovery for vfio-pci devices on s390x

by Farhan Ali

Hi, This Linux kernel patch series introduces support for error recovery for passthrough PCI devices on System Z (s390x). Background ---------- For PCI devices on s390x an operating system receives platform specific error events from firmware rather than through AER.Today for passthrough/userspace devices, we don't attempt any error recovery and ignore any error events for the devices. The passthrough/userspace devices are managed by the vfio-pci driver. The driver does register error handling callbacks (error_detected), and on an error trigger an eventfd to userspace. But we need a mechanism to notify userspace (QEMU/guest/userspace drivers) about the error event. Proposal -------- We can expose this error information (currently only the PCI Error Code) via a device feature. Userspace can then obtain the error information via VFIO_DEVICE_FEATURE ioctl and take appropriate actions such as driving a device reset. This is how a typical flow for passthrough devices to a VM would work: For passthrough devices to a VM, the driver bound to the device on the host is vfio-pci. vfio-pci driver does support the error_detected() callback (vfio_pci_core_aer_err_detected()), and on an PCI error s390x recovery code on the host will call the vfio-pci error_detected() callback. The vfio-pci error_detected() callback will notify userspace/QEMU via an eventfd, and return PCI_ERS_RESULT_CAN_RECOVER. At this point the s390x error recovery on the host will skip any further action(see patch 6) and let userspace drive the error recovery. Once userspace/QEMU is notified, it then injects this error into the VM so device drivers in the VM can take recovery actions. For example for a passthrough NVMe device, the VM's OS NVMe driver will access the device. At this point the VM's NVMe driver's error_detected() will drive the recovery by returning PCI_ERS_RESULT_NEED_RESET, and the s390x error recovery in the VM's OS will try to do a reset. Resets are privileged operations and so the VM will need intervention from QEMU to perform the reset. QEMU will invoke the VFIO_DEVICE_RESET ioctl to now notify the host that the VM is requesting a reset of the device. The vfio-pci driver on the host will then perform the reset on the device to recover it. Thanks Farhan ChangeLog --------- v5 series https://lore.kernel.org/all/20251113183502.2388-1-alifm@linux.ibm.com/ v5 -> v6 - Rebase on 6.18 + Lukas's PCI: Universal error recoverability of devices series (https://lore.kernel.org/all/cover.1763483367.git.lukas@wunner.de/) - Re-work config space accessibility check to pci_dev_save_and_disable() (patch 3). This avoids saving the config space, in the reset path, if the device's config space is corrupted or inaccessible. v4 series https://lore.kernel.org/all/20250924171628.826-1-alifm@linux.ibm.com/ v4 -> v5 - Rebase on 6.18-rc5 - Move bug fixes to the beginning of the series (patch 1 and 2). These patches were posted as a separate fixes series https://lore.kernel.org/all/a14936ac-47d6-461b-816f-0fd66f869b0f@linux.ibm.… - Add matching pci_put_dev() for pci_get_slot() (patch 6). v3 series https://lore.kernel.org/all/20250911183307.1910-1-alifm@linux.ibm.com/ v3 -> v4 - Remove warn messages for each PCI capability not restored (patch 1) - Check PCI_COMMAND and PCI_STATUS register for error value instead of device id (patch 1) - Fix kernel crash in patch 3 - Added reviewed by tags - Address comments from Niklas's (patches 4, 5, 7) - Fix compilation error non s390x system (patch 8) - Explicitly align struct vfio_device_feature_zpci_err (patch 8) v2 series https://lore.kernel.org/all/20250825171226.1602-1-alifm@linux.ibm.com/ v2 -> v3 - Patch 1 avoids saving any config space state if the device is in error (suggested by Alex) - Patch 2 adds additional check only for FLR reset to try other function reset method (suggested by Alex). - Patch 3 fixes a bug in s390 for resetting PCI devices with multiple functions. Creates a new flag pci_slot to allow per function slot. - Patch 4 fixes a bug in s390 for resource to bus address translation. - Rebase on 6.17-rc5 v1 series https://lore.kernel.org/all/20250813170821.1115-1-alifm@linux.ibm.com/ v1 - > v2 - Patches 1 and 2 adds some additional checks for FLR/PM reset to try other function reset method (suggested by Alex). - Patch 3 fixes a bug in s390 for resetting PCI devices with multiple functions. - Patch 7 adds a new device feature for zPCI devices for the VFIO_DEVICE_FEATURE ioctl. The ioctl is used by userspace to retriece any PCI error information for the device (suggested by Alex). - Patch 8 adds a reset_done() callback for the vfio-pci driver, to restore the state of the device after a reset. - Patch 9 removes the pcie check for triggering VFIO_PCI_ERR_IRQ_INDEX. Farhan Ali (9): PCI: Allow per function PCI slots s390/pci: Add architecture specific resource/bus address translation PCI: Avoid saving config space state if inaccessible PCI: Add additional checks for flr reset s390/pci: Update the logic for detecting passthrough device s390/pci: Store PCI error information for passthrough devices vfio-pci/zdev: Add a device feature for error information vfio: Add a reset_done callback for vfio-pci driver vfio: Remove the pcie check for VFIO_PCI_ERR_IRQ_INDEX arch/s390/include/asm/pci.h | 29 ++++++++ arch/s390/pci/pci.c | 75 +++++++++++++++++++++ arch/s390/pci/pci_event.c | 107 +++++++++++++++++------------- drivers/pci/host-bridge.c | 4 +- drivers/pci/pci.c | 19 +++++- drivers/pci/slot.c | 25 ++++++- drivers/vfio/pci/vfio_pci_core.c | 20 ++++-- drivers/vfio/pci/vfio_pci_intrs.c | 3 +- drivers/vfio/pci/vfio_pci_priv.h | 9 +++ drivers/vfio/pci/vfio_pci_zdev.c | 45 ++++++++++++- include/linux/pci.h | 1 + include/uapi/linux/vfio.h | 15 +++++ 12 files changed, 291 insertions(+), 61 deletions(-) -- 2.43.0

3 weeks, 3 days

¿Cuánto cuesta una mala contratación?

by Valeria Pérez

¿Cuánto cuesta una mala contratación? body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Una mala contratación cuesta 3X el salario. Evítalo con datos, no percepciones. Hola, , ¿Sabías que una mala contratación cuesta hasta 3 veces el salario anual? El 74% de empresas admite haber contratado a la persona equivocada. El motivo: decisiones basadas en percepciones, no en datos objetivos. PsicoSmart te ayuda a evaluar talento con precisión: 31 pruebas psicométricas validadas para medir liderazgo, honestidad e inteligencia 2,500+ exámenes técnicos especializados por industria Verificación de identidad con captura fotográfica automática Resultados en minutos, accesible desde cualquier dispositivo Reduce hasta 60% el riesgo de error en selección. ¿Quieres una demostración gratuita? Responde este correo y te contacto en menos de 24 horas. Saludos, -------------- Atte.: Valeria Pérez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewiswqtrseup">click aquí</a>

3 weeks, 3 days

[merged mm-nonmm-stable] ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: ocfs2: fix kernel BUG in ocfs2_find_victim_chain has been removed from the -mm tree. Its filename was ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Prithvi Tambewagh <activprithvi(a)gmail.com> Subject: ocfs2: fix kernel BUG in ocfs2_find_victim_chain Date: Mon, 1 Dec 2025 18:37:11 +0530 syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list (next free slot in the chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition in ocfs2_find_victim_chain() and panicking the kernel. To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(), just before calling ocfs2_find_victim_chain(), the code block in it being executed when either of the following conditions is true: 1. `cl_next_free_rec` is equal to 0, indicating that there are no free chains in the allocation chain list 2. `cl_next_free_rec` is greater than `cl_count` (the total number of chains in the allocation chain list) Either of them being true is indicative of the fact that there are no chains left for usage. This is addressed using ocfs2_error(), which prints the error log for debugging purposes, rather than panicking the kernel. Link: https://lkml.kernel.org/r/20251201130711.143900-1-activprithvi@gmail.com Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Heming Zhao <heming.zhao(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/suballoc.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/fs/ocfs2/suballoc.c~ocfs2-fix-kernel-bug-in-ocfs2_find_victim_chain +++ a/fs/ocfs2/suballoc.c @@ -1993,6 +1993,16 @@ static int ocfs2_claim_suballoc_bits(str } cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if (!le16_to_cpu(cl->cl_next_free_rec) || + le16_to_cpu(cl->cl_next_free_rec) > le16_to_cpu(cl->cl_count)) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has invalid next " + "free chain record %u, but only %u total\n", + (unsigned long long)le64_to_cpu(fe->i_blkno), + le16_to_cpu(cl->cl_next_free_rec), + le16_to_cpu(cl->cl_count)); + goto bail; + } victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; _ Patches currently in -mm which might be from activprithvi(a)gmail.com are

3 weeks, 3 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror