summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-04-02Merge tag 'iommu-fixes-v7.0-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull iommu fixes from Joerg Roedel: - IOMMU-PT related compile breakage in for AMD driver - IOTLB flushing behavior when unmapped region is larger than requested due to page-sizes - Fix IOTLB flush behavior with empty gathers * tag 'iommu-fixes-v7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommupt/amdv1: mark amdv1pt_install_leaf_entry as __always_inline iommupt: Fix short gather if the unmap goes into a large mapping iommu: Do not call drivers for empty gathers
2026-04-02bpf: Reject sleepable kprobe_multi programs at attach timeVarun R Mallya
kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a "sleeping function called from invalid context" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing. Fixes: 0dcac2725406 ("bpf: Add multi kprobe link") Signed-off-by: Varun R Mallya <varunrmallya@gmail.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Acked-by: Leon Hwang <leon.hwang@linux.dev> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20260401191126.440683-1-varunrmallya@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02bpf: reject direct access to nullable PTR_TO_BUF pointersQi Tang
check_mem_access() matches PTR_TO_BUF via base_type() which strips PTR_MAYBE_NULL, allowing direct dereference without a null check. Map iterator ctx->key and ctx->value are PTR_TO_BUF | PTR_MAYBE_NULL. On stop callbacks these are NULL, causing a kernel NULL dereference. Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the existing PTR_TO_BTF_ID pattern. Fixes: 20b2aff4bc15 ("bpf: Introduce MEM_RDONLY flag") Signed-off-by: Qi Tang <tpluszz77@gmail.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20260402092923.38357-2-tpluszz77@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02Merge tag 'sound-7.0-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "People have been so busy for hunting and we're still getting more changes than wished for, but it doesn't look too scary; almost all changes are device-specific small fixes. I guess it's rather a casual bump, and no more Easter eggs are left for 7.0 (hopefully)... - Fixes for the recent regression on ctxfi driver - Fix missing INIT_LIST_HEAD() for ASoC card_aux_list - Usual HD- and USB-audio, and ASoC AMD quirk updates - ASoC fixes for AMD and Intel" * tag 'sound-7.0-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (24 commits) ASoC: amd: ps: Fix missing leading zeros in subsystem_device SSID log ALSA: usb-audio: Exclude Scarlett 2i2 1st Gen (8016) from SKIP_IFACE_SETUP ALSA: hda/realtek: add quirk for Acer Swift SFG14-73 ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IMH9 ASoC: Intel: boards: fix unmet dependency on PINCTRL ASoC: Intel: ehl_rt5660: Use the correct rtd->dev device in hw_params ALSA: ctxfi: Don't enumerate SPDIF1 at DAIO initialization ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10 ALSA: hda/realtek: add quirk for HP Laptop 15-fc0xxx ASoC: ep93xx: Fix unchecked clk_prepare_enable() and add rollback on failure ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list ALSA: hda/realtek: Add quirk for Samsung Book2 Pro 360 (NP950QED) ASoC: amd: yc: Add DMI entry for HP Laptop 15-fc0xxx ASoC: amd: yc: Add DMI quirk for ASUS Vivobook Pro 16X OLED M7601RM ALSA: hda/realtek: Add quirk for ASUS ROG Strix SCAR 15 ALSA: usb-audio: Exclude Scarlett Solo 1st Gen from SKIP_IFACE_SETUP ALSA: caiaq: fix stack out-of-bounds read in init_card ALSA: ctxfi: Check the error for index mapping ALSA: ctxfi: Fix missing SPDIFI1 index handling ALSA: hda/realtek: add quirk for HP Victus 15-fb0xxx ...
2026-04-02Merge tag 'auxdisplay-v7.0-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay Pull auxdisplay fixes from Andy Shevchenko: - Fix NULL dereference in linedisp_release() - Fix ht16k33 DT bindings to avoid warnings - Handle errors in I²C transfers in lcd2s driver * tag 'auxdisplay-v7.0-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay: auxdisplay: line-display: fix NULL dereference in linedisp_release auxdisplay: lcd2s: add error handling for i2c transfers dt-bindings: auxdisplay: ht16k33: Use unevaluatedProperties to fix common property warning
2026-04-02Merge tag 'reset-fixes-for-v7.0-2' into reset/nextPhilipp Zabel
Reset controller fixes for v7.0, part 2 * Decouple spacemit K3 reset lines that were incorrectly coupled together as one, but are in fact separate resets in hardware. * Fix a double free in the reset_add_gpio_aux_device() error path. This has already been fixed on reset/next by commit a9b95ce36de4 ("reset: gpio: add a devlink between reset-gpio and its consumer"). * Fix the MODULE_AUTHOR string in the rzg2l-usbphy-ctrl driver. We merge this into reset/next to resolve a conflict between commits a9b95ce36de4 ("reset: gpio: add a devlink between reset-gpio and its consumer") and fbffb8c7c7bb ("reset: gpio: fix double free in reset_add_gpio_aux_device() error path"). Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2026-04-02Merge branch 'bpf-migrate-bpf_task_work-and-file-dynptr-to-kmalloc_nolock'Alexei Starovoitov
Mykyta Yatsenko says: ==================== bpf: Migrate bpf_task_work and file dynptr to kmalloc_nolock Now that kmalloc can be used from NMI context via kmalloc_nolock(), migrate BPF internal allocations away from bpf_mem_alloc to use the standard slab allocator. Use kfree_rcu() for deferred freeing, which waits for a regular RCU grace period before the memory is reclaimed. Sleepable BPF programs hold rcu_read_lock_trace but not regular rcu_read_lock, so patch 1 adds explicit rcu_read_lock/unlock around the pointer-to-refcount window to prevent kfree_rcu from freeing memory while a sleepable program is still between reading the pointer and acquiring a reference. Patch 1 migrates bpf_task_work_ctx from bpf_mem_alloc/bpf_mem_free to kmalloc_nolock/kfree_rcu. Patch 2 migrates bpf_dynptr_file_impl from bpf_mem_alloc/bpf_mem_free to kmalloc_nolock/kfree. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> --- Changes in v2: - Switch to scoped_guard in patch 1 (Kumar) - Remove rcu gp wait in patch 2 (Kumar) - Defer to irq_work when irqs disabled in patch 1 - use bpf_map_kmalloc_nolock() for bpf_task_work - use kmalloc_nolock() for file dynptr - Link to v1: https://lore.kernel.org/all/20260325-kmalloc_special-v1-0-269666afb1ea@meta.com/ ==================== Link: https://patch.msgid.link/20260330-kmalloc_special-v2-0-c90403f92ff0@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02bpf: Migrate dynptr file to kmalloc_nolockMykyta Yatsenko
Replace bpf_mem_alloc/bpf_mem_free with kmalloc_nolock/kfree_nolock for bpf_dynptr_file_impl, continuing the migration away from bpf_mem_alloc now that kmalloc can be used from NMI context. freader_cleanup() runs before kfree_nolock() while the dynptr still holds exclusive access, so plain kfree_nolock() is safe — no concurrent readers can access the object. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Acked-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20260330-kmalloc_special-v2-2-c90403f92ff0@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02bpf: Migrate bpf_task_work to kmalloc_nolockMykyta Yatsenko
Replace bpf_mem_alloc/bpf_mem_free with kmalloc_nolock/kfree_rcu for bpf_task_work_ctx. Replace guard(rcu_tasks_trace)() with guard(rcu)() in bpf_task_work_irq(). The function only accesses ctx struct members (not map values), so tasks trace protection is not needed - regular RCU is sufficient since ctx is freed via kfree_rcu. The guard in bpf_task_work_callback() remains as tasks trace since it accesses map values from process context. Sleepable BPF programs hold rcu_read_lock_trace but not regular rcu_read_lock. Since kfree_rcu waits for a regular RCU grace period, the ctx memory can be freed while a sleepable program is still running. Add scoped_guard(rcu) around the pointer read and refcount tryget in bpf_task_work_acquire_ctx to close this race window. Since kfree_rcu uses call_rcu internally which is not safe from NMI context, defer destruction via irq_work when irqs are disabled. For the lost-cmpxchg path the ctx was never published, so kfree_nolock is safe. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20260330-kmalloc_special-v2-1-c90403f92ff0@meta.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02MAINTAINERS: amd-pstate: Step down as maintainer, add Prateek as reviewerGautham R. Shenoy
Mario Limonciello has led amd-pstate maintenance in recent years and has done excellent work. The amd-pstate driver is in good hands with him. I am stepping down as co-maintainer as I move on to other things. Add K Prateek Nayak as a reviewer. He has been actively contributing to the driver including preferred-core and ITMT improvements, and has been helping review amd-pstate patches for a while now. Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Acked-by: K Prateek Nayak <kprateek.nayak@amd.com> Acked-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://lore.kernel.org/r/20260402102611.16519-1-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02cpufreq: Pass the policy to cpufreq_driver->adjust_perf()K Prateek Nayak
cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent writer(s), however amd-pstate depends on fetching the cpudata via the policy's driver data which necessitates grabbing the reference. Since schedutil governor can call "cpufreq_driver->update_perf()" during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled, fetching the policy object using the cpufreq_cpu_get() helper in the scheduler fast-path leads to "BUG: scheduling while atomic" on PREEMPT_RT [1]. Pass the cached cpufreq policy object in sg_policy to the update_perf() instead of just the CPU. The CPU can be inferred using "policy->cpu". The lifetime of cpufreq_policy object outlasts that of the governor and the cpufreq driver (allocated when the CPU is onlined and only reclaimed when the CPU is offlined / the CPU device is removed) which makes it safe to be referenced throughout the governor's lifetime. Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1] Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Reported-by: Bert Karwatzki <spasswolf@web.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Acked-by: Gary Guo <gary@garyguo.net> # Rust Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260316081849.19368-3-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02cpufreq/amd-pstate: Pass the policy to amd_pstate_update()K Prateek Nayak
All callers of amd_pstate_update() already have a reference to the cpufreq_policy object. Pass the entire policy object and grab the cpudata using "policy->driver_data" instead of passing the cpudata and unnecessarily grabbing another read-side reference to the cpufreq policy object when it is already available in the caller. No functional changes intended. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20260316081849.19368-2-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02cpufreq/amd-pstate-ut: Add a unit test for raw EPPMario Limonciello (AMD)
Ensure that all supported raw EPP values work properly. Export the driver helpers used by the test module so the test can drive raw EPP writes and temporarily disable dynamic EPP while it runs. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02Merge branch 'bpf-fix-abuse-of-kprobe_write_ctx-via-freplace'Alexei Starovoitov
Leon Hwang says: ==================== bpf: Fix abuse of kprobe_write_ctx via freplace The potential issue of kprobe_write_ctx+freplace was mentioned in "bpf: Disallow !kprobe_write_ctx progs tail-calling kprobe_write_ctx progs" [1]. It is true issue, that the test in patch #2 verifies that kprobe_write_ctx=false kprobe progs can be abused to modify struct pt_regs via kprobe_write_ctx=true freplace progs. When struct pt_regs is modified, bpf_prog_test_run_opts() gets -EFAULT instead of 0. test_freplace_kprobe_write_ctx:FAIL:bpf_prog_test_run_opts unexpected error: -14 (errno 14) We will disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values. Links: [1] https://lore.kernel.org/bpf/CAP01T74w4KVMn9bEwpQXrk+bqcUxzb6VW1SQ_QvNy0A4EY-9Jg@mail.gmail.com/ Changes: v2 -> v3: * Add comment to the rejection of kprobe_write_ctx (per Jiri). * Use libbpf_get_error() instead of errno in test (per Jiri). * Collect Acked-by tags from Jiri and Song, thanks. v2: https://lore.kernel.org/bpf/20260326141718.17731-1-leon.hwang@linux.dev/ v1 -> v2: * Drop patch #1 in v1, as it wasn't an issue (per Toke). * Check kprobe_write_ctx value at attach time instead of at load time, to prevent attaching kprobe_write_ctx=true freplace progs on kprobe_write_ctx=false kprobe progs (per Gemini/sashiko). * Move kprobe_write_ctx test code to attach_probe.c and kprobe_write_ctx.c. v1: https://lore.kernel.org/bpf/20260324150444.68166-1-leon.hwang@linux.dev/ ==================== Link: https://patch.msgid.link/20260331145353.87606-1-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02selftests/bpf: Add test to verify the fix of kprobe_write_ctx abuseLeon Hwang
Add a test to verify the issue: kprobe_write_ctx can be abused to modify struct pt_regs of kernel functions via kprobe_write_ctx=true freplace progs. Without the fix, the issue is verified: kprobe_write_ctx=true freplace prog is allowed to attach to kprobe_write_ctx=false kprobe prog. Then, the first arg of bpf_fentry_test1 will be set as 0, and bpf_prog_test_run_opts() gets -EFAULT instead of 0. With the fix, the issue is rejected at attach time. Acked-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260331145353.87606-3-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02bpf: Fix abuse of kprobe_write_ctx via freplaceLeon Hwang
uprobe programs are allowed to modify struct pt_regs. Since the actual program type of uprobe is KPROBE, it can be abused to modify struct pt_regs via kprobe+freplace when the kprobe attaches to kernel functions. For example, SEC("?kprobe") int kprobe(struct pt_regs *regs) { return 0; } SEC("?freplace") int freplace_kprobe(struct pt_regs *regs) { regs->di = 0; return 0; } freplace_kprobe prog will attach to kprobe prog. kprobe prog will attach to a kernel function. Without this patch, when the kernel function runs, its first arg will always be set as 0 via the freplace_kprobe prog. To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow attaching freplace programs on kprobe programs with different kprobe_write_ctx values. Fixes: 7384893d970e ("bpf: Allow uprobe program to change context registers") Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Song Liu <song@kernel.org> Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260331145353.87606-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-04-02cpufreq/amd-pstate: Add support for raw EPP writesMario Limonciello (AMD)
The energy performance preference field of the CPPC request MSR supports values from 0 to 255, but the strings only offer 4 values. The other values are useful for tuning the performance of some workloads. Add support for writing the raw energy performance preference value to the sysfs file. If the last value written was an integer then an integer will be returned. If the last value written was a string then a string will be returned. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02cpufreq/amd-pstate: Add support for platform profile classMario Limonciello (AMD)
The platform profile core allows multiple drivers and devices to register platform profile support. When the legacy platform profile interface is used all drivers will adjust the platform profile as well. Add support for registering every CPU with the platform profile handler when dynamic EPP is enabled. The end result will be that changing the platform profile will modify EPP accordingly. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02cpufreq/amd-pstate: add kernel command line to override dynamic eppMario Limonciello (AMD)
Add `amd_dynamic_epp=enable` and `amd_dynamic_epp=disable` to override the kernel configuration option `CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP` locally. Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02cpufreq/amd-pstate: Add dynamic energy performance preferenceMario Limonciello (AMD)
Dynamic energy performance preference changes the EPP profile based on whether the machine is running on AC or DC power. A notification chain from the power supply core is used to adjust EPP values on plug in or plug out events. When enabled, the driver exposes a sysfs toggle for dynamic EPP, blocks manual writes to energy_performance_preference while it "owns" the EPP updates. For non-server systems: * the default EPP for AC mode is `performance`. * the default EPP for DC mode is `balance_performance`. For server systems dynamic EPP is mostly a no-op. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02Documentation: amd-pstate: fix dead links in the reference sectionNinad Naik
The links for AMD64 Architecture Programmer's Manual and PPR for AMD Family 19h Model 51h, Revision A1 Processors redirect to a generic page. Update the links to the working ones. Signed-off-by: Ninad Naik <ninadnaik07@gmail.com> Link: https://lore.kernel.org/r/20260330190855.1115304-1-ninadnaik07@gmail.com Acked-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02cpufreq/amd-pstate: Cache the max frequency in cpudataMario Limonciello (AMD)
The value of maximum frequency is fixed and never changes. Doing calculations every time based off of perf is unnecessary. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20260326193620.649441-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02Documentation/amd-pstate: Add documentation for amd_pstate_floor_{freq,count}Gautham R. Shenoy
Add documentation for the sysfs files /sys/devices/system/cpu/cpufreq/policy*/amd_pstate_floor_freq and /sys/devices/system/cpu/cpufreq/policy*/amd_pstate_floor_count. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02Documentation/amd-pstate: List amd_pstate_prefcore_ranking sysfs fileGautham R. Shenoy
Add the missing amd_pstate_prefcore_ranking filenames in the sysfs listing example leading to the descriptions of these parameters. Clarify when will the file be visible. Fixes: 15a2b764ea7c ("amd-pstate: Add missing documentation for `amd_pstate_prefcore_ranking`") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02Documentation/amd-pstate: List amd_pstate_hw_prefcore sysfs fileGautham R. Shenoy
Add the missing amd_pstate_hw_prefcore filenames in the sysfs listing example leading to the descriptions of these parameters. Clarify when will the file be visible. Fixes: b96b82d1af7f ("cpufreq: amd-pstate: Add documentation for `amd_pstate_hw_prefcore`") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate-ut: Add a testcase to validate the visibility of driver attributesGautham R. Shenoy
amd-pstate driver has per-attribute visibility functions to dynamically control which sysfs freq_attrs are exposed based on the platform capabilities and the current amd_pstate mode. However, there is no test coverage to validate that the driver's live attribute list matches the expected visibility for each mode. Add amd_pstate_ut_check_freq_attrs() to the amd-pstate unit test module. For each enabled mode (passive, active, guided), the test independently derives the expected visibility of each attribute: - Core attributes (max_freq, lowest_nonlinear_freq, highest_perf) are always expected. - Prefcore attributes (prefcore_ranking, hw_prefcore) are expected only when cpudata->hw_prefcore indicates platform support. - EPP attributes (energy_performance_preference, energy_performance_available_preferences) are expected only in active mode. - Floor frequency attributes (floor_freq, floor_count) are expected only when X86_FEATURE_CPPC_PERF_PRIO is present. Compare these independent expectations against the live driver's attr array, catching bugs such as attributes leaking into wrong modes or visibility functions checking incorrect conditions. Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate-ut: Add module parameter to select testcasesGautham R. Shenoy
Currently when amd-pstate-ut test module is loaded, it runs all the tests from amd_pstate_ut_cases[] array. Add a module parameter named "test_list" that accepts a comma-delimited list of test names, allowing users to run a selected subset of tests. When the parameter is omitted or empty, all tests are run as before. Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate: Introduce a tracepoint trace_amd_pstate_cppc_req2()Gautham R. Shenoy
Introduce a new tracepoint trace_amd_pstate_cppc_req2() to track updates to MSR_AMD_CPPC_REQ2. Invoke this while changing the Floor Perf. Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate: Add sysfs support for floor_freq and floor_countGautham R. Shenoy
When Floor Performance feature is supported by the platform, expose two sysfs files: * amd_pstate_floor_freq to allow userspace to request the floor frequency for each CPU. * amd_pstate_floor_count which advertises the number of distinct levels of floor frequencies supported on this platform. Reset the floor_perf to bios_floor_perf in the suspend, offline, and exit paths, and restore the value to the cached user-request floor_freq on the resume and online paths mirroring how bios_min_perf is handled for MSR_AMD_CPPC_REQ. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate: Add support for CPPC_REQ2 and FLOOR_PERFGautham R. Shenoy
Some future AMD processors have feature named "CPPC Performance Priority" which lets userspace specify different floor performance levels for different CPUs. The platform firmware takes these different floor performance levels into consideration while throttling the CPUs under power/thermal constraints. The presence of this feature is indicated by bit 16 of the EDX register for CPUID leaf 0x80000007. More details can be found in AMD Publication titled "AMD64 Collaborative Processor Performance Control (CPPC) Performance Priority" Revision 1.10. The number of distinct floor performance levels supported on the platform will be advertised through the bits 32:39 of the MSR_AMD_CPPC_CAP1. Bits 0:7 of a new MSR MSR_AMD_CPPC_REQ2 (0xc00102b5) will be used to specify the desired floor performance level for that CPU. Add support for the aforementioned MSR_AMD_CPPC_REQ2, and macros for parsing and updating the relevant bits from MSR_AMD_CPPC_CAP1 and MSR_AMD_CPPC_REQ2. On boot if the default value of the MSR_AMD_CPPC_REQ2[7:0] (Floor Perf) is lower than CPPC.lowest_perf, and thus invalid, initialize it to MSR_AMD_CPPC_CAP1.nominal_perf which is a sane default value. Save the boot-time floor_perf during amd_pstate_init_floor_perf(). In a subsequent patch it will be restored in the suspend, offline, and exit paths, mirroring how bios_min_perf is handled for MSR_AMD_CPPC_REQ. Link: https://docs.amd.com/v/u/en-US/69206_1.10_AMD64_CPPC_PUB Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02x86/cpufeatures: Add AMD CPPC Performance Priority feature.Gautham R. Shenoy
Some future AMD processors have feature named "CPPC Performance Priority" which lets userspace specify different floor performance levels for different CPUs. The platform firmware takes these different floor performance levels into consideration while throttling the CPUs under power/thermal constraints. The presence of this feature is indicated by bit 16 of the EDX register for CPUID leaf 0x80000007. More details can be found in AMD Publication titled "AMD64 Collaborative Processor Performance Control (CPPC) Performance Priority" Revision 1.10. Define a new feature bit named X86_FEATURE_CPPC_PERF_PRIO to map to CPUID 0x80000007.EDX[16]. Reviewed-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate: Make certain freq_attrs conditionally visibleGautham R. Shenoy
Certain amd_pstate freq_attrs such as amd_pstate_hw_prefcore and amd_pstate_prefcore_ranking are enabled even when preferred core is not supported on the platform. Similarly there are common freq_attrs between the amd-pstate and the amd-pstate-epp drivers (eg: amd_pstate_max_freq, amd_pstate_lowest_nonlinear_freq, etc.) but are duplicated in two different freq_attr structs. Unify all the attributes in a single place and associate each of them with a visibility function that determines whether the attribute should be visible based on the underlying platform support and the current amd_pstate mode. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate: Update cppc_req_cached in fast_switch caseGautham R. Shenoy
The function msr_update_perf() does not cache the new value that is written to MSR_AMD_CPPC_REQ into the variable cpudata->cppc_req_cached when the update is happening from the fast path. Fix that by caching the value everytime the MSR_AMD_CPPC_REQ gets updated. This issue was discovered by Claude Opus 4.6 with the aid of Chris Mason's AI review-prompts (https://github.com/masoncl/review-prompts/tree/main/kernel). Assisted-by: Claude:claude-opus-4.6 review-prompts/linux Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Fixes: fff395796917 ("cpufreq/amd-pstate: Always write EPP value when updating perf") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02amd-pstate: Fix memory leak in amd_pstate_epp_cpu_init()Gautham R. Shenoy
On failure to set the epp, the function amd_pstate_epp_cpu_init() returns with an error code without freeing the cpudata object that was allocated at the beginning of the function. Ensure that the cpudata object is freed before returning from the function. This memory leak was discovered by Claude Opus 4.6 with the aid of Chris Mason's AI review-prompts (https://github.com/masoncl/review-prompts/tree/main/kernel). Assisted-by: Claude:claude-opus-4.6 review-prompts/linux Fixes: f9a378ff6443 ("cpufreq/amd-pstate: Set different default EPP policy for Epyc and Ryzen") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2026-04-02f2fs: fix to preserve previous reserve_{blocks,node} value when remountZhiguo Niu
The following steps will change previous value of reserve_{blocks,node}, this dones not match the original intention. 1.mount -t f2fs -o reserve_root=8192 imgfile test_mount/ F2FS-fs (loop56): Mounted with checkpoint version = 1b69f8c7 mount info: /dev/block/loop56 on /data/test_mount type f2fs (xxx,reserve_root=8192,reserve_node=0,resuid=0,resgid=0,xxx) 2.mount -t f2fs -o remount,reserve_root=4096 /data/test_mount F2FS-fs (loop56): Preserve previous reserve_root=8192 check mount info: reserve_root change to 4096 /dev/block/loop56 on /data/test_mount type f2fs (xxx,reserve_root=4096,reserve_node=0,resuid=0,resgid=0,xxx) Prior to commit d18535132523 ("f2fs: separate the options parsing and options checking"), the value of reserve_{blocks,node} was only set during the first mount, along with the corresponding mount option F2FS_MOUNT_RESERVE_{ROOT,NODE} . If the mount option F2FS_MOUNT_RESERVE_{ROOT,NODE} was found to have been set during the mount/remount, the previously value of reserve_{blocks,node} would also be preserved, as shown in the code below. if (test_opt(sbi, RESERVE_ROOT)) { f2fs_info(sbi, "Preserve previous reserve_root=%u", F2FS_OPTION(sbi).root_reserved_blocks); } else { F2FS_OPTION(sbi).root_reserved_blocks = arg; set_opt(sbi, RESERVE_ROOT); } But commit d18535132523 ("f2fs: separate the options parsing and options checking") only preserved the previous mount option; it did not preserve the previous value of reserve_{blocks,node}. Since value of reserve_{blocks,node} value is assigned or not depends on ctx->spec_mask, ctx->spec_mask should be alos handled in f2fs_check_opt_consistency. This patch will clear the corresponding ctx->spec_mask bits in f2fs_check_opt_consistency to preserve the previously values of reserve_{blocks,node} if it already have a value. Fixes: d18535132523 ("f2fs: separate the options parsing and options checking") Signed-off-by: Zhiguo Niu <zhiguo.niu@unisoc.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: invalidate block device page cache on umountYongpeng Yang
Neither F2FS nor VFS invalidates the block device page cache, which results in reading stale metadata. An example scenario is shown below: Terminal A Terminal B mount /dev/vdb /mnt/f2fs touch mx // ino = 4 sync dump.f2fs -i 4 /dev/vdb// block on "[Y/N]" touch mx2 // ino = 5 sync umount /mnt/f2fs dump.f2fs -i 5 /dev/vdb // block addr is 0 After umount, the block device page cache is not purged, causing `dump.f2fs -i 5 /dev/vdb` to read stale metadata and see inode 5 with block address 0. Btrfs has encountered a similar issue before, the solution there was to call sync_blockdev() and invalidate_bdev() when the device is closed: mail-archive.com/linux-btrfs@vger.kernel.org/msg54188.html For the root user, the f2fs kernel calls sync_blockdev() on umount to flush all cached data to disk, and f2fs-tools can release the page cache by issuing ioctl(fd, BLKFLSBUF) when accessing the device. However, non-root users are not permitted to drop the page cache, and may still observe stale data. This patch calls sync_blockdev() and invalidate_bdev() during umount to invalidate the block device page cache, thereby preventing stale metadata from being read. Note that this may result in an extra sync_blockdev() call on the first device, in both f2fs_put_super() and kill_block_super(). The second call do nothing, as there are no dirty pages left to flush. It ensures that non-root users do not observe stale data. Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix to freeze GC and discard threads quicklyDaeho Jeong
Suspend can fail if kernel threads do not freeze for a while. f2fs_gc and f2fs_discard threads can perform long-running operations that prevent them from reaching a freeze point in a timely manner. This patch adds explicit freezing checks in the following locations: 1. f2fs_gc: Added a check at the 'retry' label to exit the loop quickly if freezing is requested, especially during heavy GC rounds. 2. __issue_discard_cmd: Added a 'suspended' flag to break both inner and outer loops during discard command issuance if freezing is detected after at least one command has been issued. 3. __issue_discard_cmd_orderly: Added a similar check for orderly discard to ensure responsiveness. These checks ensure that the threads release locks safely and enter the frozen state. Signed-off-by: Daeho Jeong <daehojeong@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix to avoid uninit-value access in f2fs_sanity_check_node_footerChao Yu
syzbot reported a f2fs bug as below: BUG: KMSAN: uninit-value in f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520 f2fs_finish_read_bio+0xe1e/0x1d60 fs/f2fs/data.c:177 f2fs_read_end_io+0x6ab/0x2220 fs/f2fs/data.c:-1 bio_endio+0x1006/0x1160 block/bio.c:1792 submit_bio_noacct+0x533/0x2960 block/blk-core.c:891 submit_bio+0x57a/0x620 block/blk-core.c:926 blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline] f2fs_submit_read_bio+0x12c/0x360 fs/f2fs/data.c:557 f2fs_submit_page_bio+0xee2/0x1450 fs/f2fs/data.c:775 read_node_folio+0x384/0x4b0 fs/f2fs/node.c:1481 __get_node_folio+0x5db/0x15d0 fs/f2fs/node.c:1576 f2fs_get_inode_folio+0x40/0x50 fs/f2fs/node.c:1623 do_read_inode fs/f2fs/inode.c:425 [inline] f2fs_iget+0x1209/0x9380 fs/f2fs/inode.c:596 f2fs_fill_super+0x8f5a/0xb2e0 fs/f2fs/super.c:5184 get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694 get_tree_bdev+0x38/0x50 fs/super.c:1717 f2fs_get_tree+0x35/0x40 fs/f2fs/super.c:5436 vfs_get_tree+0xb3/0x5d0 fs/super.c:1754 fc_mount fs/namespace.c:1193 [inline] do_new_mount_fc fs/namespace.c:3763 [inline] do_new_mount+0x885/0x1dd0 fs/namespace.c:3839 path_mount+0x7a2/0x20b0 fs/namespace.c:4159 do_mount fs/namespace.c:4172 [inline] __do_sys_mount fs/namespace.c:4361 [inline] __se_sys_mount+0x704/0x7f0 fs/namespace.c:4338 __x64_sys_mount+0xe4/0x150 fs/namespace.c:4338 x64_sys_call+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:166 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x134/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is: in f2fs_finish_read_bio(), we may access uninit data in folio if we failed to read the data from device into folio, let's add a check condition to avoid such issue. Cc: stable@kernel.org Fixes: 50ac3ecd8e05 ("f2fs: fix to do sanity check on node footer in {read,write}_end_io") Reported-by: syzbot+9aac813cdc456cdd49f8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/69a9ca26.a70a0220.305d9a.0000.GAE@google.com Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix false alarm of lockdep on cp_global_sem lockChao Yu
lockdep reported a potential deadlock: a) TCMU device removal context: - call del_gendisk() to get q->q_usage_counter - call start_flush_work() to get work_completion of wb->dwork b) f2fs writeback context: - in wb_workfn(), which holds work_completion of wb->dwork - call f2fs_balance_fs() to get sbi->gc_lock c) f2fs vfs_write context: - call f2fs_gc() to get sbi->gc_lock - call f2fs_write_checkpoint() to get sbi->cp_global_sem d) f2fs mount context: - call recover_fsync_data() to get sbi->cp_global_sem - call f2fs_check_and_fix_write_pointer() to call blkdev_report_zones() that goes down to blk_mq_alloc_request and get q->q_usage_counter Original callstack is in Closes tag. However, I think this is a false alarm due to before mount returns successfully (context d), we can not access file therein via vfs_write (context c). Let's introduce per-sb cp_global_sem_key, and assign the key for cp_global_sem, so that lockdep can recognize cp_global_sem from different super block correctly. A lot of work are done by Shin'ichiro Kawasaki, thanks a lot for the work. Fixes: c426d99127b1 ("f2fs: Check write pointer consistency of open zones") Cc: stable@kernel.org Reported-and-tested-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Closes: https://lore.kernel.org/linux-f2fs-devel/20260218125237.3340441-1-shinichiro.kawasaki@wdc.com Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix data loss caused by incorrect use of nat_entry flagYongpeng Yang
Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. The scenario is as follows: create & write & fsync 'file A' write checkpoint - f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_flush_nat_entries - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return false SPO and lost 'file A' f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC flags for the nat_entry, but this does not mean that the checkpoint has actually completed successfully. However, f2fs_need_inode_block_update() checks these flags and incorrectly assumes that the checkpoint has finished. The root cause is that the semantics of IS_CHECKPOINTED and HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully completes. This patch modifies f2fs_need_inode_block_update() to acquire the sbi->node_write lock before reading the nat_entry flags, ensuring that once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the checkpoint operation has already completed. Fixes: e05df3b115e7 ("f2fs: add node operations") Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix to skip empty sections in f2fs_get_victimDaeho Jeong
In age-based victim selection (ATGC, AT_SSR, or GC_CB), f2fs_get_victim can encounter sections with zero valid blocks. This situation often arises when checkpoint is disabled or due to race conditions between SIT updates and dirty list management. In such cases, f2fs_get_section_mtime() returns INVALID_MTIME, which subsequently triggers a fatal f2fs_bug_on(sbi, mtime == INVALID_MTIME) in add_victim_entry() or get_cb_cost(). This patch adds a check in f2fs_get_victim's selection loop to skip sections with no valid blocks. This prevents unnecessary age calculations for empty sections and avoids the associated kernel panic. This change also allows removing redundant checks in add_victim_entry(). Signed-off-by: Daeho Jeong <daehojeong@google.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix inline data not being written to disk in writeback pathYongpeng Yang
When f2fs_fiemap() is called with `fileinfo->fi_flags` containing the FIEMAP_FLAG_SYNC flag, it attempts to write data to disk before retrieving file mappings via filemap_write_and_wait(). However, there is an issue where the file does not get mapped as expected. The following scenario can occur: root@vm:/mnt/f2fs# dd if=/dev/zero of=data.3k bs=3k count=1 root@vm:/mnt/f2fs# xfs_io data.3k -c "fiemap -v 0 4096" data.3k: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..5]: 0..5 6 0x307 The root cause of this issue is that f2fs_write_single_data_page() only calls f2fs_write_inline_data() to copy data from the data folio to the inode folio, and it clears the dirty flag on the data folio. However, it does not mark the data folio as writeback. When __filemap_fdatawait_range() checks for folios with the writeback flag, it returns early, causing f2fs_fiemap() to report that the file has no mapping. To fix this issue, the solution is to call f2fs_write_single_node_folio() in f2fs_inline_data_fiemap() when getting fiemap with FIEMAP_FLAG_SYNC flags. This patch ensures that the inode folio is written back and the writeback process completes before proceeding. Cc: stable@kernel.org Fixes: 9ffe0fb5f3bb ("f2fs: handle inline data operations") Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix fsck inconsistency caused by FGGC of node blockYongpeng Yang
During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data. The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes. In BGGC mode, node block migration is handled by f2fs_sync_node_pages(), which guarantees the dentry and fsync marks are cleared before writing. This patch move the set/clear of the fsync|dentry marks into __write_node_folio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC. Cc: stable@kernel.org Fixes: da011cc0da8c ("f2fs: move node pages only in victim section during GC") Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usageYongpeng Yang
f2fs_need_dentry_mark() reads nat_entry flags without mutual exclusion with the checkpoint path, which can result in an incorrect inode block marking state. The scenario is as follows: create & write & fsync 'file A' write checkpoint - f2fs_do_sync_file // inline inode - f2fs_write_inode // inode folio is dirty - f2fs_write_checkpoint - f2fs_flush_merged_writes - f2fs_sync_node_pages - f2fs_fsync_node_pages // no dirty node - f2fs_need_inode_block_update // return true - f2fs_fsync_node_pages // inode dirtied - f2fs_need_dentry_mark //return true - f2fs_flush_nat_entries - f2fs_write_checkpoint end - __write_node_folio // inode with DENT_BIT_SHIFT set SPO, "fsck --dry-run" find inode has already checkpointed but still with DENT_BIT_SHIFT set The state observed by f2fs_need_dentry_mark() can differ from the state observed in __write_node_folio() after acquiring sbi->node_write. The root cause is that the semantics of IS_CHECKPOINTED and HAS_FSYNCED_INODE are only guaranteed after the checkpoint write has fully completed. This patch moves set_dentry_mark() into __write_node_folio() and protects it with the sbi->node_write lock. Cc: stable@kernel.org Fixes: 88bd02c9472a ("f2fs: fix conditions to remain recovery information in f2fs_sync_file") Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: fix to do sanity check on dcc->discard_cmd_cnt conditionallyChao Yu
Syzbot reported a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:1900! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6527 Comm: syz.5.110 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:f2fs_issue_discard_timeout+0x59b/0x5a0 fs/f2fs/segment.c:1900 Code: d9 80 e1 07 80 c1 03 38 c1 0f 8c d6 fe ff ff 48 89 df e8 a8 5e fa fd e9 c9 fe ff ff e8 4e 46 94 fd 90 0f 0b e8 46 46 94 fd 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc9000494f940 EFLAGS: 00010283 RAX: ffffffff843009ca RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc9001ca78000 RSI: 00000000000029f3 RDI: 00000000000029f4 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: dffffc0000000000 R11: ffffed100893a431 R12: 1ffff1100893a430 R13: 1ffff1100c2b702c R14: dffffc0000000000 R15: ffff8880449d2160 FS: 00007ffa35fed6c0(0000) GS:ffff88812643d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2b68634000 CR3: 0000000039f62000 CR4: 00000000003526f0 Call Trace: <TASK> __f2fs_remount fs/f2fs/super.c:2960 [inline] f2fs_reconfigure+0x108a/0x1710 fs/f2fs/super.c:5443 reconfigure_super+0x227/0x8a0 fs/super.c:1080 do_remount fs/namespace.c:3391 [inline] path_mount+0xdc5/0x10e0 fs/namespace.c:4151 do_mount fs/namespace.c:4172 [inline] __do_sys_mount fs/namespace.c:4361 [inline] __se_sys_mount+0x31d/0x420 fs/namespace.c:4338 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7ffa37dbda0a The root cause is there will be race condition in between f2fs_ioc_fitrim() and f2fs_remount(): - f2fs_remount - f2fs_ioc_fitrim - f2fs_issue_discard_timeout - __issue_discard_cmd - __drop_discard_cmd - __wait_all_discard_cmd - f2fs_trim_fs - f2fs_write_checkpoint - f2fs_clear_prefree_segments - f2fs_issue_discard - __issue_discard_async - __queue_discard_cmd - __update_discard_tree_range - __insert_discard_cmd - __create_discard_cmd : atomic_inc(&dcc->discard_cmd_cnt); - sanity check on dcc->discard_cmd_cnt (expect discard_cmd_cnt to be zero) This will only happen when fitrim races w/ remount rw, if we remount to readonly filesystem, remount will wait until mnt_pcp.mnt_writers to zero, that means fitrim is not in process at that time. Cc: stable@kernel.org Fixes: 2482c4325dfe ("f2fs: detect bug_on in f2fs_wait_discard_bios") Reported-by: syzbot+62538b67389ee582837a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-f2fs-devel/69b07d7c.050a0220.8df7.09a1.GAE@google.com Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: refactor node footer flag setting related codeYongpeng Yang
This patch refactors the node footer flag setting code to simplify redundant logic and adjust function parameters and return types. No logical changes. Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02f2fs: refactor f2fs_move_node_folio functionYongpeng Yang
This patch refactor the f2fs_move_node_folio() function. No logical changes. Cc: stable@kernel.org Signed-off-by: Yongpeng Yang <yangyongpeng@xiaomi.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-04-02KVM: riscv: selftests: Implement kvm_arch_has_default_irqchipMayuresh Chitale
kvm_arch_has_default_irqchip is required for irqfd_test and returns true if an in-kernel interrupt controller is supported. Fixes: a133052666bed ("KVM: selftests: Fix irqfd_test for non-x86 architectures") Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260402101818.2982071-1-mayuresh.chitale@oss.qualcomm.com Signed-off-by: Anup Patel <anup@brainfault.org>
2026-04-02kbuild: vdso_install: drop build ID architecture allow-listThomas Weißschuh
Many architectures which do generate build IDs are missing from this list. For example arm64, riscv, loongarch, mips. Now that errors from readelf and binaries without any build ID are handled gracefully, the allow-list is not necessary anymore, drop it. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260331-kbuild-vdso-install-v2-4-606d0dc6beca@weissschuh.net Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-04-02kbuild: vdso_install: gracefully handle images without build IDThomas Weißschuh
If the vDSO does not contain a build ID, skip the symlink step. This will allow the removal of the explicit list of architectures. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260331-kbuild-vdso-install-v2-3-606d0dc6beca@weissschuh.net Signed-off-by: Nicolas Schier <nsc@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-15 11:14:44 +0000