* [PATCH bpf-next v2 2/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
From: Alexis Lothoré (eBPF Foundation) @ 2026-06-04 20:22 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Shuah Khan, Maxime Coquelin, Alexandre Torgue,
Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel,
Alexis Lothoré (eBPF Foundation)
In-Reply-To: <20260604-kasan-v2-0-c066e627fda8@bootlin.com>
Add a new Kconfig option CONFIG_BPF_JIT_KASAN that automatically enables
generic KASAN (Kernel Address SANitizer) memory access checks for
JIT-compiled BPF programs as well, when both KASAN_GENERIC and JIT
compiler are enabled. This new Kconfig is not a user selectable one: it
is either automatically enabled if KASAN is enabled on a compatible
platform, or disabled. When enabled, the JIT compiler will emit shadow
memory checks before memory loads and stores to detect use-after-free or
out-of-bounds accesses at runtime. The option is gated behind
HAVE_EBPF_JIT_KASAN, as it needs proper arch-specific implementation.
As KASAN instrumentation for eBPF program will depend on the info that
can be accessed during each instruction verification, there may be
instructions that will be instrumented even if they don't really need to
(eg: global subprograms that access caller stack memory passed as
argument). To make sure that those additional checks do not trigger any
crash, make sure that VMAP_STACK is enabled so that programs stack has
shadow memory allocated.
Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
Changes in v2:
- add dependency on kasan for vmalloc and vmalloc'ed stack
---
kernel/bpf/Kconfig | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
index eb3de35734f0..a8e004f88b92 100644
--- a/kernel/bpf/Kconfig
+++ b/kernel/bpf/Kconfig
@@ -17,6 +17,10 @@ config HAVE_CBPF_JIT
config HAVE_EBPF_JIT
bool
+# KASAN support for JIT compiler
+config HAVE_EBPF_JIT_KASAN
+ bool
+
# Used by archs to tell that they want the BPF JIT compiler enabled by
# default for kernels that were compiled with BPF JIT support.
config ARCH_WANT_DEFAULT_BPF_JIT
@@ -101,4 +105,9 @@ config BPF_LSM
If you are unsure how to answer this question, answer N.
+config BPF_JIT_KASAN
+ bool
+ depends on HAVE_EBPF_JIT_KASAN
+ default y if BPF_JIT && KASAN_GENERIC && KASAN_VMALLOC && VMAP_STACK
+
endmenu # "BPF subsystem"
--
2.54.0
^ permalink raw reply related
* [PATCH bpf-next v2 3/8] bpf, x86: add helper to emit kasan checks in x86 JITed programs
From: Alexis Lothoré (eBPF Foundation) @ 2026-06-04 20:22 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Shuah Khan, Maxime Coquelin, Alexandre Torgue,
Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel,
Alexis Lothoré (eBPF Foundation)
In-Reply-To: <20260604-kasan-v2-0-c066e627fda8@bootlin.com>
Add the emit_kasan_check() function that emits KASAN shadow memory
checks before memory accesses in JIT-compiled BPF programs. The
implementation relies on the existing __asan_{load,store}X functions
from KASAN subsystem. The helper:
- ensures that the kasan instrumention is actually needed: if the
instruction being processed accesses the program stack, we skip the
instrumentation, as those accesses are already protected with page
guards
- saves registers. This includes caller-saved registers, but also
temporary registers, as those were possibly used by the
affected program
- computes the accessed address and stores it in %rdi
- calls the relevant function, depending on the instruction being a load
or a store, and the size of the access.
- restores registers
The special care needed when inserting this instrumentation comes at the
cost of a non negligeable increase in JITed code size. For example, a
bare
mov 0x0(%si),rbx # Load in rbx content at address stored in rsi
becomes
push %rax
push %rcx
push %rdx
push %rsi
push %rdi
push %r8
push %r9
mov %rsi,%rdi
call 0xffffffff81da0a60 <__asan_load8>
pop %r9
pop %r8
pop %rdi
pop %rsi
pop %rdx
pop %rcx
pop %rax
mov 0x0(%rsi),rbx
Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
Changes in v2:
- move asan functions declaration directly into jit compiler, and guard
them with IS_ENABLED
- remove faulty stack alignment, no arg is passed to kasan funcs on the
stack anyway
- make sure to emit call depth accounting code
- do not save unneeded registers
- update helper signature to let caller configure some values (eg:
is_write)
Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
arch/x86/net/bpf_jit_comp.c | 93 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 93 insertions(+)
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index a0c541a441cf..0981791014eb 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -21,6 +21,19 @@
#include <asm/unwind.h>
#include <asm/cfi.h>
+#if IS_ENABLED(CONFIG_BPF_JIT_KASAN)
+void __asan_load1(void *p);
+void __asan_store1(void *p);
+void __asan_load2(void *p);
+void __asan_store2(void *p);
+void __asan_load4(void *p);
+void __asan_store4(void *p);
+void __asan_load8(void *p);
+void __asan_store8(void *p);
+void __asan_load16(void *p);
+void __asan_store16(void *p);
+#endif
+
static bool all_callee_regs_used[4] = {true, true, true, true};
static u8 *emit_code(u8 *ptr, u32 bytes, unsigned int len)
@@ -1330,6 +1343,86 @@ static void emit_store_stack_imm64(u8 **pprog, int reg, int stack_off, u64 imm64
emit_stx(pprog, BPF_DW, BPF_REG_FP, reg, stack_off);
}
+static int emit_kasan_check(u8 **pprog, u32 addr_reg, struct bpf_insn *insn,
+ u8 *ip, bool is_write, bool accesses_stack_only)
+{
+#ifdef CONFIG_BPF_JIT_KASAN
+ u32 bpf_size = BPF_SIZE(insn->code);
+ s32 off = insn->off;
+ u8 *prog = *pprog;
+ void *kasan_func;
+
+ if (accesses_stack_only)
+ return 0;
+
+ /* Derive KASAN check function from access type and size */
+ switch (bpf_size) {
+ case BPF_B:
+ kasan_func = is_write ? __asan_store1 : __asan_load1;
+ break;
+ case BPF_H:
+ kasan_func = is_write ? __asan_store2 : __asan_load2;
+ break;
+ case BPF_W:
+ kasan_func = is_write ? __asan_store4 : __asan_load4;
+ break;
+ case BPF_DW:
+ kasan_func = is_write ? __asan_store8 : __asan_load8;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* Save rax */
+ EMIT1(0x50);
+ /* Save rcx */
+ EMIT1(0x51);
+ /* Save rdx */
+ EMIT1(0x52);
+ /* Save rsi */
+ EMIT1(0x56);
+ /* Save rdi */
+ EMIT1(0x57);
+ /* Save r8 */
+ EMIT2(0x41, 0x50);
+ /* Save r9 */
+ EMIT2(0x41, 0x51);
+
+ /* mov rdi, addr_reg */
+ EMIT_mov(BPF_REG_1, addr_reg);
+
+ /* add rdi, off (if offset is non-zero) */
+ if (off) {
+ if (is_imm8(off)) {
+ /* add rdi, imm8 */
+ EMIT4(0x48, 0x83, 0xC7, (u8)off);
+ } else {
+ /* add rdi, imm32 */
+ EMIT3_off32(0x48, 0x81, 0xC7, off);
+ }
+ }
+
+ /* Adjust ip to account for the instrumentation generated so far */
+ ip += (prog - *pprog);
+ /* We emit a call, so update call depth counting */
+ ip += x86_call_depth_emit_accounting(&prog, kasan_func, ip);
+ /* call kasan_func */
+ if (emit_call(&prog, kasan_func, ip))
+ return -ERANGE;
+
+ EMIT2(0x41, 0x59);
+ EMIT2(0x41, 0x58);
+ EMIT1(0x5F);
+ EMIT1(0x5E);
+ EMIT1(0x5A);
+ EMIT1(0x59);
+ EMIT1(0x58);
+
+ *pprog = prog;
+#endif /* CONFIG_BPF_JIT_KASAN */
+ return 0;
+}
+
static int emit_atomic_rmw(u8 **pprog, u32 atomic_op,
u32 dst_reg, u32 src_reg, s16 off, u8 bpf_size)
{
--
2.54.0
^ permalink raw reply related
* [PATCH bpf-next v2 0/8] bpf: add support for KASAN checks in JITed programs
From: Alexis Lothoré (eBPF Foundation) @ 2026-06-04 20:21 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Shuah Khan, Maxime Coquelin, Alexandre Torgue,
Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel,
Alexis Lothoré (eBPF Foundation)
Hello,
this series aims to bring basic support for KASAN checks to BPF JITed
programs. This v2 drops the RFC prefix and brings many updates regarding
the topics and issues mentioned on the RFC or at LSFMMBPF. Thanks to
Ihor's update on CI, the instrumentation can now trigger properly in CI
as well.
"Traditional" KASAN allows to spot memory management mistakes by
reserving a fraction of memory as "shadow memory" that will map to the
rest of the memory and allow its monitoring. Each memory-accessing
instruction is then instrumented at build time to call some ASAN check
function, that will analyze the corresponding bits in shadow memory, and
if it detects the access as invalid, trigger a detailed report. The goal
of this series is to replicate this mechanism for BPF programs when they
are being JITed into native instructions: that's then the JIT compiler
that is in charge of inserting calls to the corresponding kasan checks,
when a program is being loaded into the kernel. This task involves:
- identifying at program load time the instructions performing memory
accesses
- identifying those accesses properties (size ? read or write ?) to
define the relevant kasan check function to call
- just before the identified instructions:
- perform the basic context saving (ie: saving registers)
- inserting a call to the relevant kasan check function
- restore context
- whenever the instrumented program executes, if it performs an invalid
access, it triggers a kasan report identical to those instrumented on
kernel side at build time.
As discussed in [1], this series is based on some choices and
assumptions:
- it focuses on x86_64 for now, and so only on KASAN_GENERIC
- not all memory accessing BPF instructions are being instrumented:
- it discards instructions accessing BPF program stack (already
monitored by page guards)
- it discards possibly faulting instructions, like BPF_PROBE_MEM or
BPF_PROBE_ATOMIC insns
---
Changes in v2:
- declare asan functions as extern in JIT compiler rather than exposing
them in kasan header
- invert stack-accessing instructions marking to make sure not to skip
instructions that could end up accessing to-be-checked memory
- fix stack accesses marking when verifier patches instructions
- add best effort marking for cBPF
- add missing call depth accounting in jited instrumentation
- skip unused registers in kasan instrumentation save/restore
- remove faulty stack align in kasan instrumentation
- drop commit skipping some jit-related tests
- cover missing instructions: BPF_ST and atomics
- completely rework tests: directly tune shadow memory, increase
coverage, do not consume kernel logs
- Link to v1: https://patch.msgid.link/20260413-kasan-v1-0-1a5831230821@bootlin.com
To: Alexei Starovoitov <ast@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andrii@kernel.org>
To: Martin KaFai Lau <martin.lau@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Song Liu <song@kernel.org>
To: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <jolsa@kernel.org>
To: John Fastabend <john.fastabend@gmail.com>
To: Thomas Gleixner <tglx@kernel.org>
To: Ingo Molnar <mingo@redhat.com>
To: Borislav Petkov <bp@alien8.de>
To: Dave Hansen <dave.hansen@linux.intel.com>
To: x86@kernel.org
To: "H. Peter Anvin" <hpa@zytor.com>
To: Shuah Khan <shuah@kernel.org>
To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>
To: Ihor Solodrai <ihor.solodrai@linux.dev>
Cc: ebpf@linuxfoundation.org
Cc: Bastien Curutchet <bastien.curutchet@bootlin.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: bpf@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
---
Alexis Lothoré (eBPF Foundation) (8):
bpf: mark instructions accessing program stack
bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
bpf, x86: add helper to emit kasan checks in x86 JITed programs
bpf, x86: refactor BPF_ST management in do_jit
bpf, x86: emit KASAN checks into x86 JITed programs
bpf, x86: enable KASAN for JITed programs on x86
selftests/bpf: add helper to check whether eBPF KASAN is active
selftests/bpf: add tests to validate KASAN on JIT programs
arch/x86/Kconfig | 1 +
arch/x86/net/bpf_jit_comp.c | 209 +++++++++--
include/linux/bpf.h | 2 +
include/linux/bpf_verifier.h | 2 +
kernel/bpf/Kconfig | 9 +
kernel/bpf/core.c | 17 +
kernel/bpf/fixups.c | 16 +-
kernel/bpf/verifier.c | 9 +
tools/testing/selftests/bpf/prog_tests/kasan.c | 356 +++++++++++++++++++
tools/testing/selftests/bpf/progs/kasan.c | 382 +++++++++++++++++++++
.../testing/selftests/bpf/test_kmods/bpf_testmod.c | 22 ++
tools/testing/selftests/bpf/unpriv_helpers.c | 5 +
tools/testing/selftests/bpf/unpriv_helpers.h | 1 +
13 files changed, 994 insertions(+), 37 deletions(-)
---
base-commit: b1c85ee71e2ab9ed7a12d7f3ee38988509baa368
change-id: 20260126-kasan-fcd68f64cd7b
Best regards,
--
Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
^ permalink raw reply
* [PATCH bpf-next v2 1/8] bpf: mark instructions accessing program stack
From: Alexis Lothoré (eBPF Foundation) @ 2026-06-04 20:21 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Shuah Khan, Maxime Coquelin, Alexandre Torgue,
Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel,
Alexis Lothoré (eBPF Foundation)
In-Reply-To: <20260604-kasan-v2-0-c066e627fda8@bootlin.com>
In order to prepare to emit KASAN checks in JITed programs, JIT
compilers need to be aware about whether some load/store instructions
are targeting the bpf program stack, as those should not be monitored
(we already have guard pages for that, and it is difficult anyway to
correctly monitor any kind of data passed on stack).
To support this need, make the BPF verifier mark the instructions
depending on whether they could access or not memory other than stack:
- add a setter that allows the verifier to mark instructions accessing
non-stack memory
- add a getter that allows JIT compilers to check whether instructions
being JITed are accessing the stack _and only_ the stack. If no env is
provided (eg this is a cBPF program), do a best-effort check based on
source and destination registers.
As different states in the verifier could lead to different memory types
for the same access, just marking an instruction as accessing stack only
is not enough (it could be some other memory type in another verifier
state), so the algorithm rather sets by default any load/store
instruction as stack only, and if _any_ state leads to any memory access
type other than PTR_TO_STACK, it overrides this setting. It also takes
care about shifting back the instruction marking in adjust_insn_aux_data
if the verifier patches instructions.
Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
---
Changes in v2:
- invert marking logic to cover possible different reg types when the
verifier covers different states
- add a best-effort processing for classical bpf programs, inspecting
directly src and dst registers since we don't have verifier env
- make sure to keep marking in sync with prog when it is patched by
verifier
---
include/linux/bpf.h | 2 ++
include/linux/bpf_verifier.h | 2 ++
kernel/bpf/core.c | 17 +++++++++++++++++
kernel/bpf/fixups.c | 16 +++++++++++-----
kernel/bpf/verifier.c | 9 +++++++++
5 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 8599b451dd7a..ff80d1d62bff 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1560,6 +1560,8 @@ void bpf_jit_uncharge_modmem(u32 size);
bool bpf_prog_has_trampoline(const struct bpf_prog *prog);
bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struct bpf_prog *prog,
int insn_idx);
+bool bpf_insn_accesses_stack_only(const struct bpf_verifier_env *env,
+ const struct bpf_prog *prog, int insn_idx);
u16 bpf_out_stack_arg_cnt(const struct bpf_verifier_env *env, const struct bpf_prog *prog);
#else
static inline int bpf_trampoline_link_prog(struct bpf_tramp_link *link,
diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index c248ff41f42a..0f3f055d6c14 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -722,6 +722,8 @@ struct bpf_insn_aux_data {
u16 const_reg_map_mask;
u16 const_reg_subprog_mask;
u32 const_reg_vals[10];
+ /* instruction can access non-stack memory */
+ bool non_stack_access;
};
#define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index a656a8572bdb..393d9eacd215 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1583,6 +1583,22 @@ bool bpf_insn_is_indirect_target(const struct bpf_verifier_env *env, const struc
return env->insn_aux_data[insn_idx].indirect_target;
}
+bool bpf_insn_accesses_stack_only(const struct bpf_verifier_env *env,
+ const struct bpf_prog *prog, int insn_idx)
+{
+ struct bpf_insn *insn;
+
+ /* cBPF: we have no verifier state, do a best-effort check based on
+ * dst/src reg
+ */
+ insn_idx += prog->aux->subprog_start;
+ insn = (struct bpf_insn *)prog->insnsi + insn_idx;
+ if (!env)
+ return insn->dst_reg == BPF_REG_FP ||
+ insn->src_reg == BPF_REG_FP;
+ return !env->insn_aux_data[insn_idx].non_stack_access;
+}
+
u16 bpf_out_stack_arg_cnt(const struct bpf_verifier_env *env, const struct bpf_prog *prog)
{
const struct bpf_subprog_info *sub;
@@ -1592,6 +1608,7 @@ u16 bpf_out_stack_arg_cnt(const struct bpf_verifier_env *env, const struct bpf_p
sub = &env->subprog_info[prog->aux->func_idx];
return sub->stack_arg_cnt - bpf_in_stack_arg_cnt(sub);
}
+
#endif /* CONFIG_BPF_JIT */
/* Base function for offset calculation. Needs to go into .text section,
diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
index 5aa3f7d99ac9..5228c910fbf5 100644
--- a/kernel/bpf/fixups.c
+++ b/kernel/bpf/fixups.c
@@ -185,16 +185,22 @@ static void adjust_insn_aux_data(struct bpf_verifier_env *env,
}
/*
- * The indirect_target flag of the original instruction was moved to the last of the
- * new instructions by the above memmove and memset, but the indirect jump target is
- * actually the first instruction, so move it back. This also matches with the behavior
- * of bpf_insn_array_adjust(), which preserves xlated_off to point to the first new
- * instruction.
+ * The indirect_target and non_stack_access flags of the original
+ * instruction were moved to the last of the new instructions by the
+ * above memmove and memset, but those actually match the first
+ * instruction, so move them back. This also matches with the behavior
+ * of bpf_insn_array_adjust(), which preserves xlated_off to point to
+ * the first new instruction.
*/
if (data[off + cnt - 1].indirect_target) {
data[off].indirect_target = 1;
data[off + cnt - 1].indirect_target = 0;
}
+
+ if (data[off + cnt - 1].non_stack_access) {
+ data[off].non_stack_access = 1;
+ data[off + cnt - 1].non_stack_access = 0;
+ }
}
static void adjust_subprog_starts(struct bpf_verifier_env *env, u32 off, u32 len)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 8ed484cb1a8a..b3f0f430ad6a 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3143,6 +3143,11 @@ static void mark_indirect_target(struct bpf_verifier_env *env, int idx)
env->insn_aux_data[idx].indirect_target = true;
}
+static void mark_non_stack_access(struct bpf_verifier_env *env, int idx)
+{
+ env->insn_aux_data[idx].non_stack_access = true;
+}
+
#define LR_FRAMENO_BITS 3
#define LR_SPI_BITS 6
#define LR_ENTRY_BITS (LR_SPI_BITS + LR_FRAMENO_BITS + 1)
@@ -6300,6 +6305,10 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, struct b
else
coerce_reg_to_size_sx(®s[value_regno], size);
}
+
+ if (!err && reg->type != PTR_TO_STACK)
+ mark_non_stack_access(env, insn_idx);
+
return err;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v4 2/2] kconfig: Remove the architecture specific config for Propeller
From: xur @ 2026-06-04 19:56 UTC (permalink / raw)
To: Yabin Cui, Will Deacon, Han Shen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kees Cook,
Nathan Chancellor, Nicolas Schier, Linus Walleij, Arnd Bergmann,
Mathieu Desnoyers, Rong Xu, Miguel Ojeda, Peter Zijlstra,
Jinjie Ruan, Lukas Bulwahn, linux-kernel, Juergen Gross,
Helge Deller, Ryan Roberts, Marc Zyngier, Ard Biesheuvel,
Vincent Donnefort, Alice Ryhl
Cc: x86, linux-arm-kernel
In-Reply-To: <20260604195612.3757860-1-xur@google.com>
From: Rong Xu <xur@google.com>
The CONFIG_PROPELLER_CLANG option currently depends on
ARCH_SUPPORTS_PROPELLER_CLANG, but this dependency seems unnecessary.
Remove ARCH_SUPPORTS_PROPELLER_CLANG and allow users to control
Propeller builds solely through CONFIG_PROPELLER_CLANG. This simplifies
the kconfig and avoids potential confusion.
Move the .llvm_bb_addr_map sections grouping to
include/asm-generic/vmlinux.lds.h.
The Propeller documentation has been updated to reflect the most
recent tool location and now includes instructions for arm64.
Contributor Acknowledgments:
* SPE instructions: Daniel Hoekwater <hoekwater@google.com>
Signed-off-by: Rong Xu <xur@google.com>
Suggested-by: Will Deacon <will@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Yabin Cui <yabinc@google.com>
Reviewed-by: Kees Cook <kees@kernel.org>
---
Documentation/dev-tools/propeller.rst | 49 ++++++++++++++++++++-------
arch/Kconfig | 5 +--
arch/arm64/kernel/vmlinux.lds.S | 1 +
arch/x86/Kconfig | 1 -
arch/x86/kernel/vmlinux.lds.S | 5 +--
include/asm-generic/vmlinux.lds.h | 6 ++++
6 files changed, 46 insertions(+), 21 deletions(-)
diff --git a/Documentation/dev-tools/propeller.rst b/Documentation/dev-tools/propeller.rst
index 92195958e3db..e927319941c9 100644
--- a/Documentation/dev-tools/propeller.rst
+++ b/Documentation/dev-tools/propeller.rst
@@ -28,8 +28,10 @@ A few important notes about adopting Propeller optimization:
and the linker(ld.lld).
#. In addition to LLVM toolchain, Propeller requires a profiling
- conversion tool: https://github.com/google/autofdo with a release
- after v0.30.1: https://github.com/google/autofdo/releases/tag/v0.30.1.
+ conversion tool: https://github.com/google/llvm-propeller.
+
+Current supported architectures include x86/X86_64 (via LBR),
+and arm64 (via SPE).
The Propeller optimization process involves the following steps:
@@ -124,17 +126,30 @@ Here is an example workflow for building an AutoFDO+Propeller kernel:
$ perf record --pfm-event RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
- Note you can repeat the above steps to collect multiple <perf_file>s.
+ - For arm64 with SPE::
+ There are a few kernel features that must be enabled to collect SPE profiles on Arm.
+ Below is a list of the required features:
+
+ - CONFIG_ARM_SPE_PMU=y
+ - CONFIG_PID_IN_CONTEXTIDR=y
+ - kpti=off
+
+ Use the following command to generate SPE perf data file::
+
+ $ perf record -e 'arm_spe_0/branch_filter=1,load_filter=0,store_filter=0/' -a -N -c <count> --no-switch-events -o <perf_file> -- <loadtest>
+
+ Note you can repeat the above steps to collect multiple <perf_file>s.
4) (Optional) Download the raw perf file(s) to the host machine.
-5) Use the create_llvm_prof tool (https://github.com/google/autofdo) to
+5) Use the generate_propeller_profiles tool (https://github.com/google/llvm-propeller) to
generate Propeller profile. ::
- $ create_llvm_prof --binary=<vmlinux> --profile=<perf_file>
- --format=propeller --propeller_output_module_name
- --out=<propeller_profile_prefix>_cc_profile.txt
- --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
+ $ generate_propeller_profiles \
+ --binary=<vmlinux> --profile=<perf_file> \
+ --format=propeller --propeller_output_module_name \
+ --out=<propeller_profile_prefix>_cc_profile.txt \
+ --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
"<propeller_profile_prefix>" can be something like "/home/user/dir/any_string".
@@ -146,10 +161,20 @@ Here is an example workflow for building an AutoFDO+Propeller kernel:
you can create a temp list file "<perf_file_list>" with each line
containing one perf file name and run::
- $ create_llvm_prof --binary=<vmlinux> --profile=@<perf_file_list>
- --format=propeller --propeller_output_module_name
- --out=<propeller_profile_prefix>_cc_profile.txt
- --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
+ $ generate_propeller_profiles \
+ --binary=<vmlinux> --profile=@<perf_file_list> \
+ --format=propeller --propeller_output_module_name \
+ --out=<propeller_profile_prefix>_cc_profile.txt \
+ --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
+
+ For arm64 SPE, add the option '--profiler=perf_spe', like::
+
+ $ generate_propeller_profiles \
+ --binary=<vmlinux> --profile=<perf_file> \
+ --profiler=perf_spe \
+ --format=propeller --propeller_output_module_name \
+ --out=<propeller_profile_prefix>_cc_profile.txt \
+ --propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
6) Rebuild the kernel using the AutoFDO and Propeller
profiles. ::
diff --git a/arch/Kconfig b/arch/Kconfig
index 5e878924939a..99c2017eb515 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -895,13 +895,10 @@ config AUTOFDO_CLANG
If unsure, say N.
-config ARCH_SUPPORTS_PROPELLER_CLANG
- bool
-
config PROPELLER_CLANG
bool "Enable Clang's Propeller build"
- depends on ARCH_SUPPORTS_PROPELLER_CLANG
depends on CC_IS_CLANG && CLANG_VERSION >= 190000
+ depends on $(cc-option,-fbasic-block-sections=list=/dev/null)
help
This option enables Clang’s Propeller build. When the Propeller
profiles is specified in variable CLANG_PROPELLER_PROFILE_PREFIX
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index e1ac876200a3..8aaf404980a7 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -368,6 +368,7 @@ SECTIONS
STABS_DEBUG
DWARF_DEBUG
+ PROPELLER_DATA
MODINFO
ELF_DETAILS
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 10bf3984102e..b875d2f27e48 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -130,7 +130,6 @@ config X86
select ARCH_SUPPORTS_LTO_CLANG
select ARCH_SUPPORTS_LTO_CLANG_THIN
select ARCH_SUPPORTS_RT
- select ARCH_SUPPORTS_PROPELLER_CLANG if X86_64
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF if X86_CX8
select ARCH_USE_MEMTEST
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 4711a35e706c..74e336d7f9dd 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -423,10 +423,7 @@ SECTIONS
STABS_DEBUG
DWARF_DEBUG
-#ifdef CONFIG_PROPELLER_CLANG
- .llvm_bb_addr_map : { *(.llvm_bb_addr_map) }
-#endif
-
+ PROPELLER_DATA
MODINFO
ELF_DETAILS
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 60c8c22fd3e4..5659f4b5a125 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -1011,6 +1011,12 @@
#define PERCPU_DECRYPTED_SECTION
#endif
+#ifdef CONFIG_PROPELLER_CLANG
+#define PROPELLER_DATA \
+ .llvm_bb_addr_map : { *(.llvm_bb_addr_map) }
+#else
+#define PROPELLER_DATA
+#endif
/*
* Default discarded sections.
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [PATCH v4 1/2] kconfig: Remove the architecture specific config for AutoFDO
From: xur @ 2026-06-04 19:56 UTC (permalink / raw)
To: Yabin Cui, Will Deacon, Han Shen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kees Cook,
Nathan Chancellor, Nicolas Schier, Linus Walleij, Arnd Bergmann,
Mathieu Desnoyers, Rong Xu, Miguel Ojeda, Peter Zijlstra,
Jinjie Ruan, Lukas Bulwahn, linux-kernel, Juergen Gross,
Helge Deller, Ryan Roberts, Marc Zyngier, Ard Biesheuvel,
Vincent Donnefort, Alice Ryhl
Cc: x86, linux-arm-kernel
In-Reply-To: <20260604195612.3757860-1-xur@google.com>
From: Rong Xu <xur@google.com>
The CONFIG_AUTOFDO_CLANG option currently depends on
ARCH_SUPPORTS_AUTOFDO_CLANG, but this dependency seems unnecessary.
Remove ARCH_SUPPORTS_AUTOFDO_CLANG and allow users to control AutoFDO
builds solely through CONFIG_AUTOFDO_CLANG. This simplifies the kconfig
and avoids potential confusion.
Expand the AutoFDO documentation to include instructions for arm64.
Contributor acknowledgments:
* SPE instructions: Daniel Hoekwater <hoekwater@google.com>
* ETM instructions: Yabin Cui <yabinc@google.com>
Signed-off-by: Rong Xu <xur@google.com>
Suggested-by: Will Deacon <will@kernel.org>
Tested-by: Yabin Cui <yabinc@google.com>
Reviewed-by: Kees Cook <kees@kernel.org>
---
Documentation/dev-tools/autofdo.rst | 41 +++++++++++++++++++++++++++++
arch/Kconfig | 4 ---
arch/x86/Kconfig | 1 -
3 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/Documentation/dev-tools/autofdo.rst b/Documentation/dev-tools/autofdo.rst
index bcf06e7d6ffa..ae03c4dfedc1 100644
--- a/Documentation/dev-tools/autofdo.rst
+++ b/Documentation/dev-tools/autofdo.rst
@@ -61,6 +61,9 @@ process consists of the following steps:
the AutoFDO profile via offline tools.
The support requires a Clang compiler LLVM 17 or later.
+Current supported architectures include x86/x86_64 (via LBR) and
+arm64 (via SPE or ETM).
+
Preparation
===========
@@ -141,6 +144,35 @@ Here is an example workflow for AutoFDO kernel:
$ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a -N -b -c <count> -o <perf_file> -- <loadtest>
+ - For arm64 with SPE:
+
+ There are a few kernel features that must be enabled to collect SPE profiles on Arm.
+ Below is a list of the required features:
+
+ - CONFIG_ARM_SPE_PMU=y
+ - CONFIG_PID_IN_CONTEXTIDR=y
+ - kpti=off
+
+ Use the following command to generate SPE perf data file::
+
+ $ perf record -e ' arm_spe_0/branch_filter=1,load_filter=0,store_filter=0/' -a -c <count> -N --no-switch-events -o <perf_file> -- <loadtest>
+
+ - For arm64 with ETM trace:
+
+ Follow the instructions in `Linaro OpenCSD document
+ <https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/auto-fdo/autofdo.md>`_
+ to record ETM traces for AutoFDO::
+
+ $ perf record -e cs_etm/@tmc_etr0/k -a -o <etm_perf_file> -- <loadtest>
+ $ perf inject -i <etm_perf_file> -o <perf_file> --itrace=i500009il
+
+ For ARM platforms running Android, follow the instructions in `Android simpleperf
+ document <https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/gki/aarch64/afdo>`_
+ to record ETM traces for AutoFDO::
+
+ $ simpleperf record -e cs-etm:k -a -o <etm_perf_file> -- <loadtest>
+ $ simpleperf inject -i <etm_perf_file> -o <text_perf_file> --symdir <vmlinux_dir>
+
4) (Optional) Download the raw perf file to the host machine.
5) To generate an AutoFDO profile, two offline tools are available:
@@ -162,6 +194,15 @@ Here is an example workflow for AutoFDO kernel:
$ llvm-profdata merge -o <profile_file> <profile_1> <profile_2> ... <profile_n>
+ For arm64 SPE, use the following command::
+
+ $ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> --profiler=perf_spe --format=extbinary --out=<profile_file>
+
+ For arm64 ETM, use the following command::
+
+ $ create_llvm_prof --binary=<vmlinux> --profile=<text_perf_file> --profiler=text -format=extbinary -out=<profile_file>
+
+
6) Rebuild the kernel using the AutoFDO profile file with the same config as step 1,
(Note CONFIG_AUTOFDO_CLANG needs to be enabled)::
diff --git a/arch/Kconfig b/arch/Kconfig
index 0848932d1c8e..5e878924939a 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -879,12 +879,8 @@ config LTO_CLANG_THIN_DIST
module-specific compiler options, and simplifies debugging.
endchoice
-config ARCH_SUPPORTS_AUTOFDO_CLANG
- bool
-
config AUTOFDO_CLANG
bool "Enable Clang's AutoFDO build (EXPERIMENTAL)"
- depends on ARCH_SUPPORTS_AUTOFDO_CLANG
depends on CC_IS_CLANG
help
This option enables Clang’s AutoFDO build. When
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f3f7cb01d69d..10bf3984102e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -130,7 +130,6 @@ config X86
select ARCH_SUPPORTS_LTO_CLANG
select ARCH_SUPPORTS_LTO_CLANG_THIN
select ARCH_SUPPORTS_RT
- select ARCH_SUPPORTS_AUTOFDO_CLANG
select ARCH_SUPPORTS_PROPELLER_CLANG if X86_64
select ARCH_USE_BUILTIN_BSWAP
select ARCH_USE_CMPXCHG_LOCKREF if X86_CX8
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply related
* [PATCH v4 0/2] kconfig: Remove the architecture specific config for AutoFDO and Propeller
From: xur @ 2026-06-04 19:56 UTC (permalink / raw)
To: Yabin Cui, Will Deacon, Han Shen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Kees Cook,
Nathan Chancellor, Nicolas Schier, Linus Walleij, Arnd Bergmann,
Mathieu Desnoyers, Rong Xu, Miguel Ojeda, Peter Zijlstra,
Jinjie Ruan, Lukas Bulwahn, linux-kernel, Juergen Gross,
Helge Deller, Ryan Roberts, Marc Zyngier, Ard Biesheuvel,
Vincent Donnefort, Alice Ryhl
Cc: x86, linux-arm-kernel
From: Rong Xu <xur@google.com>
ChangeLog:
V4: (1) updated docs for AutoFDO and Propeller
(2) moved .llvm_bb_addr_map sections grouping to the header file.
(3) use $(cc-option,...) for supported archs.
V3: (1) updated the base;
(2) changed vmlinux.lds.S for arm64 to avoid the warnings
from .llvm_bb_addr_map.
Rong Xu (2):
kconfig: Remove the architecture specific config for AutoFDO
kconfig: Remove the architecture specific config for Propeller
Documentation/dev-tools/autofdo.rst | 41 ++++++++++++++++++++++
Documentation/dev-tools/propeller.rst | 49 ++++++++++++++++++++-------
arch/Kconfig | 9 +----
arch/arm64/kernel/vmlinux.lds.S | 1 +
arch/x86/Kconfig | 2 --
arch/x86/kernel/vmlinux.lds.S | 5 +--
include/asm-generic/vmlinux.lds.h | 6 ++++
7 files changed, 87 insertions(+), 26 deletions(-)
base-commit: f58316a441b4626324993db585fa4b7b7c780fac
--
2.54.0.1032.g2f8565e1d1-goog
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: imx6: Assert ref_clk_en after reference clock stabilizes on i.MX95
From: Frank Li @ 2026-06-04 19:34 UTC (permalink / raw)
To: Richard Zhu
Cc: l.stach, lpieralisi, kwilczynski, mani, robh, bhelgaas, s.hauer,
kernel, festevam, linux-pci, linux-arm-kernel, imx, linux-kernel,
stable
In-Reply-To: <20260518072715.3166514-3-hongxing.zhu@nxp.com>
On Mon, May 18, 2026 at 03:27:15PM +0800, Richard Zhu wrote:
> According to the PHY Databook Common Block Signals section, the
> ref_clk_en signal must remain de-asserted until the reference clock is
> running at the appropriate frequency. Once the clock is stable,
> ref_clk_en can be asserted. For lower power states where the reference
> clock to the PHY is disabled, ref_clk_en should also be de-asserted.
>
> Move the ref_clk_en bit manipulation into imx95_pcie_enable_ref_clk()
> to ensure the reference clock stabilizes before ref_clk_en is asserted
> and before the PHY reset is de-asserted. This aligns with the timing
> requirements specified in the PHY documentation.
>
> Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/pci/controller/dwc/pci-imx6.c | 28 +++++++++++++++++++++------
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 66e760015c92..c4b079c93648 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -270,8 +270,6 @@ static int imx95_pcie_init_pre_reset(struct imx_pcie *imx_pcie)
>
> static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
> {
> - bool ext = imx_pcie->enable_ext_refclk;
> -
> /*
> * ERR051624: The Controller Without Vaux Cannot Exit L23 Ready
> * Through Beacon or PERST# De-assertion
> @@ -290,10 +288,6 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
> IMX95_PCIE_PHY_CR_PARA_SEL,
> IMX95_PCIE_PHY_CR_PARA_SEL);
>
> - regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
> - IMX95_PCIE_REF_CLKEN,
> - ext ? 0 : IMX95_PCIE_REF_CLKEN);
> -
> return 0;
> }
>
> @@ -742,7 +736,29 @@ static void imx95_pcie_clkreq_override(struct imx_pcie *imx_pcie, bool enable)
>
> static int imx95_pcie_enable_ref_clk(struct imx_pcie *imx_pcie, bool enable)
> {
> + bool ext = imx_pcie->enable_ext_refclk;
> +
> imx95_pcie_clkreq_override(imx_pcie, enable);
> + /*
> + * The ref_clk_en signal must remain de-asserted until the
> + * reference clock is running at appropriate frequency, at which
> + * point this bit can be asserted. For lower power states where
> + * the reference clock to the PHY is disabled, it may also be
> + * de-asserted.
> + * +------------------- -+--------+----------------+
> + * | External clock mode | Enable | PCIE_REF_CLKEN |
> + * +---------------------+--------+----------------+
> + * | TRUE | X | 1b'0 |
> + * +---------------------+--------+----------------+
> + * | FALSE | TRUE | 1b'1 |
> + * +---------------------+--------+----------------+
> + * | FALSE | FALSE | 1b'0 |
> + * +---------------------+--------+----------------+
> + */
> + regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
> + IMX95_PCIE_REF_CLKEN,
> + ext || !enable ? 0 : IMX95_PCIE_REF_CLKEN);
> +
> return 0;
> }
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH v7 2/2] mm: use mapping_max_folio_order() for force_thp_readahead order
From: Pedro Falcato @ 2026-06-04 19:33 UTC (permalink / raw)
To: Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack,
Andrew Donnellan, apopple, baohua, baolin.wang, brauner,
catalin.marinas, dev.jain, kees, kevin.brodsky, lance.yang,
Liam R. Howlett, linux-arm-kernel, linux-fsdevel, linux-kernel,
ljs, mhocko, npache, pasha.tatashin, rmclure, rppt, surenb,
vbabka, Al Viro, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <20260601102205.3985788-3-usama.arif@linux.dev>
On Mon, Jun 01, 2026 at 03:21:18AM -0700, Usama Arif wrote:
> The force_thp_readahead path in do_sync_mmap_readahead() is gated on
> HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always requests
> HPAGE_PMD_ORDER / HPAGE_PMD_NR. On configurations where HPAGE_PMD_ORDER
> exceeds MAX_PAGECACHE_ORDER, notably arm64 with a 64K base page size,
> VM_HUGEPAGE mappings cannot use this path and fall back to the non-forced
> mmap readahead path even when the mapping supports useful large folios.
>
> Enable forced readahead for mappings that support large folios and request
> the max folio order supported by the mapping, capped at 2M.
> 2MB is chosen as the cap because it matches the PMD size on x86_64
> and on arm64 with 4K base pages, so the size/memory-pressure tradeoff
> for folios of that size is already well understood. On arm64 with 16K
> and 64K base page sizes, 2MB is also the contiguous-PTE (contpte)
> block size, so the resulting folios coalesce into a single TLB entry
> and reduce TLB pressure on the readahead path. This will result
> in 32M folios not being faulted in with 16K base page size for arm64,
> but with contpte, the performance difference should be negligible.
>
> The final allocation order may still be clamped by page_cache_ra_order()
> to the mapping and request geometry, but this gives VM_HUGEPAGE mappings
> on such configurations a large-folio readahead request instead of
> dropping back to base-page readahead.
>
> Signed-off-by: Usama Arif <usama.arif@linux.dev>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Overall LGTM. Lets see if performance doesn't degrade.
/me hides in cover
--
Pedro
^ permalink raw reply
* Re: [PATCH v7 1/2] mm: bypass mmap_miss heuristic for VM_EXEC readahead
From: Pedro Falcato @ 2026-06-04 19:30 UTC (permalink / raw)
To: Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack,
Andrew Donnellan, apopple, baohua, baolin.wang, brauner,
catalin.marinas, dev.jain, kees, kevin.brodsky, lance.yang,
Liam R. Howlett, linux-arm-kernel, linux-fsdevel, linux-kernel,
ljs, mhocko, npache, pasha.tatashin, rmclure, rppt, surenb,
vbabka, Al Viro, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <20260601102205.3985788-2-usama.arif@linux.dev>
On Mon, Jun 01, 2026 at 03:21:17AM -0700, Usama Arif wrote:
> The mmap_miss heuristic is intended to stop speculative mmap readahead
> when a file looks like a random-access workload. That does not fit the
> VM_EXEC path very well.
>
> VM_EXEC readahead is already constrained differently from ordinary mmap
> read-around: it is bounded by the VMA, uses exec_folio_order() to choose
> an order useful for executable mappings, and sets async_size to 0 so it
> does not create follow-on readahead. When VM_HUGEPAGE is also present,
> the larger readahead is an explicit userspace opt-in.
>
> The mmap_miss counter is decremented from cache-hit paths in
> do_async_mmap_readahead() and filemap_map_pages(). Those paths are not
> always enough to balance the synchronous miss increments for executable
> mappings. In particular, when fault-around is effectively disabled, such
> as configurations where fault_around_pages is 1, filemap_map_pages() is
> not reached from the fault path. The counter can then become a stale
> throttle for VM_EXEC mappings and suppress the readahead behavior that
> the executable-specific path is trying to provide.
>
> Skip both mmap_miss increments and decrements for VM_EXEC mappings,
> matching the existing VM_SEQ_READ treatment and keeping the counter
> accounting symmetric.
>
> Signed-off-by: Usama Arif <usama.arif@linux.dev>
> Reviewed-by: Jan Kara <jack@suse.cz>
> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
> ---
> mm/filemap.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index cca20e350c95..a16b33e0fc71 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -3339,7 +3339,7 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
> }
> }
>
> - if (!(vm_flags & VM_SEQ_READ)) {
> + if (!(vm_flags & (VM_SEQ_READ | VM_EXEC))) {
Just a side comment: I really hate these adhoc criteria all around
filemap/readahead. One day we ought to actually write things down, and
write things in a way that isn't entirely mysterious. I might see if I send
a patch for this down the line...
> /* Avoid banging the cache line if not needed */
> mmap_miss = READ_ONCE(ra->mmap_miss);
> if (mmap_miss < MMAP_LOTSAMISS * 10)
> @@ -3434,12 +3434,12 @@ static struct file *do_async_mmap_readahead(struct vm_fault *vmf,
> * times for a single folio and break the balance with mmap_miss
> * increase in do_sync_mmap_readahead().
> *
> - * VM_SEQ_READ mappings skip the mmap_miss increment in
> + * VM_SEQ_READ and VM_EXEC mappings skip the mmap_miss increment in
> * do_sync_mmap_readahead(), so skip the decrement here as well to
> * keep the counter symmetric.
> */
> if (likely(!folio_test_locked(folio)) &&
> - !(vmf->vma->vm_flags & VM_SEQ_READ)) {
> + !(vmf->vma->vm_flags & (VM_SEQ_READ | VM_EXEC))) {
> mmap_miss = READ_ONCE(ra->mmap_miss);
> if (mmap_miss)
> WRITE_ONCE(ra->mmap_miss, --mmap_miss);
> @@ -3941,14 +3941,14 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf,
> * Don't decrease mmap_miss in this scenario to make sure
> * we can stop read-ahead.
> *
> - * VM_SEQ_READ mappings skip the mmap_miss increment in
> - * do_sync_mmap_readahead(), so skip the decrement here as
> - * well to keep the counter symmetric.
> + * VM_SEQ_READ and VM_EXEC mappings skip the mmap_miss
> + * increment in do_sync_mmap_readahead(), so skip the
> + * decrement here as well to keep the counter symmetric.
> */
> if ((map_ret & VM_FAULT_NOPAGE) &&
> !(vmf->flags & FAULT_FLAG_TRIED) &&
> !folio_test_workingset(folio) &&
> - !(vma->vm_flags & VM_SEQ_READ)) {
> + !(vma->vm_flags & (VM_SEQ_READ | VM_EXEC))) {
> unsigned short mmap_miss;
>
> mmap_miss = READ_ONCE(file->f_ra.mmap_miss);
> --
> 2.52.0
>
--
Pedro
^ permalink raw reply
* Re: [PATCH] net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
From: Andrew Lunn @ 2026-06-04 19:30 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, alexandre.torgue, rmk+kernel, maxime.chevallier,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Thu, Jun 04, 2026 at 01:30:37AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Read the L3FM and L4FM bits from the RX descriptor status word (RDES2)
> and increment the corresponding ethtool statistics counters. This allows
> users to observe L3/L4 filter hit rates via ethtool -S.
Are there any more bits which are missing?
dwmac4 has RDES2_L3_L4_FILT_NB_MATCH_MASK for example.
Andrew
^ permalink raw reply
* Re: [PATCH] net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
From: Jacob Keller @ 2026-06-04 19:05 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade, netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On 6/4/2026 1:30 AM, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Read the L3FM and L4FM bits from the RX descriptor status word (RDES2)
> and increment the corresponding ethtool statistics counters. This allows
> users to observe L3/L4 filter hit rates via ethtool -S.
>
> Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 ++
> drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c | 6 ++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> index 51943705a2b0..95fdf3133208 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> @@ -429,6 +429,8 @@
> #define XGMAC_TDES3_VLTV BIT(16)
> #define XGMAC_TDES3_VT GENMASK(15, 0)
> #define XGMAC_TDES3_FL GENMASK(14, 0)
> +#define XGMAC_RDES2_L4FM BIT(28)
> +#define XGMAC_RDES2_L3FM BIT(27)
> #define XGMAC_RDES2_HL GENMASK(9, 0)
> #define XGMAC_RDES3_OWN BIT(31)
> #define XGMAC_RDES3_CTXT BIT(30)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> index b5f200a87484..6719ac6e395b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> @@ -27,6 +27,7 @@ static int dwxgmac2_get_rx_status(struct stmmac_extra_stats *x,
> struct dma_desc *p)
> {
> u32 rdes3 = le32_to_cpu(p->des3);
> + u32 rdes2 = le32_to_cpu(p->des2);
>
> if (unlikely(rdes3 & XGMAC_RDES3_OWN))
> return dma_own;
> @@ -37,6 +38,11 @@ static int dwxgmac2_get_rx_status(struct stmmac_extra_stats *x,
> if (unlikely((rdes3 & XGMAC_RDES3_ES) && (rdes3 & XGMAC_RDES3_LD)))
> return discard_frame;
>
> + if (rdes2 & XGMAC_RDES2_L3FM)
> + x->l3_filter_match++;
> + if (rdes2 & XGMAC_RDES2_L4FM)
> + x->l4_filter_match++;
> +
> return good_frame;
> }
>
Right. The l3_filter_match and l4_filter_match already get reported in
stmmac_ethtool.c
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
^ permalink raw reply
* Re: [PATCH v3] i2c: imx-lpi2c: reset controller in probe stage
From: Frank Li @ 2026-06-04 18:58 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: aisheng.dong, andi.shyti, s.hauer, kernel, festevam, linux-i2c,
imx, linux-arm-kernel, linux-kernel, Carlos Song
In-Reply-To: <20260521103530.2988866-1-carlos.song@oss.nxp.com>
On Thu, May 21, 2026 at 06:35:30PM +0800, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> Reset I2C controller in probe stage to avoid unexpected LPI2C controller
> state left from previous stages and hang system boot.
>
> Per the LPI2C reference manual, section 7.1.4 "Controller Control (MCR)"
> and 7.1.20 Target Control (SCR), the RST bit (bit 1) description states:
>
> "The reset takes effect immediately and remains asserted until negated
> by software. There is no minimum delay required before clearing the
> software reset."
>
> Therefore, it is safe to write 0 to MCR and SCR immediately after
> asserting the RST bit without any additional delay.
>
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
> Change for v3:
> - Reset the Target logic via LPI2C_SCR.
> - Replacing pm_runtime_put_sync() with pm_runtime_disable() +
> pm_runtime_set_suspended() + pm_runtime_put_noidle() to avoid
> triggering the suspend callback, and explicitly calling
> clk_bulk_disable_unprepare() for clock cleanup.
> - Add new error path free_irq and clk_disable to cover more
> complete error recovery.
> - Remake commit log adding SCR RST section.
> Change for v2:
> - Jump to rpm_disable instread of returning directly if the IRQ request
> fails
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 52 +++++++++++++++++++++---------
> 1 file changed, 37 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index e6c24a9d934d..4929f85ab485 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -1510,11 +1510,6 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> if (ret)
> lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
>
> - ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
> - pdev->name, lpi2c_imx);
> - if (ret)
> - return dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
> -
> i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
> platform_set_drvdata(pdev, lpi2c_imx);
>
> @@ -1527,14 +1522,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> * each transfer
> */
> ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
> - if (ret)
> - return dev_err_probe(&pdev->dev, ret,
> - "can't lock I2C peripheral clock rate\n");
> + if (ret) {
> + dev_err_probe(&pdev->dev, ret,
> + "can't lock I2C peripheral clock rate\n");
> + goto clk_disable;
> + }
>
> lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
> - if (!lpi2c_imx->rate_per)
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "can't get I2C peripheral clock rate\n");
> + if (!lpi2c_imx->rate_per) {
> + ret = dev_err_probe(&pdev->dev, -EINVAL,
> + "can't get I2C peripheral clock rate\n");
> + goto clk_disable;
> + }
>
> if (lpi2c_imx->hwdata->need_prepare_unprepare_clk)
> pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_LONG_TIMEOUT_MS);
> @@ -1546,27 +1545,43 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> pm_runtime_set_active(&pdev->dev);
> pm_runtime_enable(&pdev->dev);
>
> + /*
> + * Reset all internal controller logic and registers to avoid effects of previous status
> + * Reset both Master and Target logic to prevent interrupt storms
> + */
> + writel(MCR_RST, lpi2c_imx->base + LPI2C_MCR);
> + writel(SCR_RST, lpi2c_imx->base + LPI2C_SCR);
> + writel(0, lpi2c_imx->base + LPI2C_MCR);
> + writel(0, lpi2c_imx->base + LPI2C_SCR);
> +
This patch should only include this part. other adjust should be new patch
> temp = readl(lpi2c_imx->base + LPI2C_PARAM);
> lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
> lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
>
> + ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
> + pdev->name, lpi2c_imx);
> + if (ret) {
> + dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
> + goto rpm_disable;
> + }
> +
> /* Init optional bus recovery function */
> ret = lpi2c_imx_init_recovery_info(lpi2c_imx, pdev);
> /* Give it another chance if pinctrl used is not ready yet */
> if (ret == -EPROBE_DEFER)
> - goto rpm_disable;
> + goto free_irq;
>
> /* Init DMA */
> ret = lpi2c_dma_init(&pdev->dev, phy_addr);
> if (ret) {
> if (ret == -EPROBE_DEFER)
> - goto rpm_disable;
> + goto free_irq;
> dev_info(&pdev->dev, "use pio mode\n");
> }
>
> ret = i2c_add_adapter(&lpi2c_imx->adapter);
> if (ret)
> - goto rpm_disable;
> + goto free_irq;
>
> pm_runtime_put_autosuspend(&pdev->dev);
>
> @@ -1574,10 +1589,17 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
>
> return 0;
>
> +free_irq:
> + devm_free_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx);
> +
if use devm_(), need devm_free_irq() here.
Frank
> rpm_disable:
> pm_runtime_dont_use_autosuspend(&pdev->dev);
> - pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> + pm_runtime_set_suspended(&pdev->dev);
> + pm_runtime_put_noidle(&pdev->dev);
> +
> +clk_disable:
> + clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
>
> return ret;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PACTH v2] i2c: imx-lpi2c: mark I2C adapter when hardware is powered down
From: Frank Li @ 2026-06-04 18:54 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: aisheng.dong, andi.shyti, s.hauer, kernel, festevam, carlos.song,
linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260520090910.2879570-1-carlos.song@oss.nxp.com>
On Wed, May 20, 2026 at 05:09:10PM +0800, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> Mark the I2C adapter as suspended during system suspend to block further
> transfers, and resume it on system resume. This prevents potential hangs
> when the hardware is powered down but clients still attempt I2C transfers.
>
> Fixes: 1ee867e465c1 ("i2c: imx-lpi2c: add target mode support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Change for v2:
> - Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
> to prevent potential deadlock if a transfer is active during suspend.
> - Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
> fails.
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index a01c23696481..01ee38131ef2 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -1635,7 +1635,18 @@ static int __maybe_unused lpi2c_runtime_resume(struct device *dev)
>
> static int __maybe_unused lpi2c_suspend_noirq(struct device *dev)
> {
> - return pm_runtime_force_suspend(dev);
> + struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
> + int ret;
> +
> + i2c_mark_adapter_suspended(&lpi2c_imx->adapter);
> +
> + ret = pm_runtime_force_suspend(dev);
> + if (ret) {
> + i2c_mark_adapter_resumed(&lpi2c_imx->adapter);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static int __maybe_unused lpi2c_resume_noirq(struct device *dev)
> @@ -1655,6 +1666,8 @@ static int __maybe_unused lpi2c_resume_noirq(struct device *dev)
> if (lpi2c_imx->target)
> lpi2c_imx_target_init(lpi2c_imx);
>
> + i2c_mark_adapter_resumed(&lpi2c_imx->adapter);
> +
> return 0;
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH] KVM: arm64: Reallocate the nested_mmus array under the mmu_lock
From: Hyunwoo Kim @ 2026-06-04 18:30 UTC (permalink / raw)
To: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, christoffer.dall
Cc: linux-arm-kernel, kvmarm, imv4bel
Code that walks kvm->arch.nested_mmus[] holds kvm->mmu_lock. By contrast,
kvm_vcpu_init_nested() reallocates the array and frees the old buffer while
holding only kvm->arch.config_lock, so a walker can reference the freed
array.
Allocate the new array outside the lock, as the allocation can sleep, and
do only the copy and the pointer swap under the mmu_lock. After the swap no
walker can reach the old buffer, so free it once the lock has been
released.
Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
arch/arm64/kvm/nested.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 38f672e940878..6f7bc9a9992e0 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -89,21 +89,28 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
* again, and there is no reason to affect the whole VM for this.
*/
num_mmus = atomic_read(&kvm->online_vcpus) * S2_MMU_PER_VCPU;
- tmp = kvrealloc(kvm->arch.nested_mmus,
- size_mul(sizeof(*kvm->arch.nested_mmus), num_mmus),
- GFP_KERNEL_ACCOUNT | __GFP_ZERO);
- if (!tmp)
- return -ENOMEM;
- swap(kvm->arch.nested_mmus, tmp);
+ if (num_mmus > kvm->arch.nested_mmus_size) {
+ tmp = kvcalloc(num_mmus, sizeof(*tmp), GFP_KERNEL_ACCOUNT);
+ if (!tmp)
+ return -ENOMEM;
- /*
- * If we went through a realocation, adjust the MMU back-pointers in
- * the previously initialised kvm_pgtable structures.
- */
- if (kvm->arch.nested_mmus != tmp)
- for (int i = 0; i < kvm->arch.nested_mmus_size; i++)
- kvm->arch.nested_mmus[i].pgt->mmu = &kvm->arch.nested_mmus[i];
+ write_lock(&kvm->mmu_lock);
+
+ if (kvm->arch.nested_mmus_size) {
+ memcpy(tmp, kvm->arch.nested_mmus,
+ size_mul(sizeof(*tmp), kvm->arch.nested_mmus_size));
+
+ for (int i = 0; i < kvm->arch.nested_mmus_size; i++)
+ tmp[i].pgt->mmu = &tmp[i];
+ }
+
+ swap(kvm->arch.nested_mmus, tmp);
+
+ write_unlock(&kvm->mmu_lock);
+
+ kvfree(tmp);
+ }
for (int i = kvm->arch.nested_mmus_size; !ret && i < num_mmus; i++)
ret = init_nested_s2_mmu(kvm, &kvm->arch.nested_mmus[i]);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Jason Gunthorpe @ 2026-06-04 18:24 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Michael Kelley, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <yq5apl26qrof.fsf@kernel.org>
On Thu, Jun 04, 2026 at 08:27:36PM +0530, Aneesh Kumar K.V wrote:
> I already sent a v6 in the hope of getting this merged for the next
> merge window. Should I send a v7, or would you prefer that I do the
> rename on top of v6?
I think it is too late for such a major change, but this should be
imaginged to be for rc2ish next cycle. You also have to spell out how
the pkvm patch will get sequenced as well, it would be best to push
that it gets picked up right away.
Jason
^ permalink raw reply
* Re: [PATCH net 1/2] net: airoha: Fix use-after-free in metadata dst teardown
From: Jacob Keller @ 2026-06-04 17:38 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Florian Westphal, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org>
On 6/2/2026 2:21 AM, Lorenzo Bianconi wrote:
> airoha_metadata_dst_free() runs metadata_dst_free() which frees the
> metadata_dst with kfree() immediately, bypassing the RCU grace period.
> In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
> the skb to the metadata_dst. This function requires RCU read-side
> protection and the dst must remain valid until all RCU readers complete.
> Since metadata_dst_free() calls kfree() directly, an use-after-free can
> occur if any skb still holds a noref pointer to the dst when the driver
> tears it down.
> Replace metadata_dst_free() with dst_release() which properly goes
> through the refcount path: when the refcount drops to zero, it schedules
> the actual free via call_rcu_hurry(), ensuring all RCU readers have
> completed before the memory is freed.
>
> Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index cecd66251dba..eab6a98d62b9 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2936,7 +2936,7 @@ static void airoha_metadata_dst_free(struct airoha_gdm_port *port)
> if (!port->dsa_meta[i])
> continue;
>
> - metadata_dst_free(port->dsa_meta[i]);
> + dst_release(&port->dsa_meta[i]->dst);
> }
> }
>
>
the port->dsa_meta is allocated using metadata_dst_alloc().. how is it
safe to use dst_release here? Seems like we should be calling dst_alloc
instead of metadata_dst_alloc in order to use dst_release??
metadata_dst_alloc does call __metadata_dst_init which calls dst_init..
I guess the start of the metadata_dst structure is also the same address
as the internal dst_entry struct...
But dst_destroy does a whole lot more than metadata_dst_release so I
don't feel confident in this actually being a drop-in replacement... It
calls netdev_put, it calls the dst->ops->destroy, it releases child
refs.. Or for metadata dst entries is that all basically a no-op??
I feel like I'm missing something here.. The driver also calls
metadata_dst_free in the remove path and that wasn't changed by this
patch either.
Generally it seems like we should be using the same API to allocate as
to release the object... This is confusing. What am I missing?
^ permalink raw reply
* [GIT PULL] i.MX ARM device tree changes for v7.2
From: Frank.Li @ 2026-06-04 17:02 UTC (permalink / raw)
To: soc, arm; +Cc: Frank.Li, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt-7.2
for you to fetch changes up to 8772e1f64c7d69986821d71d8e58fd10594c9aa1:
dt-bindings: soc: imx: Add fsl,aipi-bus and fsl,emi-bus (2026-06-04 12:47:24 -0400)
----------------------------------------------------------------
i.MX ARM device tree changes for 7.2:
DT Binding Cleanup:
- Replaced undocumented compatible strings with proper ones:
* edt,edt-ft5x06 -> edt,edt-ft5206
* marvell,88E1510 -> ethernet-phy-ieee802.3-c22
* karo,imx6qdl-tx6-sgtl5000 -> simple-audio-card
- Fixed incorrect VAR-SOM-MX6UL references (corrected to VAR-SOM-MX6)
- Added missing required properties:
* #phy-cells for usb-nop-xceiv
* #io-channel-cells to ADC nodes
* bus-type for ov5642/ov5640 cameras
* ti,deskew = <0> for ti,tfp410
- Added missing supply properties (power-supply, vdd-supply, dvdd-supply, avdd-supply)
- Removed redundant/empty properties (bus-width for video-mux, empty clock-names)
- Fixed boolean property warnings and non-existent property references
- Converted TS-4800 watchdog to DT schema
- Renamed wdt nodes to watchdog for consistency
New Features Added:
- PCIe Root Port nodes and PERST property for imx6qdl, imx6sx, and imx7d
- OV5645 camera support for imx7d-pico-pi
- LVDS display panel support for imx6ul-var-som
- WiFi and Bluetooth support for VAR-SOM boards
- nvmem-layout support for imx7
- New bus bindings: fsl,aipi-bus and fsl,emi-bus
- New board binding: variscite,var-som-imx6ull
Code Refactoring:
- VAR-SOM-MX6UL/ULL: factored out common parts for CPU variants
- Separated audio, ethernet (ENET1/ENET2), and SD card support into reusable components
----------------------------------------------------------------
Alexander Feilke (1):
ARM: dts: imx7: add nvmem-layout
Alice Guo (1):
ARM: dts: freescale: add bootph-all to i.MX7ULP watchdog nodes
Eduard Bostina (2):
dt-bindings: watchdog: Convert TS-4800 to DT schema
ARM: dts: nxp: imx51-ts4800: Rename wdt node to watchdog
Frank Li (12):
ARM: dts: imx35: remove empty clock-names for nand-controller@bb000000
ARM: dts: imx25: remove empty clock-names for nand-controller@bb000000
ARM: dts: imx: add ti,deskew = <0> for ti,tfp410
ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g
ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv
ARM: dts: imx: add (power|vdd)-supply for related node
ARM: dts: imx: remove redundant bus-width for video-mux
ARM: dts: imx: Add bus-type for ov5642/ov5640
ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
dt-bindings: soc: imx: Add fsl,aipi-bus and fsl,emi-bus
Hugo Villeneuve (14):
ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply property
ARM: dts: imx6ul-var-som: fix warning for boolean property with a value
ARM: dts: imx6ul-var-som: change incorrect VAR-SOM-MX6UL references
dt-bindings: arm: fsl: change incorrect VAR-SOM-MX6UL references
dt-bindings: arm: fsl: add variscite,var-som-imx6ull
ARM: dts: imx6ul-var-som: Factor out common parts for all CPU variants
ARM: dts: imx6ul-var-som-concerto: Factor out common parts for all CPU variants
ARM: dts: imx6ul-var-som-concerto: order DT properties
ARM: dts: imx6ul-var-som: factor out SD card support
ARM: dts: imx6ul-var-som: add proper Wifi and Bluetooth support
ARM: dts: imx6ul-var-som: factor out ENET2 ethernet support
ARM: dts: imx6ul-var-som: add support for EC configuration option (ENET1)
ARM: dts: imx6ul-var-som: factor out audio support
ARM: dts: imx6ul-var-som: add support for LVDS display panel
Lech Perczak (1):
ARM: dts: imx7d-pico-pi: add OV5645 camera support
Markus Niebel (1):
ARM: dts: imx6ul: add #io-channel-cells to ADC
Sherry Sun (3):
ARM: dts: imx6qdl: Add Root Port node and PERST property
ARM: dts: imx6sx: Add Root Port node and PERST property
ARM: dts: imx7d: Add Root Port node and PERST property
Documentation/devicetree/bindings/arm/fsl.yaml | 8 +-
.../devicetree/bindings/bus/fsl,spba-bus.yaml | 4 +
.../bindings/watchdog/technologic,ts4800-wdt.yaml | 40 +++
.../devicetree/bindings/watchdog/ts4800-wdt.txt | 25 --
arch/arm/boot/dts/nxp/imx/Makefile | 3 +
arch/arm/boot/dts/nxp/imx/imx25.dtsi | 1 -
arch/arm/boot/dts/nxp/imx/imx35.dtsi | 1 -
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 11 +-
arch/arm/boot/dts/nxp/imx/imx53-ppd.dts | 2 +
arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi | 10 +
.../boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 +
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 -
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 18 +-
.../boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
.../boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
.../boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 5 +-
arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
.../arm/boot/dts/nxp/imx/imx6ul-var-som-audio.dtsi | 30 ++
.../boot/dts/nxp/imx/imx6ul-var-som-common.dtsi | 187 ++++++++++++
.../nxp/imx/imx6ul-var-som-concerto-common.dtsi | 215 ++++++++++++++
.../dts/nxp/imx/imx6ul-var-som-concerto-full.dts | 22 ++
.../boot/dts/nxp/imx/imx6ul-var-som-concerto.dts | 318 +--------------------
.../arm/boot/dts/nxp/imx/imx6ul-var-som-enet1.dtsi | 44 +++
.../arm/boot/dts/nxp/imx/imx6ul-var-som-enet2.dtsi | 79 +++++
.../dts/nxp/imx/imx6ul-var-som-lvds-panel.dtsi | 112 ++++++++
arch/arm/boot/dts/nxp/imx/imx6ul-var-som-sd.dtsi | 27 ++
arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi | 75 +++++
arch/arm/boot/dts/nxp/imx/imx6ul-var-som.dtsi | 215 +-------------
arch/arm/boot/dts/nxp/imx/imx6ul.dtsi | 1 +
.../dts/nxp/imx/imx6ull-var-som-concerto-full.dts | 22 ++
.../boot/dts/nxp/imx/imx6ull-var-som-concerto.dts | 21 ++
arch/arm/boot/dts/nxp/imx/imx6ull-var-som.dtsi | 36 +++
arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 10 +
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 68 ++++-
arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx7d.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 12 +
67 files changed, 1143 insertions(+), 594 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/technologic,ts4800-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-audio.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-common.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-concerto-common.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-concerto-full.dts
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-enet1.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-enet2.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-lvds-panel.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-sd.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som-concerto-full.dts
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som-concerto.dts
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som.dtsi
^ permalink raw reply
* Re: [PATCH v2 4/5] KVM: arm64: Omit tag sync on stage-2 mappings of the zero page
From: Catalin Marinas @ 2026-06-04 16:50 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, Ard Biesheuvel,
Kevin Brodsky, Mark Brown, Marc Zyngier, stable
In-Reply-To: <20260604151151.150377-11-ardb+git@google.com>
On Thu, Jun 04, 2026 at 05:11:56PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Commit
>
> f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
>
> removed the PG_mte_tagged flag from the zero page, but missed a KVM code
> path that may set this flag on the zero page when it is used in a
> stage-2 CoW mapping of anonymous memory.
>
> So disregard the zero page explicitly in sanitise_mte_tags().
>
> Fixes: f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
> Cc: <stable@vger.kernel.org> # 5.10.x
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [GIT PULL] clk: samsung: drivers for v7.2
From: Krzysztof Kozlowski @ 2026-06-04 16:47 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Krzysztof Kozlowski, Chanwoo Choi, linux-clk, Sylwester Nawrocki,
Alim Akhtar, Peter Griffin, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Hi Stephen and Michael,
Notable change outside of this pull: Peter Griffin was added as co-maintainer
to Samsung SoC and Samsung SoC clocks. See also commit 20550601bf4 in
linux-next and
https://lore.kernel.org/all/178015858043.36212.8088079079471293822.b4-ty@b4/
Best regards,
Krzysztof
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-7.2
for you to fetch changes up to e11560b050ce867bd7d3ccea138231db54e2250a:
clk: samsung: exynos990: Fix PERIC0/1 USI clock types (2026-05-30 18:50:36 +0200)
----------------------------------------------------------------
Samsung SoC clock drivers changes for v7.2
1. Exynos850: Mark APM (Active Power Management) I3C clocks as critical,
because they are necessary for communication with firmware but we do
not have any consumer of them so far.
2. Exynos990: Correct the parents of a few muxes and propagate rate
requests up.
----------------------------------------------------------------
Alexey Klimov (1):
clk: samsung: exynos850: mark APM I3C clocks as critical
Denzeel Oliva (1):
clk: samsung: exynos990: Fix PERIC0/1 USI clock types
drivers/clk/samsung/clk-exynos850.c | 5 +-
drivers/clk/samsung/clk-exynos990.c | 307 +++++++++++++++++-------------------
2 files changed, 146 insertions(+), 166 deletions(-)
^ permalink raw reply
* [GIT PULL] i.MX SoC driver updates for v7.2
From: Frank.Li @ 2026-06-04 16:45 UTC (permalink / raw)
To: soc, arm; +Cc: Frank.Li, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-soc-updates-for-v7.2
for you to fetch changes up to ccb4b54b8ecf1ebafef96d538cd6c5c8455bb390:
ARM: imx31: Fix IIM mapping leak in revision check (2026-06-01 15:58:13 -0400)
----------------------------------------------------------------
i.MX Soc Changes for v7.2
- Fix IIM mapping leak in imx31 revision check
- Fix CCM node reference leak in imx3
- Make scmi_imx_misc_ctrl_nb variable static in firmware driver
----------------------------------------------------------------
Krzysztof Kozlowski (1):
firmware: imx: sm-misc: Make scmi_imx_misc_ctrl_nb variable static
Yuho Choi (2):
ARM: imx3: Fix CCM node reference leak
ARM: imx31: Fix IIM mapping leak in revision check
arch/arm/mach-imx/cpu-imx31.c | 9 +++++++--
arch/arm/mach-imx/mm-imx3.c | 2 ++
drivers/firmware/imx/sm-misc.c | 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH v01] mailbox/pcc.c: ignore errors on type 4 channels.
From: Adam Young @ 2026-06-04 16:33 UTC (permalink / raw)
To: Sudeep Holla, Jassi Brar
Cc: linux-kernel, linux-hwmon, Rafael J . Wysocki, Len Brown,
linux-acpi, Andi Shyti, Guenter Roeck, Huisong Li, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, linux-arm-kernel
THE ACPI spec states:
"[The Error status register] Contains the processor relative address,
represented in Generic Address Structure (GAS) format, of the Error status
register. This field is ignored by the OSPM on slave channels"
Which Refers to type 4 channels.
https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/14_Platform_Communications_Channel/Platform_Comm_Channel.html#hw-registers-based-communications-subspace-structure-type-5
Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
---
drivers/mailbox/pcc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 636879ae1db7..0deaf7907ed6 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -270,6 +270,9 @@ static int pcc_mbox_error_check_and_clear(struct pcc_chan_info *pchan)
u64 val;
int ret;
+ if (pchan->type == ACPI_PCCT_TYPE_EXT_PCC_SLAVE_SUBSPACE)
+ return 0;
+
ret = pcc_chan_reg_read(&pchan->error, &val);
if (ret)
return ret;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v8 2/5] thermal: samsung: Add Exynos ACPM TMU driver GS101
From: Peter Griffin @ 2026-06-04 16:30 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, André Draszik, Alim Akhtar, jyescas,
linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20260603-acpm-tmu-v8-2-0f1810a356e6@linaro.org>
On Wed, 3 Jun 2026 at 14:00, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Add driver for the Thermal Management Unit (TMU) managed via the Alive
> Clock and Power Manager (ACPM), found on Samsung Exynos SoCs such as
> the Google GS101.
>
> The TMU on the GS101 utilizes a hybrid management model shared between
> the Application Processor (AP) and the ACPM firmware. The driver
> maintains direct memory-mapped access to the TMU interrupt pending
> registers to identify thermal events, while delegating functional
> tasks - such as sensor initialization, threshold configuration, and
> temperature acquisition, to the ACPM firmware via the ACPM IPC
> protocol.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply
* [PATCH v2] regulator: dt-bindings: mt6311: Convert to DT schema
From: Ninad Naik @ 2026-06-04 16:26 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, me,
linux-kernel-mentees, skhan, Ninad Naik
Convert mediatek,mt6311 to DT schema.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Changes in v2:
- Correct "MediaTek" in the title.
- Drop "|" in the top-level description.
- Remove unnecessary regulator node description.
- Remove unused labels from example.
.../regulator/mediatek,mt6311-regulator.yaml | 70 +++++++++++++++++++
.../bindings/regulator/mt6311-regulator.txt | 35 ----------
2 files changed, 70 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
new file mode 100644
index 000000000000..f65ee2c90298
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6311-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6311 Regulator
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek MT6311 is an I2C power management IC that provides one step-down
+ converter and one low-dropout regulator. The regulators are named VDVFS and
+ VBIASN, respectively.
+
+properties:
+ compatible:
+ const: mediatek,mt6311-regulator
+
+ reg:
+ description: I2C slave address.
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: List of regulators provided by this controller.
+
+ patternProperties:
+ "^(VDVFS|VBIASN)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@6b {
+ compatible = "mediatek,mt6311-regulator";
+ reg = <0x6b>;
+
+ regulators {
+ VDVFS {
+ regulator-name = "VDVFS";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-ramp-delay = <10000>;
+ };
+
+ VBIASN {
+ regulator-name = "VBIASN";
+ regulator-min-microvolt = <200000>;
+ regulator-max-microvolt = <800000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
deleted file mode 100644
index 84d544d8c1b1..000000000000
--- a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Mediatek MT6311 Regulator
-
-Required properties:
-- compatible: "mediatek,mt6311-regulator"
-- reg: I2C slave address, usually 0x6b.
-- regulators: List of regulators provided by this controller. It is named
- to VDVFS and VBIASN.
- The definition for each of these nodes is defined using the standard binding
- for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
-
-The valid names for regulators are:
-BUCK:
- VDVFS
-LDO:
- VBIASN
-
-Example:
- mt6311: pmic@6b {
- compatible = "mediatek,mt6311-regulator";
- reg = <0x6b>;
-
- regulators {
- mt6311_vcpu_reg: VDVFS {
- regulator-name = "VDVFS";
- regulator-min-microvolt = < 600000>;
- regulator-max-microvolt = <1400000>;
- regulator-ramp-delay = <10000>;
- };
- mt6311_ldo_reg: VBIASN {
- regulator-name = "VBIASN";
- regulator-min-microvolt = <200000>;
- regulator-max-microvolt = <800000>;
- };
- };
- };
--
2.54.0
^ permalink raw reply related
* RE: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Michael Kelley @ 2026-06-04 16:18 UTC (permalink / raw)
To: Aneesh Kumar K.V, Michael Kelley, Jason Gunthorpe, Michael Kelley
Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <yq5apl26qrof.fsf@kernel.org>
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Sent: Thursday, June 4, 2026 7:58 AM
>
> Michael Kelley <mhklinux@outlook.com> writes:
>
> > From: Jason Gunthorpe <jgg@ziepe.ca> Sent: Tuesday, June 2, 2026 5:55 PM
> >>
> >> On Tue, Jun 02, 2026 at 02:24:40PM +0000, Michael Kelley wrote:
> >>
> >> > Except that in a normal VM, the "unencrypted" pool attribute does *not*
> >> > describe the state of the memory itself. In a normal VM, the memory is
> >> > unencrypted, but the "unencrypted" pool attribute is false. That
> >> > contradiction is the essence of my concern.
> >>
> >> I would argue no..
> >>
> >> When CC is enabled the default state of memory in a Linux environment
> >> is "encrypted". You have to take a special action to "decrypt" it.
> >>
> >> Thus the default state of memory in a non-CC environment is also
> >> paradoxically "encrypted" too.
> >
> > The need to have such an unnatural premise is usually an indication
> > of a conceptual problem with the overall model, or perhaps just a
> > terminology problem.
> >
> > Here's a proposal. The new DMA attribute is DMA_ATTR_CC_SHARED.
> > Name the pool attribute "cc_shared" instead of "unencrypted". Having
> > "cc_shared" set to false in a normal VM doesn't lead to the non-sensical
> > situation of claiming that a normal VM is encrypted. The boolean
> > "unencrypted" parameter that has been added to various calls also
> > becomes "cc_shared". If "CC_SHARED" is a suitable name for the DMA
> > attribute, it ought to be suitable as the pool attribute. And everything
> > matches as well.
> >
>
> That is better. It would also simplify:
>
> if (mem->unencrypted != !!(attrs & DMA_ATTR_CC_SHARED))
> return NULL;
>
> to
> if (mem->cc_shared != !!(attrs & DMA_ATTR_CC_SHARED))
> return NULL;
>
>
> I already sent a v6 in the hope of getting this merged for the next
> merge window. Should I send a v7, or would you prefer that I do the
> rename on top of v6?
>
I would advocate for a v7 with the rename, vs. a separate follow-on
patch to do the rename, just to reduce churn. But I don't know what
the tradeoffs are in trying to hit the next merge window. If a follow-on
patch is more practical from a timing standpoint, I won't object.
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox