summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-22Merge branch 'bpf-fix-oob-read-and-add-tests-for-load-acquire-store-release'Alexei Starovoitov
Kohei Enju says: ==================== bpf: Fix OOB read and add tests for load-acquire/store-release This patch series addresses an out-of-bounds read issue in check_atomic_load/store() reported by syzkaller when an invalid register number (MAX_BPF_REG or greater) is used. The first patch fixes the actual bug by changing the order of validity checks, ensuring register validity is checked before atomic_ptr_type_ok() is called. It also updates some tests that were assuming the previous order of checks. The second patch adds new tests specifically for the invalid register number case to prevent regression in the future. Changes: v3: - Change invalid register from R11 to R15 in new tests v2: https://lore.kernel.org/all/20250321110010.95217-4-enjuk@amazon.com/ - Just swap atomic_ptr_type_ok() and check_load_mem()/check_store_reg() - Update some tests that were assuming the previous order of checks - Add new tests specifically for the invalid register number v1: https://lore.kernel.org/bpf/20250314195619.23772-2-enjuk@amazon.com/ Reported-by: syzbot+a5964227adc0f904549c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a5964227adc0f904549c ==================== Link: https://patch.msgid.link/20250322045340.18010-4-enjuk@amazon.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-03-22selftests/bpf: Add selftests for load-acquire/store-release when register ↵Kohei Enju
number is invalid syzbot reported out-of-bounds read in check_atomic_load/store() when the register number is invalid in this context: https://syzkaller.appspot.com/bug?extid=a5964227adc0f904549c To avoid the issue from now on, let's add tests where the register number is invalid for load-acquire/store-release. After discussion with Eduard, I decided to use R15 as invalid register because the actual slab-out-of-bounds read issue occurs when the register number is R12 or larger. Signed-off-by: Kohei Enju <enjuk@amazon.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250322045340.18010-6-enjuk@amazon.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-03-22bpf: Fix out-of-bounds read in check_atomic_load/store()Kohei Enju
syzbot reported the following splat [0]. In check_atomic_load/store(), register validity is not checked before atomic_ptr_type_ok(). This causes the out-of-bounds read in is_ctx_reg() called from atomic_ptr_type_ok() when the register number is MAX_BPF_REG or greater. Call check_load_mem()/check_store_reg() before atomic_ptr_type_ok() to avoid the OOB read. However, some tests introduced by commit ff3afe5da998 ("selftests/bpf: Add selftests for load-acquire and store-release instructions") assume calling atomic_ptr_type_ok() before checking register validity. Therefore the swapping of order unintentionally changes verifier messages of these tests. For example in the test load_acquire_from_pkt_pointer(), expected message is 'BPF_ATOMIC loads from R2 pkt is not allowed' although actual messages are different. validate_msgs:FAIL:754 expect_msg VERIFIER LOG: ============= Global function load_acquire_from_pkt_pointer() doesn't return scalar. Only those are supported. 0: R1=ctx() R10=fp0 ; asm volatile ( @ verifier_load_acquire.c:140 0: (61) r2 = *(u32 *)(r1 +0) ; R1=ctx() R2_w=pkt(r=0) 1: (d3) r0 = load_acquire((u8 *)(r2 +0)) invalid access to packet, off=0 size=1, R2(id=0,off=0,r=0) R2 offset is outside of the packet processed 2 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 ============= EXPECTED SUBSTR: 'BPF_ATOMIC loads from R2 pkt is not allowed' #505/19 verifier_load_acquire/load-acquire from pkt pointer:FAIL This is because instructions in the test don't pass check_load_mem() and therefore don't enter the atomic_ptr_type_ok() path. In this case, we have to modify instructions so that they pass the check_load_mem() and trigger atomic_ptr_type_ok(). Similarly for store-release tests, we need to modify instructions so that they pass check_store_reg(). Like load_acquire_from_pkt_pointer(), modify instructions in: load_acquire_from_sock_pointer() store_release_to_ctx_pointer() store_release_to_pkt_pointer() Also in store_release_to_sock_pointer(), check_store_reg() returns error early and atomic_ptr_type_ok() is not triggered, since write to sock pointer is not possible in general. We might be able to remove the test, but for now let's leave it and just change the expected message. [0] BUG: KASAN: slab-out-of-bounds in is_ctx_reg kernel/bpf/verifier.c:6185 [inline] BUG: KASAN: slab-out-of-bounds in atomic_ptr_type_ok+0x3d7/0x550 kernel/bpf/verifier.c:6223 Read of size 4 at addr ffff888141b0d690 by task syz-executor143/5842 CPU: 1 UID: 0 PID: 5842 Comm: syz-executor143 Not tainted 6.14.0-rc3-syzkaller-gf28214603dc6 #0 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x16e/0x5b0 mm/kasan/report.c:521 kasan_report+0x143/0x180 mm/kasan/report.c:634 is_ctx_reg kernel/bpf/verifier.c:6185 [inline] atomic_ptr_type_ok+0x3d7/0x550 kernel/bpf/verifier.c:6223 check_atomic_store kernel/bpf/verifier.c:7804 [inline] check_atomic kernel/bpf/verifier.c:7841 [inline] do_check+0x89dd/0xedd0 kernel/bpf/verifier.c:19334 do_check_common+0x1678/0x2080 kernel/bpf/verifier.c:22600 do_check_main kernel/bpf/verifier.c:22691 [inline] bpf_check+0x165c8/0x1cca0 kernel/bpf/verifier.c:23821 Reported-by: syzbot+a5964227adc0f904549c@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=a5964227adc0f904549c Tested-by: syzbot+a5964227adc0f904549c@syzkaller.appspotmail.com Fixes: e24bbad29a8d ("bpf: Introduce load-acquire and store-release instructions") Fixes: ff3afe5da998 ("selftests/bpf: Add selftests for load-acquire and store-release instructions") Signed-off-by: Kohei Enju <enjuk@amazon.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250322045340.18010-5-enjuk@amazon.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-03-22i2c: iproc: Refactor prototype and remove redundant error checksWentao Liang
The bcm_iproc_i2c_init() always returns 0. As a result, there is no need to check its return value or handle errors. This patch changes the prototype of bcm_iproc_i2c_init() to return void and removes the redundant error handling code after calls to bcm_iproc_i2c_init() in both the bcm_iproc_i2c_probe() and bcm_iproc_i2c_resume(). Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Acked-by: Ray Jui <ray.jui@broadcom.com> Link: https://lore.kernel.org/r/20250121084818.2719-1-vulab@iscas.ac.cn Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2025-03-22i2c: qcom-geni: Update i2c frequency table to match hardware guidanceMukesh Kumar Savaliya
With the current settings, the I2C buses are achieving around 370KHz instead of the expected 400KHz. For 100KHz and 1MHz, the settings are now more compliant and adhere to the Qualcomm’s internal programming guide. Update the I2C frequency table to align with the recommended values outlined in the I2C hardware programming guide, ensuring proper communication and performance. Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20250122064634.2864432-1-quic_msavaliy@quicinc.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2025-03-22i2c: mlxbf: Use readl_poll_timeout_atomic() for pollingAndy Shevchenko
Convert the usage of an open-coded custom tight poll while loop with the provided readl_poll_timeout_atomic() macro. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com> Link: https://lore.kernel.org/r/20250212165128.2413430-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2025-03-22i2c: pasemi: Add registers bits and switch to BIT()Sven Peter
Add the missing register bits to the defines and also switch those to use the BIT macro which is much more readable than using hardcoded masks Co-developed-by: Hector Martin <marcan@marcan.st> Signed-off-by: Hector Martin <marcan@marcan.st> Signed-off-by: Sven Peter <sven@svenpeter.dev> Reviewed-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250222-pasemi-fixes-v1-1-d7ea33d50c5e@svenpeter.dev
2025-03-22i2c: k1: Initialize variable before useAndi Shyti
Commit 95a8ca229032 ("i2c: spacemit: add support for SpacemiT K1 SoC") introduced a check in the probe function to warn the user if the DTS has incorrect frequency settings. In such cases, the driver falls back to default values. However, the return value of of_property_read_u32() was not stored, making the check ineffective. Fix this by storing the return value in 'ret' and evaluating it properly. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202503200928.eBWfwnHG-lkp@intel.com/ Cc: Troy Mitchell <troymitchell988@gmail.com> Link: https://lore.kernel.org/r/20250320113521.3966762-1-andi.shyti@kernel.org Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
2025-03-22rust: hrtimer: add maintainer entryAndreas Hindborg
Add Andreas Hindborg as maintainer for Rust `hrtimer` abstractions. Also add Boqun Feng as reviewer. Acked-by: Boqun Feng <boqun.feng@gmail.com> Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-13-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: add clocksource selection through `ClockId`Andreas Hindborg
Allow selecting a clock source for timers by passing a `ClockId` variant to `HrTimer::new`. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-12-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: add `HrTimerMode`Andreas Hindborg
Allow selection of timer mode by passing a `HrTimerMode` variant to `HrTimer::new`. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-11-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: implement `HrTimerPointer` for `Pin<Box<T>>`Andreas Hindborg
Allow `Pin<Box<T>>` to be the target of a timer callback. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-10-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: alloc: add `Box::into_pin`Andreas Hindborg
Add an associated function to convert a `Box<T>` into a `Pin<Box<T>>`. Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-9-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: implement `UnsafeHrTimerPointer` for `Pin<&mut T>`Andreas Hindborg
Allow pinned mutable references to structs that contain a `HrTimer` node to be scheduled with the `hrtimer` subsystem. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-8-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: implement `UnsafeHrTimerPointer` for `Pin<&T>`Andreas Hindborg
Allow pinned references to structs that contain a `HrTimer` node to be scheduled with the `hrtimer` subsystem. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-7-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: add `hrtimer::ScopedHrTimerPointer`Andreas Hindborg
Add the trait `ScopedHrTimerPointer` to allow safe use of stack allocated timers. Safety is achieved by pinning the stack in place while timers are running. Implement the trait for all types that implement `UnsafeHrTimerPointer`. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-6-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: add `UnsafeHrTimerPointer`Andreas Hindborg
Add a trait to allow unsafely queuing stack allocated timers. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-5-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22rust: hrtimer: allow timer restart from timer handlerAndreas Hindborg
Allow timer handlers to report that they want a timer to be restarted after the timer handler has finished executing. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-4-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-22tracing: Fix use-after-free in print_graph_function_flags during tracer ↵Tengda Wu
switching Kairui reported a UAF issue in print_graph_function_flags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(), and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer The root cause lies in the two calls to print_graph_function_flags within print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns. Tracer switching only updates the former, while the latter continues to use the print_line function of the old tracer, which in the script above is print_graph_function_flags. Moreover, when switching from the 'function_graph' tracer to the 'timerlat' tracer, s_start only calls graph_trace_close of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'. To fix this issue, set 'iter->private' to NULL immediately after freeing it in graph_trace_close(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/ Cc: stable@vger.kernel.org Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Zheng Yejian <zhengyejian1@huawei.com> Link: https://lore.kernel.org/20250320122137.23635-1-wutengda@huaweicloud.com Fixes: eecb91b9f98d ("tracing: Fix memleak due to race between current_tracer and trace") Closes: https://lore.kernel.org/all/CAMgjq7BW79KDSCyp+tZHjShSzHsScSiJxn5ffskp-QzVM06fxw@mail.gmail.com/ Reported-by: Kairui Song <kasong@tencent.com> Signed-off-by: Tengda Wu <wutengda@huaweicloud.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-03-22tracing: gfp: vsprintf: Do not print "none" when using %pGg printf formatPetr Mladek
The commit ca29a0bf122145 ("tracing: gfp: Remove duplication of recording GFP flags") caused the following regression in printf_test selftest: [ 46.208199] test_printf: kvasprintf(..., "%pGg", ...) returned 'none|0xfc000000', expected '0xfc000000' [ 46.208209] test_printf: kvasprintf(..., "%pGg", ...) returned '__GFP_HIGH|none|0xfc000000', expected '__GFP_HIGH|0xfc000000' The problem is the new '{ 0, "none" }' entry in __def_gfpflag_names macro and the following code: char *format_flags(char *buf, char *end, unsigned long flags, const struct trace_print_flags *names) { [...] if ((flags & mask) != mask) continue; [...] } The purpose of the code is to print the name of a mask instead of bits, for example, printk "GFP_ZONEMASK", instead of "__GFP_DMA|__GFP_HIGHMEM|__GFP_DMA32|__GFP_MOVABLE". Unfortunately, the mask "0" pass this check and "none" is always printed. A solution would be to move TRACE_GFP_FLAGS up so that it is not the last entry. But it breaks the rule that named masks must be defined before names of single bytes. Otherwise, it would print the names of the bytes instead of the mask. Instead, replace '{ 0, "none" }' with '{ 0, NULL }'. It works because __def_gfpflag_names defines a standalone array and this is the standard trailing entry. The code processing these arrays always ends the cycle when flag->name == NULL. Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michael Petlan <mpetlan@redhat.com> Cc: Veronika Molnarova <vmolnaro@redhat.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Tamir Duberstein <tamird@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/Z9Q5d11ZbA3CNMZm@pathway.suse.cz Fixes: ca29a0bf122145 ("tracing: gfp: Remove duplication of recording GFP flags") Signed-off-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-03-22tracing: Disable branch profiling in noinstr codeJosh Poimboeuf
CONFIG_TRACE_BRANCH_PROFILING inserts a call to ftrace_likely_update() for each use of likely() or unlikely(). That breaks noinstr rules if the affected function is annotated as noinstr. Disable branch profiling for files with noinstr functions. In addition to some individual files, this also includes the entire arch/x86 subtree, as well as the kernel/entry, drivers/cpuidle, and drivers/idle directories, all of which are noinstr-heavy. Due to the nature of how sched binaries are built by combining multiple .c files into one, branch profiling is disabled more broadly across the sched code than would otherwise be needed. This fixes many warnings like the following: vmlinux.o: warning: objtool: do_syscall_64+0x40: call to ftrace_likely_update() leaves .noinstr.text section vmlinux.o: warning: objtool: __rdgsbase_inactive+0x33: call to ftrace_likely_update() leaves .noinstr.text section vmlinux.o: warning: objtool: handle_bug.isra.0+0x198: call to ftrace_likely_update() leaves .noinstr.text section ... Reported-by: Ingo Molnar <mingo@kernel.org> Suggested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/fb94fc9303d48a5ed370498f54500cc4c338eb6d.1742586676.git.jpoimboe@kernel.org
2025-03-22ALSA: hda/realtek: Add support for various HP Laptops using CS35L41 HDAStefan Binding
Add support for HP Cadet, Clipper OmniBook, Turbine OmniBook, Trekker, Enstrom Onmibook, Piston Omnibook Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with I2C Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com> Link: https://patch.msgid.link/20250321231717.1232792-1-sbinding@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-03-22x86/speculation: Remove the extra #ifdef around CALL_NOSPECPawan Gupta
Commit: 010c4a461c1d ("x86/speculation: Simplify and make CALL_NOSPEC consistent") added an #ifdef CONFIG_MITIGATION_RETPOLINE around the CALL_NOSPEC definition. This is not required as this code is already under a larger #ifdef. Remove the extra #ifdef, no functional change. vmlinux size remains same before and after this change: CONFIG_MITIGATION_RETPOLINE=y: text data bss dec hex filename 25434752 7342290 2301212 35078254 217406e vmlinux.before 25434752 7342290 2301212 35078254 217406e vmlinux.after # CONFIG_MITIGATION_RETPOLINE is not set: text data bss dec hex filename 22943094 6214994 1550152 30708240 1d49210 vmlinux.before 22943094 6214994 1550152 30708240 1d49210 vmlinux.after Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/20250320-call-nospec-extra-ifdef-v1-1-d9b084d24820@linux.intel.com
2025-03-22perf/amd/ibs: Prevent leaking sensitive data to userspaceNamhyung Kim
Although IBS "swfilt" can prevent leaking samples with kernel RIP to the userspace, there are few subtle cases where a 'data' address and/or a 'branch target' address can fall under kernel address range although RIP is from userspace. Prevent leaking kernel 'data' addresses by discarding such samples when {exclude_kernel=1,swfilt=1}. IBS can now be invoked by unprivileged user with the introduction of "swfilt". However, this creates a loophole in the interface where an unprivileged user can get physical address of the userspace virtual addresses through IBS register raw dump (PERF_SAMPLE_RAW). Prevent this as well. This upstream commit fixed the most obvious leak: 65a99264f5e5 perf/x86: Check data address for IBS software filter Follow that up with a more complete fix. Fixes: d29e744c7167 ("perf/x86: Relax privilege filter restriction on AMD IBS") Suggested-by: Matteo Rizzo <matteorizzo@google.com> Co-developed-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250321161251.1033-1-ravi.bangoria@amd.com
2025-03-22x86/Kconfig: Document release year of glibc 2.3.3Mateusz Jończyk
I wonder how many people were checking their glibc version when considering whether to enable this option. Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-7-b0cbaa6fa338@ixit.cz
2025-03-22x86/Kconfig: Make CONFIG_PCI_CNB20LE_QUIRK depend on X86_32Mateusz Jończyk
I was unable to find a good description of the ServerWorks CNB20LE chipset. However, it was probably exclusively used with the Pentium III processor (this CPU model was used in all references to it that I found where the CPU model was provided: dmesgs in [1] and [2]; [3] page 2; [4]-[7]). As is widely known, the Pentium III processor did not support the 64-bit mode, support for which was introduced by Intel a couple of years later. So it is safe to assume that no systems with the CNB20LE chipset have amd64 and the CONFIG_PCI_CNB20LE_QUIRK may now depend on X86_32. Additionally, I have determined that most computers with the CNB20LE chipset did have ACPI support and this driver was inactive on them. I have submitted a patch to remove this driver, but it was met with resistance [8]. [1] Jim Studt, Re: Problem with ServerWorks CNB20LE and lost interrupts Linux Kernel Mailing List, https://lkml.org/lkml/2002/1/11/111 [2] RedHat Bug 665109 - e100 problems on old Compaq Proliant DL320 https://bugzilla.redhat.com/show_bug.cgi?id=665109 [3] R. Hughes-Jones, S. Dallison, G. Fairey, Performance Measurements on Gigabit Ethernet NICs and Server Quality Motherboards, http://datatag.web.cern.ch/papers/pfldnet2003-rhj.doc [4] "Hardware for Linux", Probe #d6b5151873 of Intel STL2-bd A28808-302 Desktop Computer (STL2) https://linux-hardware.org/?probe=d6b5151873 [5] "Hardware for Linux", Probe #0b5d843f10 of Compaq ProLiant DL380 https://linux-hardware.org/?probe=0b5d843f10 [6] Ubuntu Forums, Dell Poweredge 2400 - Adaptec SCSI Bus AIC-7880 https://ubuntuforums.org/showthread.php?t=1689552 [7] Ira W. Snyder, "BISECTED: 2.6.35 (and -git) fail to boot: APIC problems" https://lkml.org/lkml/2010/8/13/220 [8] Bjorn Helgaas, "Re: [PATCH] x86/pci: drop ServerWorks / Broadcom CNB20LE PCI host bridge driver" https://lore.kernel.org/lkml/20220318165535.GA840063@bhelgaas/T/ Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: David Heideberg <david@ixit.cz> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-6-b0cbaa6fa338@ixit.cz
2025-03-22x86/Kconfig: Document CONFIG_PCI_MMCONFIGMateusz Jończyk
This configuration option had no help text, so add it. CONFIG_EXPERT is enabled on some distribution kernels, so people using a distribution kernel's configuration as a starting point will see this option. [ mingo: Standardized the new Kconfig text a bit. ] Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: David Heideberg <david@ixit.cz> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-5-b0cbaa6fa338@ixit.cz
2025-03-22x86/Kconfig: Update lists in X86_EXTENDED_PLATFORMMateusz Jończyk
The order of the entries matches the order they appear in Kconfig. In 2011, AMD Elan was moved to Kconfig.cpu and the dependency on X86_EXTENDED_PLATFORM was dropped in: ce9c99af8d4b ("x86, cpu: Move AMD Elan Kconfig under "Processor family"") Support for Moorestown MID devices was removed in 2012 in: 1a8359e411eb ("x86/mid: Remove Intel Moorestown") SGI 320/540 (Visual Workstation) was removed in 2014 in: c5f9ee3d665a ("x86, platforms: Remove SGI Visual Workstation") Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: David Heideberg <david@ixit.cz> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-4-b0cbaa6fa338@ixit.cz
2025-03-22x86/Kconfig: Move all X86_EXTENDED_PLATFORM options togetherMateusz Jończyk
So that these options will be displayed together in menuconfig etc. Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: David Heidelberg <david@ixit.cz> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-3-b0cbaa6fa338@ixit.cz
2025-03-22x86/Kconfig: Always enable ARCH_SPARSEMEM_ENABLEMateusz Jończyk
It appears that (X86_64 || X86_32) is always true on x86. This logical OR directive was introduced in: 6ea3038648da ("arch/x86: remove depends on CONFIG_EXPERIMENTAL") By (EXPERIMENTAL && X86_32) turning into (X86_32). Since this change was an identity transformation, nobody noticed that the condition turned into 'true'. [ mingo: Updated changelog ] Fixes: 6ea3038648da ("arch/x86: remove depends on CONFIG_EXPERIMENTAL") Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: David Heideberg <david@ixit.cz> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-2-b0cbaa6fa338@ixit.cz
2025-03-22x86/Kconfig: Enable X86_X2APIC by default and improve help textMateusz Jończyk
As many current platforms (most modern Intel CPUs and QEMU) have x2APIC present, enable CONFIG_X86_X2APIC by default as it gives performance and functionality benefits. Additionally, if the BIOS has already switched APIC to x2APIC mode, but CONFIG_X86_X2APIC is disabled, the kernel will panic in arch/x86/kernel/apic/apic.c . Also improve the help text, which was confusing and really did not describe what the feature is about. Help text references and discussion: Both Intel [1] and AMD [3] spell the name as "x2APIC", not "x2apic". "It allows faster access to the local APIC" [2], chapter 2.1, page 15: "More efficient MSR interface to access APIC registers." "x2APIC was introduced in Intel CPUs around 2008": I was unable to find specific information which Intel CPUs support x2APIC. Wikipedia claims it was "introduced with the Nehalem microarchitecture in November 2008", but I was not able to confirm this independently. At least some Nehalem CPUs do not support x2APIC [1]. The documentation [2] is dated June 2008. Linux kernel also introduced x2APIC support in 2008, so the year seems to be right. "and in AMD EPYC CPUs in 2019": [3], page 15: "AMD introduced an x2APIC in our EPYC 7002 Series processors for the first time." "It is also frequently emulated in virtual machines, even when the host CPU does not support it." [1] "If this configuration option is disabled, the kernel will not boot on some platforms that have x2APIC enabled." According to some BIOS documentation [4], the x2APIC may be "disabled", "enabled", or "force enabled" on this system. I think that "enabled" means "made available to the operating system, but not already turned on" and "force enabled" means "already switched to x2APIC mode when the OS boots". Only in the latter mode a kernel without CONFIG_X86_X2APIC will panic in validate_x2apic() in arch/x86/kernel/apic/apic.c . QEMU 4.2.1 and my Intel HP laptop (bought in 2019) use the "enabled" mode and the kernel does not panic. [1] "Re: [Qemu-devel] [Question] why x2apic's set by default without host sup" https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03527.html [2] Intel® 64 Architecture x2APIC Specification, ( https://www.naic.edu/~phil/software/intel/318148.pdf ) [3] Workload Tuning Guide for AMD EPYC ™ 7002 Series Processor Based Servers Application Note, https://developer.amd.com/wp-content/resources/56745_0.80.pdf [4] UEFI System Utilities and Shell Command Mobile Help for HPE ProLiant Gen10, ProLiant Gen10 Plus Servers and HPE Synergy: Enabling or disabling Processor x2APIC Support https://techlibrary.hpe.com/docs/iss/proliant-gen10-uefi/s_enable_disable_x2APIC_support.html Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250321-x86_x2apic-v3-1-b0cbaa6fa338@ixit.cz
2025-03-21mailmap: consolidate email addresses of Alexander SverdlinAlexander Sverdlin
Alias all the addresses used in the past and currently to the single contact address. Link: https://lkml.kernel.org/r/20250319085251.3335678-1-alexander.sverdlin@siemens.com Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21fs/procfs: fix the comment above proc_pid_wchan()Bart Van Assche
proc_pid_wchan() used to report kernel addresses to user space but that is no longer the case today. Bring the comment above proc_pid_wchan() in sync with the implementation. Link: https://lkml.kernel.org/r/20250319210222.1518771-1-bvanassche@acm.org Fixes: b2f73922d119 ("fs/proc, core/debug: Don't expose absolute kernel addresses via wchan") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Cc: Kees Cook <kees@kernel.org> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21relay: use kasprintf() instead of fixed buffer formattingAndy Shevchenko
Improve readability and maintainability by replacing a hard coded string allocation and formatting by using the kasprintf() helper. It also eliminates the GCC compiler warning (with CONFIG_WERROR=y, which is default, it becomes an error: kernel/relay.c:357:42: error: `snprintf' output may be truncated before the last format character [-Werror=format-truncation=] Link: https://lkml.kernel.org/r/20250317212948.1811176-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21resource: replace open coded variant of DEFINE_RES()Andy Shevchenko
Replace open coded variant of DEFINE_RES(). No functional changes intended. Link: https://lkml.kernel.org/r/20250317181412.1560630-5-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21resource: replace open coded variants of DEFINE_RES_*_NAMED()Andy Shevchenko
Replace open coded variants of DEFINE_RES_*_NAMED(). Link: https://lkml.kernel.org/r/20250317181412.1560630-4-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21resource: replace open coded variant of DEFINE_RES_NAMED_DESC()Andy Shevchenko
Replace open coded variant of DEFINE_RES_NAMED_DESC(). Link: https://lkml.kernel.org/r/20250317181412.1560630-3-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21resource: split DEFINE_RES_NAMED_DESC() out of DEFINE_RES_NAMED()Andy Shevchenko
Patch series "resource: Split and use DEFINE_RES*() macros", v2. Replace open coded variants of DEFINE_RES*() macros. Note, there are many more possibilities over the kernel and even in reources.c, however the latter contains not so trivial leftovers. That's why the examples cover only straightforward conversions. This patch (of 4): In some cases it would be useful to supply predefined descriptor of the resource. For this, introduce DEFINE_RES_NAMED_DESC() macro. While at it, provide DEFINE_RES() that takes only start, size, and flags. Link: https://lkml.kernel.org/r/20250317181412.1560630-1-andriy.shevchenko@linux.intel.com Link: https://lkml.kernel.org/r/20250317181412.1560630-2-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21samples: add hung_task detector mutex blocking sampleMasami Hiramatsu (Google)
Add a hung_task detector mutex blocking test sample code. This module will create a dummy file on the debugfs. That file will cause the read process to sleep for enough long time (256 seconds) while holding a mutex. As a result, the second process will wait on the mutex for a prolonged duration and be detected by the hung_task detector. Usage is; > cd /sys/kernel/debug/hung_task > cat mutex & cat mutex and wait for hung_task message. [akpm@linux-foundation.org: make `hung_task_dir' static] Closes: https://lore.kernel.org/oe-kbuild-all/202503180827.4StpuFrD-lkp@intel.com/ Link: https://lkml.kernel.org/r/174046696281.2194069.4567490148001547311.stgit@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Cc: Anna Schumaker <anna.schumaker@oracle.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Joel Granados <joel.granados@kernel.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Lance Yang <ioworker0@gmail.com> Cc: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Waiman Long <longman@redhat.com> Cc: Will Deacon <will@kernel.org> Cc: Yongliang Gao <leonylgao@tencent.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21hung_task: show the blocker task if the task is hung on mutexMasami Hiramatsu (Google)
Patch series "hung_task: Dump the blocking task stacktrace", v4. The hung_task detector is very useful for detecting the lockup. However, since it only dumps the blocked (uninterruptible sleep) processes, it is not enough to identify the root cause of that lockup. For example, if a process holds a mutex and sleep an event in interruptible state long time, the other processes will wait on the mutex in uninterruptible state. In this case, the waiter processes are dumped, but the blocker process is not shown because it is sleep in interruptible state. This adds a feature to dump the blocker task which holds a mutex when detecting a hung task. e.g. INFO: task cat:115 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-00003-ga8946be3de00 #156 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:cat state:D stack:13432 pid:115 tgid:115 ppid:106 task_flags:0x400100 flags:0x00000002 Call Trace: <TASK> __schedule+0x731/0x960 ? schedule_preempt_disabled+0x54/0xa0 schedule+0xb7/0x140 ? __mutex_lock+0x51b/0xa60 ? __mutex_lock+0x51b/0xa60 schedule_preempt_disabled+0x54/0xa0 __mutex_lock+0x51b/0xa60 read_dummy+0x23/0x70 full_proxy_read+0x6a/0xc0 vfs_read+0xc2/0x340 ? __pfx_direct_file_splice_eof+0x10/0x10 ? do_sendfile+0x1bd/0x2e0 ksys_read+0x76/0xe0 do_syscall_64+0xe3/0x1c0 ? exc_page_fault+0xa9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x4840cd RSP: 002b:00007ffe99071828 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd RDX: 0000000000001000 RSI: 00007ffe99071870 RDI: 0000000000000003 RBP: 00007ffe99071870 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000 R13: 00000000132fd3a0 R14: 0000000000000001 R15: ffffffffffffffff </TASK> INFO: task cat:115 is blocked on a mutex likely owned by task cat:114. task:cat state:S stack:13432 pid:114 tgid:114 ppid:106 task_flags:0x400100 flags:0x00000002 Call Trace: <TASK> __schedule+0x731/0x960 ? schedule_timeout+0xa8/0x120 schedule+0xb7/0x140 schedule_timeout+0xa8/0x120 ? __pfx_process_timeout+0x10/0x10 msleep_interruptible+0x3e/0x60 read_dummy+0x2d/0x70 full_proxy_read+0x6a/0xc0 vfs_read+0xc2/0x340 ? __pfx_direct_file_splice_eof+0x10/0x10 ? do_sendfile+0x1bd/0x2e0 ksys_read+0x76/0xe0 do_syscall_64+0xe3/0x1c0 ? exc_page_fault+0xa9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x4840cd RSP: 002b:00007ffe3e0147b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd RDX: 0000000000001000 RSI: 00007ffe3e014800 RDI: 0000000000000003 RBP: 00007ffe3e014800 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000 R13: 000000001a0a93a0 R14: 0000000000000001 R15: ffffffffffffffff </TASK> TBD: We can extend this feature to cover other locks like rwsem and rt_mutex, but rwsem requires to dump all the tasks which acquire and wait that rwsem. We can follow the waiter link but the output will be a bit different compared with mutex case. This patch (of 2): The "hung_task" shows a long-time uninterruptible slept task, but most often, it's blocked on a mutex acquired by another task. Without dumping such a task, investigating the root cause of the hung task problem is very difficult. This introduce task_struct::blocker_mutex to point the mutex lock which this task is waiting for. Since the mutex has "owner" information, we can find the owner task and dump it with hung tasks. Note: the owner can be changed while dumping the owner task, so this is "likely" the owner of the mutex. With this change, the hung task shows blocker task's info like below; INFO: task cat:115 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-00003-ga8946be3de00 #156 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:cat state:D stack:13432 pid:115 tgid:115 ppid:106 task_flags:0x400100 flags:0x00000002 Call Trace: <TASK> __schedule+0x731/0x960 ? schedule_preempt_disabled+0x54/0xa0 schedule+0xb7/0x140 ? __mutex_lock+0x51b/0xa60 ? __mutex_lock+0x51b/0xa60 schedule_preempt_disabled+0x54/0xa0 __mutex_lock+0x51b/0xa60 read_dummy+0x23/0x70 full_proxy_read+0x6a/0xc0 vfs_read+0xc2/0x340 ? __pfx_direct_file_splice_eof+0x10/0x10 ? do_sendfile+0x1bd/0x2e0 ksys_read+0x76/0xe0 do_syscall_64+0xe3/0x1c0 ? exc_page_fault+0xa9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x4840cd RSP: 002b:00007ffe99071828 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd RDX: 0000000000001000 RSI: 00007ffe99071870 RDI: 0000000000000003 RBP: 00007ffe99071870 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000 R13: 00000000132fd3a0 R14: 0000000000000001 R15: ffffffffffffffff </TASK> INFO: task cat:115 is blocked on a mutex likely owned by task cat:114. task:cat state:S stack:13432 pid:114 tgid:114 ppid:106 task_flags:0x400100 flags:0x00000002 Call Trace: <TASK> __schedule+0x731/0x960 ? schedule_timeout+0xa8/0x120 schedule+0xb7/0x140 schedule_timeout+0xa8/0x120 ? __pfx_process_timeout+0x10/0x10 msleep_interruptible+0x3e/0x60 read_dummy+0x2d/0x70 full_proxy_read+0x6a/0xc0 vfs_read+0xc2/0x340 ? __pfx_direct_file_splice_eof+0x10/0x10 ? do_sendfile+0x1bd/0x2e0 ksys_read+0x76/0xe0 do_syscall_64+0xe3/0x1c0 ? exc_page_fault+0xa9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x4840cd RSP: 002b:00007ffe3e0147b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000004840cd RDX: 0000000000001000 RSI: 00007ffe3e014800 RDI: 0000000000000003 RBP: 00007ffe3e014800 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000001000000 R11: 0000000000000246 R12: 0000000000001000 R13: 000000001a0a93a0 R14: 0000000000000001 R15: ffffffffffffffff </TASK> [akpm@linux-foundation.org: implement debug_show_blocker() in C rather than in CPP] Link: https://lkml.kernel.org/r/174046694331.2194069.15472952050240807469.stgit@mhiramat.tok.corp.google.com Link: https://lkml.kernel.org/r/174046695384.2194069.16796289525958195643.stgit@mhiramat.tok.corp.google.com Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Waiman Long <longman@redhat.com> Reviewed-by: Lance Yang <ioworker0@gmail.com> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Cc: Anna Schumaker <anna.schumaker@oracle.com> Cc: Boqun Feng <boqun.feng@gmail.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Joel Granados <joel.granados@kernel.org> Cc: Kent Overstreet <kent.overstreet@linux.dev> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Will Deacon <will@kernel.org> Cc: Yongliang Gao <leonylgao@tencent.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21mm/page_alloc: remove unnecessary __maybe_unused in order_to_pindex()Liu Ye
The `movable` variable is always used when `CONFIG_TRANSPARENT_HUGEPAGE` is enabled, so the `__maybe_unused` attribute is not necessary. This patch removes it and keeps the variable declaration within the `#ifdef` block for better clarity. Link: https://lkml.kernel.org/r/20250319091726.401158-1-liuyerd@163.com Signed-off-by: Liu Ye<liuye@kylinos.cn> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21x86/mm: restore early initialization of high_memory for 32-bitsMike Rapoport (Microsoft)
Kernel test robot reports the following crash on 32-bit system with HIGHMEM and DEBUG_VIRTUAL: [ 0.056128][ T0] kernel BUG at arch/x86/mm/physaddr.c:77! PANIC: early exception 0x06 IP 60:c116539d error 0 cr2 0x0 [ 0.056916][ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.14.0-rc4-00010-ga4dbe5c71817 #1 [ 0.057570][ T0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 0.058299][ T0] EIP: __phys_addr (arch/x86/mm/physaddr.c:77) [ 0.058633][ T0] Code: 00 74 33 89 f0 e8 d3 8b 2e 00 89 c3 0f b6 d0 b8 58 bb 4b c5 31 c9 6a 00 e8 70 f5 15 00 83 c4 04 84 db 74 25 ff 05 78 de 5d c5 <0f> 0b b8 c8 91 ea c4 e8 e7 6e ea ff b8 58 bb 4b c5 31 d2 31 c9 6a All code [ 0.060017][ T0] EAX: 00000000 EBX: c61f7001 ECX: 00000000 EDX: 00000000 [ 0.060519][ T0] ESI: c61f7000 EDI: 061f7000 EBP: c4e31f04 ESP: c61f7000 [ 0.061016][ T0] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: cff4 EFLAGS: 00210002 [ 0.061560][ T0] CR0: 80050033 CR2: 00000000 CR3: 059fc000 CR4: 00000090 [ 0.062060][ T0] Call Trace: [ 0.062288][ T0] ? show_regs (arch/x86/kernel/dumpstack.c:478) [ 0.062588][ T0] ? early_fixup_exception (arch/x86/include/asm/nospec-branch.h:595) [ 0.062968][ T0] ? early_idt_handler_common (arch/x86/kernel/head_32.S:352) [ 0.063360][ T0] ? __phys_addr (arch/x86/mm/physaddr.c:77) [ 0.063677][ T0] ? one_page_table_init (arch/x86/mm/init_32.c:100) [ 0.064037][ T0] ? page_table_range_init (arch/x86/mm/init_32.c:227) [ 0.064411][ T0] ? permanent_kmaps_init (include/linux/pgtable.h:191 include/linux/pgtable.h:196 arch/x86/mm/init_32.c:395) [ 0.064814][ T0] ? paging_init (arch/x86/mm/init_32.c:677) [ 0.065118][ T0] ? native_pagetable_init (arch/x86/mm/init_32.c:481) [ 0.065503][ T0] ? setup_arch (arch/x86/kernel/setup.c:1131) [ 0.065819][ T0] ? start_kernel (include/linux/jump_label.h:267 init/main.c:920) [ 0.066143][ T0] ? i386_start_kernel (arch/x86/kernel/head32.c:79) [ 0.066501][ T0] ? startup_32_smp (arch/x86/kernel/head_32.S:292) The crash happens because commit e120d1bc12da ("arch, mm: set high_memory in free_area_init()") moved initialization of high_memory after __vmalloc_start_set and with high_memory still set to 0 any address passes is_vmalloc_addr() check. Restore early initialization of high_memory on 32-bit systems in initmem_init(). Link: https://lkml.kernel.org/r/20250319122337.1538924-1-rppt@kernel.org Fixes: e120d1bc12da ("arch, mm: set high_memory in free_area_init()") Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202503191442.112e954f-lkp@intel.com Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Betkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleinxer <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21mm/vmscan: don't try to reclaim hwpoison folioJinjiang Tu
Syzkaller reports a bug as follows: Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20 I can reproduce this issue with the following steps: 1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru. 2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever. 3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared. To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list. Link: https://lkml.kernel.org/r/20250318083939.987651-3-tujinjiang@huawei.com Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: David Hildenbrand <david@redhat.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Nanyong Sun <sunnanyong@huawei.com> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: <stable@vger,kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21mm/hwpoison: introduce folio_contain_hwpoisoned_page() helperJinjiang Tu
Patch series "mm/vmscan: don't try to reclaim hwpoison folio". Fix a bug during memory reclaim if folio is hwpoisoned. This patch (of 2): Introduce helper folio_contain_hwpoisoned_page() to check if the entire folio is hwpoisoned or it contains hwpoisoned pages. Link: https://lkml.kernel.org/r/20250318083939.987651-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20250318083939.987651-2-tujinjiang@huawei.com Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com> Acked-by: Miaohe Lin <linmiaohe@huawei.com> Cc: David Hildenbrand <david@redhat.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Nanyong Sun <sunnanyong@huawei.com> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: <stable@vger,kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21cgroup: docs: add pswpin and pswpout items in cgroup v2 docHao Jia
The commit 15ff4d409e1a ("mm/memcontrol: add per-memcg pgpgin/pswpin counter") introduced the pswpin and pswpout items in the memory.stat of cgroup v2. Therefore, update them accordingly in the cgroup-v2 documentation. Link: https://lkml.kernel.org/r/20250318075833.90615-3-jiahao.kernel@gmail.com Fixes: 15ff4d409e1a ("mm/memcontrol: add per-memcg pgpgin/pswpin counter") Signed-off-by: Hao Jia <jiahao1@lixiang.com> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: Michal Koutný <mkoutny@suse.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21mm: vmscan: split proactive reclaim statistics from direct reclaim statisticsHao Jia
Patch series "Adding Proactive Memory Reclaim Statistics". These two patches are related to proactive memory reclaim. Patch 1 Split proactive reclaim statistics from direct reclaim counters and introduces new counters: pgsteal_proactive, pgdemote_proactive, and pgscan_proactive. Patch 2 Adds pswpin and pswpout items to the cgroup-v2 documentation. This patch (of 2): In proactive memory reclaim scenarios, it is necessary to accurately track proactive reclaim statistics to dynamically adjust the frequency and amount of memory being reclaimed proactively. Currently, proactive reclaim is included in direct reclaim statistics, which can make these direct reclaim statistics misleading. Therefore, separate proactive reclaim memory from the direct reclaim counters by introducing new counters: pgsteal_proactive, pgdemote_proactive, and pgscan_proactive, to avoid confusion with direct reclaim. Link: https://lkml.kernel.org/r/20250318075833.90615-1-jiahao.kernel@gmail.com Link: https://lkml.kernel.org/r/20250318075833.90615-2-jiahao.kernel@gmail.com Signed-off-by: Hao Jia <jiahao1@lixiang.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: Michal Koutný <mkoutny@suse.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21selftests/mm: speed up split_huge_page_testRyan Roberts
create_pagecache_thp_and_fd() was previously writing a file sized at twice the PMD size by making a per-byte write syscall. This was quite slow when the PMD size is 4M, but completely intolerable for 32M (PMD size for arm64's 16K page size), and 512M (PMD size for arm64's 64K page size). The byte pattern has a 256 byte period, so let's create a 1K buffer and fill it with exactly 4 periods. Then we can write the buffer as many times as is required to fill the file. This makes things much more tolerable. The test now passes for 16K page size. It still fails for 64K page size because MAX_PAGECACHE_ORDER is too small for 512M folio size (I think). Link: https://lkml.kernel.org/r/20250318174343.243631-3-ryan.roberts@arm.com Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Acked-by: Peter Xu <peterx@redhat.com> Acked-by: Rafael Aquini <raquini@redhat.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21selftests/mm: uffd-unit-tests support for hugepages > 2MRyan Roberts
uffd-unit-tests uses a memory area with a fixed 32M size. Then it calculates the number of pages by dividing by page_size, which itself is either the base page size or the PMD huge page size depending on the test config. For the latter, we end up with nr_pages=1 for arm64 16K base pages, and nr_pages=0 for 64K base pages. This doesn't end well. So let's make the 32M size a floor and also ensure that we have at least 2 pages given the PMD size. With this change, the tests pass on arm64 64K base page size configuration. Link: https://lkml.kernel.org/r/20250318174343.243631-2-ryan.roberts@arm.com Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Acked-by: Peter Xu <peterx@redhat.com> Acked-by: Rafael Aquini <raquini@redhat.com> Cc: Shuah Khan <shuah@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21docs/mm/damon/design: document active DAMOS filter typeNhat Pham
Document availability and meaning of "active" DAMOS filter type on design document. Since introduction of the type requires no additional user ABI, usage and ABI document need no update. Link: https://lkml.kernel.org/r/20250318183029.2062917-3-nphamcs@gmail.com Signed-off-by: Nhat Pham <nphamcs@gmail.com> Suggested-by: SeongJae Park <sj@kernel.org> Reviewed-by: SeongJae Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-03-21mm/damon: implement a new DAMOS filter type for active pagesNhat Pham
Patch series "mm/damon: introduce DAMOS filter type for active pages". The memory reclaim algorithm categorizes pages into active and inactive lists, separately for file and anon pages. The system's performance relies heavily on the (relative and absolute) accuracy of this categorization. This patch series add a new DAMOS filter for pages' activeness, giving us visibility into the access frequency of the pages on each list. This insight can help us diagnose issues with the active-inactive balancing dynamics, and make decisions to optimize reclaim efficiency and memory utilization. For instance, we might decide to enable DAMON_LRU_SORT, if we find that there are pages on the active list that are infrequently accessed, or less frequently accessed than pages on the inactive list. This patch (of 2): Implement a DAMOS filter type for active pages on DAMON kernel API, and add support of it from the physical address space DAMON operations set (paddr). Link: https://lkml.kernel.org/r/20250318183029.2062917-1-nphamcs@gmail.com Link: https://lkml.kernel.org/r/20250318183029.2062917-2-nphamcs@gmail.com Signed-off-by: Nhat Pham <nphamcs@gmail.com> Suggested-by: SeongJae Park <sj@kernel.org> Reviewed-by: SeongJae Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
generated by cgit (git 2.34.1) at 2025-09-15 04:48:33 +0000