June 2025 - Linux-stable-mirror

[PATCH v2] iommu/arm-smmu-qcom: Add SM6115 MDSS compatible

by Alexey Klimov

Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot: arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed) ------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22 Suggested-by: Bjorn Andersson <andersson(a)kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115") Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexey Klimov <alexey.klimov(a)linaro.org> --- v2: - added tags as suggested by Dmitry; - slightly updated text in the commit message. Previous version: https://lore.kernel.org/linux-arm-msm/20250528003118.214093-1-alexey.klimov… drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c index 62874b18f645..c75023718595 100644 --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c @@ -379,6 +379,7 @@ static const struct of_device_id qcom_smmu_client_of_match[] __maybe_unused = { { .compatible = "qcom,sdm670-mdss" }, { .compatible = "qcom,sdm845-mdss" }, { .compatible = "qcom,sdm845-mss-pil" }, + { .compatible = "qcom,sm6115-mdss" }, { .compatible = "qcom,sm6350-mdss" }, { .compatible = "qcom,sm6375-mdss" }, { .compatible = "qcom,sm8150-mdss" }, -- 2.47.2

5 months

3
3
0 0

[PATCH] extcon: fsa9480: Avoid buffer overflow in fsa9480_handle_change()

by Vladimir Moskovkin

Bit 7 of the 'Device Type 2' (0Bh) register is reserved in the FSA9480 device, but is used by the FSA880 and TSU6111 devices. From FSA9480 datasheet, Table 18. Device Type 2: Reset Value: x0000000 =========================================================================== Bit # | Name | Size (Bits) | Description --------------------------------------------------------------------------- 7 | Reserved | 1 | NA From FSA880 datasheet, Table 13. Device Type 2: Reset Value: 0xxx0000 =========================================================================== Bit # | Name | Size (Bits) | Description --------------------------------------------------------------------------- 7 | Unknown | 1 | 1: Any accessory detected as unknown | Accessory | | or an accessory that cannot be | | | detected as being valid even | | | though ID_CON is not floating | | | 0: Unknown accessory not detected From TSU6111 datasheet, Device Type 2: Reset Value:x0000000 =========================================================================== Bit # | Name | Size (Bits) | Description --------------------------------------------------------------------------- 7 | Audio Type 3 | 1 | Audio device type 3 So the value obtained from the FSA9480_REG_DEV_T2 register in the fsa9480_detect_dev() function may have the 7th bit set. In this case, the 'dev' parameter in the fsa9480_handle_change() function will be 15. And this will cause the 'cable_types' array to overflow when accessed at this index. Extend the 'cable_types' array with a new value 'DEV_RESERVED' as specified in the FSA9480 datasheet. Do not use it as it serves for various purposes in the listed devices. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bad5b5e707a5 ("extcon: Add fsa9480 extcon driver") Cc: stable(a)vger.kernel.org Signed-off-by: Vladimir Moskovkin <Vladimir.Moskovkin(a)kaspersky.com> --- drivers/extcon/extcon-fsa9480.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/extcon/extcon-fsa9480.c b/drivers/extcon/extcon-fsa9480.c index b11b43171063..30972a7214f7 100644 --- a/drivers/extcon/extcon-fsa9480.c +++ b/drivers/extcon/extcon-fsa9480.c @@ -68,6 +68,7 @@ #define DEV_T1_CHARGER_MASK (DEV_DEDICATED_CHG | DEV_USB_CHG) /* Device Type 2 */ +#define DEV_RESERVED 15 #define DEV_AV 14 #define DEV_TTY 13 #define DEV_PPD 12 @@ -133,6 +134,7 @@ static const u64 cable_types[] = { [DEV_USB] = BIT_ULL(EXTCON_USB) | BIT_ULL(EXTCON_CHG_USB_SDP), [DEV_AUDIO_2] = BIT_ULL(EXTCON_JACK_LINE_OUT), [DEV_AUDIO_1] = BIT_ULL(EXTCON_JACK_LINE_OUT), + [DEV_RESERVED] = 0, [DEV_AV] = BIT_ULL(EXTCON_JACK_LINE_OUT) | BIT_ULL(EXTCON_JACK_VIDEO_OUT), [DEV_TTY] = BIT_ULL(EXTCON_JIG), @@ -228,7 +230,7 @@ static void fsa9480_detect_dev(struct fsa9480_usbsw *usbsw) dev_err(usbsw->dev, "%s: failed to read registers", __func__); return; } - val = val2 << 8 | val1; + val = val2 << 8 | (val1 & 0xFF); dev_info(usbsw->dev, "dev1: 0x%x, dev2: 0x%x\n", val1, val2); -- 2.25.1

5 months

2
1
0 0

[PATCH for 5.4 and 5.10] ACPI: PAD: fix crash in exit_round_robin()

by Nobuhiro Iwamatsu

From: Seiji Nishikawa <snishika(a)redhat.com> commit 0a2ed70a549e61c5181bad5db418d223b68ae932 upstream. The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 <power_saving_thread+787>: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <pad_busy_cpus_bits> crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). Signed-off-by: Seiji Nishikawa <snishika(a)redhat.com> Link: https://patch.msgid.link/20240825141352.25280-1-snishika@redhat.com [ rjw: Subject edit, avoid updates to the same value ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Link: https://nvd.nist.gov/vuln/detail/CVE-2024-49935 Signed-off-by: Nobuhiro Iwamatsu (CIP) <nobuhiro1.iwamatsu(a)toshiba.co.jp> --- drivers/acpi/acpi_pad.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c index 35de23ff50d6..3e7e28b7947e 100644 --- a/drivers/acpi/acpi_pad.c +++ b/drivers/acpi/acpi_pad.c @@ -128,8 +128,11 @@ static void round_robin_cpu(unsigned int tsk_index) static void exit_round_robin(unsigned int tsk_index) { struct cpumask *pad_busy_cpus = to_cpumask(pad_busy_cpus_bits); - cpumask_clear_cpu(tsk_in_cpu[tsk_index], pad_busy_cpus); - tsk_in_cpu[tsk_index] = -1; + + if (tsk_in_cpu[tsk_index] != -1) { + cpumask_clear_cpu(tsk_in_cpu[tsk_index], pad_busy_cpus); + tsk_in_cpu[tsk_index] = -1; + } } static unsigned int idle_pct = 5; /* percentage */ -- 2.25.1

5 months

4
3
0 0

[PATCH] usb: gadget: max3420_udc: Fix out-of-bounds endpoint index access

by Seungjin Bae

In the max3420_set_clear_feature() function, the endpoint index `id` can have a value from 0 to 15. However, the udc->ep array is initialized with a maximum of 4 endpoints in max3420_eps_init(). If host sends a request with a wIndex greater than 3, the access to `udc->ep[id]` will go out-of-bounds, leading to memory corruption or a potential kernel crash. This bug was found by code inspection and has not been tested on hardware. Fixes: 48ba02b2e2b1a ("usb: gadget: add udc driver for max3420") Cc: stable(a)vger.kernel.org Signed-off-by: Seungjin Bae <eeodqql09(a)gmail.com> --- drivers/usb/gadget/udc/max3420_udc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/udc/max3420_udc.c b/drivers/usb/gadget/udc/max3420_udc.c index 7349ea774adf..e4ecc7f7f3be 100644 --- a/drivers/usb/gadget/udc/max3420_udc.c +++ b/drivers/usb/gadget/udc/max3420_udc.c @@ -596,6 +596,8 @@ static void max3420_set_clear_feature(struct max3420_udc *udc) break; id = udc->setup.wIndex & USB_ENDPOINT_NUMBER_MASK; + if (id >= MAX3420_MAX_EPS) + break; ep = &udc->ep[id]; spin_lock_irqsave(&ep->lock, flags); -- 2.43.0

5 months

3
4
0 0

[PATCH 5.15.y] ocfs2: fix deadlock in ocfs2_get_system_file_inode

by Pranav Tyagi

From: Mohammed Anees <pvmohammedanees2003(a)gmail.com> [ Upstream commit 7bf1823e010e8db2fb649c790bd1b449a75f52d8 ] syzbot has found a possible deadlock in ocfs2_get_system_file_inode [1]. The scenario is depicted here, CPU0 CPU1 lock(&ocfs2_file_ip_alloc_sem_key); lock(&osb->system_file_mutex); lock(&ocfs2_file_ip_alloc_sem_key); lock(&osb->system_file_mutex); The function calls which could lead to this are: CPU0 ocfs2_mknod - lock(&ocfs2_file_ip_alloc_sem_key); . . . ocfs2_get_system_file_inode - lock(&osb->system_file_mutex); CPU1 - ocfs2_fill_super - lock(&osb->system_file_mutex); . . . ocfs2_read_virt_blocks - lock(&ocfs2_file_ip_alloc_sem_key); This issue can be resolved by making the down_read -> down_read_try in the ocfs2_read_virt_blocks. [1] https://syzkaller.appspot.com/bug?extid=e0055ea09f1f5e6fabdd [ Backport to 5.15: context cleanly applied with no semantic changes. Build-tested. ] Link: https://lkml.kernel.org/r/20240924093257.7181-1-pvmohammedanees2003@gmail.c… Signed-off-by: Mohammed Anees <pvmohammedanees2003(a)gmail.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reported-by: <syzbot+e0055ea09f1f5e6fabdd(a)syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=e0055ea09f1f5e6fabdd Tested-by: syzbot+e0055ea09f1f5e6fabdd(a)syzkaller.appspotmail.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: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Pranav Tyagi <pranav.tyagi03(a)gmail.com> --- fs/ocfs2/extent_map.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c index 70a768b623cf..f7672472fa82 100644 --- a/fs/ocfs2/extent_map.c +++ b/fs/ocfs2/extent_map.c @@ -973,7 +973,13 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, } while (done < nr) { - down_read(&OCFS2_I(inode)->ip_alloc_sem); + if (!down_read_trylock(&OCFS2_I(inode)->ip_alloc_sem)) { + rc = -EAGAIN; + mlog(ML_ERROR, + "Inode #%llu ip_alloc_sem is temporarily unavailable\n", + (unsigned long long)OCFS2_I(inode)->ip_blkno); + break; + } rc = ocfs2_extent_map_get_blocks(inode, v_block + done, &p_block, &p_count, NULL); up_read(&OCFS2_I(inode)->ip_alloc_sem); -- 2.49.0

5 months

3
3
0 0

[stable 6.12+] x86/pkeys: Simplify PKRU update in signal frame

by Ben Hutchings

Hi stable maintainers, Please apply commit d1e420772cd1 ("x86/pkeys: Simplify PKRU update in signal frame") to the stable branches for 6.12 and later. This fixes a regression introduced in 6.13 by commit ae6012d72fa6 ("x86/pkeys: Ensure updated PKRU value is XRSTOR'd"), which was also backported in 6.12.5. Ben. -- Ben Hutchings 73.46% of all statistics are made up.

5 months

3
5
0 0

[PATCH 5.10 v2 00/16] ITS mitigation for 5.10

by Pawan Gupta

v2: - Fixed the sign-offs. v1: https://lore.kernel.org/stable/20250610-its-5-10-v1-0-64f0ae98c98d@linux.in… This is the backport for Indirect Target Selection(ITS) mitigation for 5.10. This is only boot tested, so sending it as an RFC for now. I hope some bot picks this up for some at-scale testing. Meanwhile I am doing basic tests around ITS mitigation. In addition to commits in 5.15 ITS backport, below commits are required to make the ITS mitigation work on 5.10. These are the prime target of scrutiny: x86/alternatives: Teach text_poke_bp() to patch Jcc.d32 instructions x86/alternatives: Introduce int3_emulate_jcc() x86/bhi: Define SPEC_CTRL_BHI_DIS_S --- Borislav Petkov (AMD) (1): x86/alternative: Optimize returns patching Daniel Sneddon (1): x86/bhi: Define SPEC_CTRL_BHI_DIS_S Eric Biggers (1): x86/its: Fix build errors when CONFIG_MODULES=n Josh Poimboeuf (1): x86/alternatives: Remove faulty optimization Pawan Gupta (7): Documentation: x86/bugs/its: Add ITS documentation x86/its: Enumerate Indirect Target Selection (ITS) bug x86/its: Add support for ITS-safe indirect thunk x86/its: Add support for ITS-safe return thunk x86/its: Fix undefined reference to cpu_wants_rethunk_at() x86/its: Enable Indirect Target Selection mitigation x86/its: Add "vmexit" option to skip mitigation on some CPUs Peter Zijlstra (4): x86/alternatives: Introduce int3_emulate_jcc() x86/alternatives: Teach text_poke_bp() to patch Jcc.d32 instructions x86/its: Use dynamic thunks for indirect branches x86/its: FineIBT-paranoid vs ITS Thomas Gleixner (1): x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc() Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/indirect-target-selection.rst | 156 +++++++++++ Documentation/admin-guide/kernel-parameters.txt | 15 + arch/x86/Kconfig | 11 + arch/x86/include/asm/alternative.h | 26 ++ arch/x86/include/asm/cpufeatures.h | 6 +- arch/x86/include/asm/msr-index.h | 13 +- arch/x86/include/asm/nospec-branch.h | 11 + arch/x86/include/asm/text-patching.h | 31 +++ arch/x86/kernel/alternative.c | 308 ++++++++++++++++++++- arch/x86/kernel/cpu/bugs.c | 139 +++++++++- arch/x86/kernel/cpu/common.c | 63 ++++- arch/x86/kernel/cpu/scattered.c | 1 + arch/x86/kernel/ftrace.c | 4 +- arch/x86/kernel/kprobes/core.c | 39 +-- arch/x86/kernel/module.c | 14 +- arch/x86/kernel/static_call.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 8 + arch/x86/kvm/x86.c | 4 +- arch/x86/lib/retpoline.S | 39 +++ arch/x86/net/bpf_jit_comp.c | 8 +- drivers/base/cpu.c | 8 + include/linux/cpu.h | 2 + include/linux/module.h | 5 + 25 files changed, 842 insertions(+), 73 deletions(-) --- base-commit: 01e7e36b8606e5d4fddf795938010f7bfa3aa277 change-id: 20250617-its-5-10-43d1e195b345

5 months

3
36
0 0

[PATCH v2] ext4: inline: convert when mmap is called, not when page is written

by Thadeu Lima de Souza Cascardo

inline data handling has a race between writing and writing to a memory map. When ext4_page_mkwrite is called, it calls ext4_convert_inline_data, which destroys the inline data, but if block allocation fails, restores the inline data. In that process, we could have: CPU1 CPU2 destroy_inline_data write_begin (does not see inline data) restory_inline_data write_end (sees inline data) This leads to bugs like the one below, as write_begin did not prepare for the case of inline data, which is expected by the write_end side of it. ------------[ cut here ]------------ kernel BUG at fs/ext4/inline.c:235! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 UID: 0 PID: 5838 Comm: syz-executor110 Not tainted 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:ext4_write_inline_data fs/ext4/inline.c:235 [inline] RIP: 0010:ext4_write_inline_data_end+0xdc7/0xdd0 fs/ext4/inline.c:774 Code: 47 1d 8c e8 4b 3a 91 ff 90 0f 0b e8 63 7a 47 ff 48 8b 7c 24 10 48 c7 c6 e0 47 1d 8c e8 32 3a 91 ff 90 0f 0b e8 4a 7a 47 ff 90 <0f> 0b 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffc900031c7320 EFLAGS: 00010293 RAX: ffffffff8257f9a6 RBX: 000000000000005a RCX: ffff888012968000 RDX: 0000000000000000 RSI: 000000000000005a RDI: 000000000000005b RBP: ffffc900031c7448 R08: ffffffff8257ef87 R09: 1ffff11006806070 R10: dffffc0000000000 R11: ffffed1006806071 R12: 000000000000005a R13: dffffc0000000000 R14: ffff888076b65bd8 R15: 000000000000005b FS: 00007f5c6bacf6c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000a00 CR3: 0000000073fb6000 CR4: 0000000000350ef0 Call Trace: <TASK> generic_perform_write+0x6f8/0x990 mm/filemap.c:4070 ext4_buffered_write_iter+0xc5/0x350 fs/ext4/file.c:299 ext4_file_write_iter+0x892/0x1c50 iter_file_splice_write+0xbfc/0x1510 fs/splice.c:743 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0x11d/0x220 fs/splice.c:1164 splice_direct_to_actor+0x588/0xc80 fs/splice.c:1108 do_splice_direct_actor fs/splice.c:1207 [inline] do_splice_direct+0x289/0x3e0 fs/splice.c:1233 do_sendfile+0x564/0x8a0 fs/read_write.c:1363 __do_sys_sendfile64 fs/read_write.c:1424 [inline] __se_sys_sendfile64+0x17c/0x1e0 fs/read_write.c:1410 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5c6bb18d09 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f5c6bacf218 EFLAGS: 00000246 ORIG_RAX: 0000000000000028 RAX: ffffffffffffffda RBX: 00007f5c6bba0708 RCX: 00007f5c6bb18d09 RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000004 RBP: 00007f5c6bba0700 R08: 0000000000000000 R09: 0000000000000000 R10: 000080001d00c0d0 R11: 0000000000000246 R12: 00007f5c6bb6d620 R13: 00007f5c6bb6d0c0 R14: 0031656c69662f2e R15: 8088e3ad122bc192 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- This happens because ext4_page_mkwrite is not protected by the inode_lock. The xattr semaphore is not sufficient to protect inline data handling in a sane way, so we need to rely on the inode_lock. Adding the inode_lock to ext4_page_mkwrite is not an option, otherwise lock-ordering problems with mmap_lock may arise. The conversion inside ext4_page_mkwrite was introduced at commit 7b4cc9787fe3 ("ext4: evict inline data when writing to memory map"). This fixes a documented bug in the commit message, which suggests some alternative fixes. Convert inline data when mmap is called, instead of doing it only when the mmapped page is written to. Using the inode_lock there does not lead to lock-ordering issues. The drawback is that inline conversion will happen when the file is mmapped, even though the page will not be written to. Fixes: 7b4cc9787fe3 ("ext4: evict inline data when writing to memory map") Reported-by: syzbot+0c89d865531d053abb2d(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c89d865531d053abb2d Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com> Cc: stable(a)vger.kernel.org --- Changes in v2: - Convert inline data at mmap time, avoiding data loss. - Link to v1: https://lore.kernel.org/r/20250519-ext4_inline_page_mkwrite-v1-1-865d9a62b5… --- fs/ext4/file.c | 6 ++++++ fs/ext4/inode.c | 4 ---- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/ext4/file.c b/fs/ext4/file.c index beb078ee4811d6092e362e37307e7d87e5276cbc..f2380471df5d99500e49fdc639fa3e56143c328f 100644 --- a/fs/ext4/file.c +++ b/fs/ext4/file.c @@ -819,6 +819,12 @@ static int ext4_file_mmap(struct file *file, struct vm_area_struct *vma) if (!daxdev_mapping_supported(vma, dax_dev)) return -EOPNOTSUPP; + inode_lock(inode); + ret = ext4_convert_inline_data(inode); + inode_unlock(inode); + if (ret) + return ret; + file_accessed(file); if (IS_DAX(file_inode(file))) { vma->vm_ops = &ext4_dax_vm_ops; diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 94c7d2d828a64e42ded09c82497ed7617071aa19..895ecda786194b29d32c9c49785d56a1a84e2096 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -6222,10 +6222,6 @@ vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf) filemap_invalidate_lock_shared(mapping); - err = ext4_convert_inline_data(inode); - if (err) - goto out_ret; - /* * On data journalling we skip straight to the transaction handle: * there's no delalloc; page truncated will be checked later; the --- base-commit: 4a95bc121ccdaee04c4d72f84dbfa6b880a514b6 change-id: 20250519-ext4_inline_page_mkwrite-c42ca1f02295 Best regards, -- Thadeu Lima de Souza Cascardo <cascardo(a)igalia.com>

5 months

3
2
0 0

[PATCH 2/2] mmc: core: sd: Fix and simplify SD card current limit handling

by Avri Altman

The SD spec says: "In UHS-I mode, after selecting one of SDR50, SDR104, or DDR50 mode by Function Group 1, host needs to change the Power Limit to enable the card to operate in higher performance". The driver previously determined SD card current limits incorrectly by checking capability bits before bus speed was established, and by using support bits in function group 4 (bytes 6 & 7) rather than the actual current requirement (bytes 0 & 1). This is wrong because the card responds for a given bus speed. This patch queries the card's current requirement after setting the bus speed, and uses the reported value to select the appropriate current limit. while at it, remove some unused constants and the misleading comment in the code. Fixes: d9812780a020 ("mmc: sd: limit SD card power limit according to cards capabilities") Signed-off-by: Avri Altman <avri.altman(a)sandisk.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/core/sd.c | 36 +++++++++++++----------------------- include/linux/mmc/card.h | 6 ------ 2 files changed, 13 insertions(+), 29 deletions(-) diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index cf92c5b2059a..357edfb910df 100644 --- a/drivers/mmc/core/sd.c +++ b/drivers/mmc/core/sd.c @@ -365,7 +365,6 @@ static int mmc_read_switch(struct mmc_card *card) card->sw_caps.sd3_bus_mode = status[13]; /* Driver Strengths supported by the card */ card->sw_caps.sd3_drv_type = status[9]; - card->sw_caps.sd3_curr_limit = status[7] | status[6] << 8; } out: @@ -556,7 +555,7 @@ static int sd_set_current_limit(struct mmc_card *card, u8 *status) { int current_limit = SD_SET_CURRENT_LIMIT_200; int err; - u32 max_current; + u32 max_current, card_needs; /* * Current limit switch is only defined for SDR50, SDR104, and DDR50 @@ -575,33 +574,24 @@ static int sd_set_current_limit(struct mmc_card *card, u8 *status) max_current = sd_get_host_max_current(card->host); /* - * We only check host's capability here, if we set a limit that is - * higher than the card's maximum current, the card will be using its - * maximum current, e.g. if the card's maximum current is 300ma, and - * when we set current limit to 200ma, the card will draw 200ma, and - * when we set current limit to 400/600/800ma, the card will draw its - * maximum 300ma from the host. - * - * The above is incorrect: if we try to set a current limit that is - * not supported by the card, the card can rightfully error out the - * attempt, and remain at the default current limit. This results - * in a 300mA card being limited to 200mA even though the host - * supports 800mA. Failures seen with SanDisk 8GB UHS cards with - * an iMX6 host. --rmk + * query the card of its maximun current/power consumption given the + * bus speed mode */ - if (max_current >= 800 && - card->sw_caps.sd3_curr_limit & SD_MAX_CURRENT_800) + err = mmc_sd_switch(card, 0, 0, card->sd_bus_speed, status); + if (err) + return err; + + card_needs = status[1] | status[0] << 8; + + if (max_current >= 800 && card_needs > 600) current_limit = SD_SET_CURRENT_LIMIT_800; - else if (max_current >= 600 && - card->sw_caps.sd3_curr_limit & SD_MAX_CURRENT_600) + else if (max_current >= 600 && card_needs > 400) current_limit = SD_SET_CURRENT_LIMIT_600; - else if (max_current >= 400 && - card->sw_caps.sd3_curr_limit & SD_MAX_CURRENT_400) + else if (max_current >= 400 && card_needs > 200) current_limit = SD_SET_CURRENT_LIMIT_400; if (current_limit != SD_SET_CURRENT_LIMIT_200) { - err = mmc_sd_switch(card, SD_SWITCH_SET, 3, - current_limit, status); + err = mmc_sd_switch(card, SD_SWITCH_SET, 3, current_limit, status); if (err) return err; diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h index e9e964c20e53..67c1386ca574 100644 --- a/include/linux/mmc/card.h +++ b/include/linux/mmc/card.h @@ -177,17 +177,11 @@ struct sd_switch_caps { #define SD_DRIVER_TYPE_A 0x02 #define SD_DRIVER_TYPE_C 0x04 #define SD_DRIVER_TYPE_D 0x08 - unsigned int sd3_curr_limit; #define SD_SET_CURRENT_LIMIT_200 0 #define SD_SET_CURRENT_LIMIT_400 1 #define SD_SET_CURRENT_LIMIT_600 2 #define SD_SET_CURRENT_LIMIT_800 3 -#define SD_MAX_CURRENT_200 (1 << SD_SET_CURRENT_LIMIT_200) -#define SD_MAX_CURRENT_400 (1 << SD_SET_CURRENT_LIMIT_400) -#define SD_MAX_CURRENT_600 (1 << SD_SET_CURRENT_LIMIT_600) -#define SD_MAX_CURRENT_800 (1 << SD_SET_CURRENT_LIMIT_800) - #define SD4_SET_POWER_LIMIT_0_72W 0 #define SD4_SET_POWER_LIMIT_1_44W 1 #define SD4_SET_POWER_LIMIT_2_16W 2 -- 2.25.1

5 months

3
6
0 0

[PATCH v2] zynq_fpga: use sgtable-based scatterlist wrappers

by Marek Szyprowski

Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of statterlists related calls. dma_unmap_sg() function has to be called with the number of elements originally passed to the dma_map_sg() function, not the one returned in sgtable's nents. CC: stable(a)vger.kernel.org Fixes: 425902f5c8e3 ("fpga zynq: Use the scatterlist interface") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- v2: - fixed build break (missing flags parameter) --- drivers/fpga/zynq-fpga.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git drivers/fpga/zynq-fpga.c drivers/fpga/zynq-fpga.c index f7e08f7ea9ef..0be0d569589d 100644 --- drivers/fpga/zynq-fpga.c +++ drivers/fpga/zynq-fpga.c @@ -406,7 +406,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr, struct sg_table *sgt) } priv->dma_nelms = - dma_map_sg(mgr->dev.parent, sgt->sgl, sgt->nents, DMA_TO_DEVICE); + dma_map_sgtable(mgr->dev.parent, sgt, DMA_TO_DEVICE, 0); if (priv->dma_nelms == 0) { dev_err(&mgr->dev, "Unable to DMA map (TO_DEVICE)\n"); return -ENOMEM; @@ -478,7 +478,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr, struct sg_table *sgt) clk_disable(priv->clk); out_free: - dma_unmap_sg(mgr->dev.parent, sgt->sgl, sgt->nents, DMA_TO_DEVICE); + dma_unmap_sgtable(mgr->dev.parent, sgt, DMA_TO_DEVICE, 0); return err; } -- 2.34.1

5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025