* [RFC PATCH v2 04/13] HWBP: Add modify_wide_hw_breakpoint_local() API
From: Jinchao Wang @ 2026-07-17 13:03 UTC (permalink / raw)
To: Andrew Morton, Peter Zijlstra, Thomas Gleixner, Steven Rostedt,
Masami Hiramatsu
Cc: Ingo Molnar, Borislav Petkov, Dave Hansen, H . Peter Anvin, x86,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Mathieu Desnoyers, David Hildenbrand, Jonathan Corbet,
Matthew Wilcox, Alan Stern, Randy Dunlap, Alexander Potapenko,
Marco Elver, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc, Jinchao Wang
In-Reply-To: <20260717125023.1895892-1-wangjinchao600@gmail.com>
From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Add modify_wide_hw_breakpoint_local() arch-wide interface which allows
hwbp users to update watch address on-line. This is available if the
arch supports CONFIG_HAVE_REINSTALL_HW_BREAKPOINT.
Note that this allows to change the type only for compatible types,
because it does not release and reserve the hwbp slot based on type.
For instance, you can not change HW_BREAKPOINT_W to HW_BREAKPOINT_X.
Assisted-by: Antigravity:gemini-3.5-flash
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
---
include/linux/hw_breakpoint.h | 6 +++++
kernel/events/hw_breakpoint.c | 43 +++++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+)
diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h
index db199d653dd1..6754ffbee9ed 100644
--- a/include/linux/hw_breakpoint.h
+++ b/include/linux/hw_breakpoint.h
@@ -81,6 +81,9 @@ register_wide_hw_breakpoint(struct perf_event_attr *attr,
perf_overflow_handler_t triggered,
void *context);
+extern int modify_wide_hw_breakpoint_local(struct perf_event *bp,
+ struct perf_event_attr *attr);
+
extern int register_perf_hw_breakpoint(struct perf_event *bp);
extern void unregister_hw_breakpoint(struct perf_event *bp);
extern void unregister_wide_hw_breakpoint(struct perf_event * __percpu *cpu_events);
@@ -124,6 +127,9 @@ register_wide_hw_breakpoint(struct perf_event_attr *attr,
perf_overflow_handler_t triggered,
void *context) { return NULL; }
static inline int
+modify_wide_hw_breakpoint_local(struct perf_event *bp,
+ struct perf_event_attr *attr) { return -EOPNOTSUPP; }
+static inline int
register_perf_hw_breakpoint(struct perf_event *bp) { return -ENOSYS; }
static inline void unregister_hw_breakpoint(struct perf_event *bp) { }
static inline void
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index 789add0c185a..f4709c892d67 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -888,6 +888,49 @@ void unregister_wide_hw_breakpoint(struct perf_event * __percpu *cpu_events)
}
EXPORT_SYMBOL_GPL(unregister_wide_hw_breakpoint);
+/**
+ * modify_wide_hw_breakpoint_local - update breakpoint config for local CPU
+ * @bp: the hwbp perf event for this CPU
+ * @attr: the new attribute for @bp
+ *
+ * This does not release and reserve the slot of a HWBP; it just reuses the
+ * current slot on local CPU. So the users must update the other CPUs by
+ * themselves.
+ * Also, since this does not release/reserve the slot, this can not change the
+ * type to incompatible type of the HWBP.
+ * Return err if attr is invalid or the CPU fails to update debug register
+ * for new @attr.
+ */
+#ifdef CONFIG_HAVE_REINSTALL_HW_BREAKPOINT
+int modify_wide_hw_breakpoint_local(struct perf_event *bp,
+ struct perf_event_attr *attr)
+{
+ struct arch_hw_breakpoint info;
+ int ret;
+
+ if (find_slot_idx(bp->attr.bp_type) != find_slot_idx(attr->bp_type))
+ return -EINVAL;
+
+ ret = hw_breakpoint_arch_parse(bp, attr, &info);
+ if (ret)
+ return ret;
+
+ *counter_arch_bp(bp) = info;
+ bp->attr.bp_addr = attr->bp_addr;
+ bp->attr.bp_type = attr->bp_type;
+ bp->attr.bp_len = attr->bp_len;
+
+ return arch_reinstall_hw_breakpoint(bp);
+}
+#else
+int modify_wide_hw_breakpoint_local(struct perf_event *bp,
+ struct perf_event_attr *attr)
+{
+ return -EOPNOTSUPP;
+}
+#endif
+EXPORT_SYMBOL_GPL(modify_wide_hw_breakpoint_local);
+
/**
* hw_breakpoint_is_used - check if breakpoints are currently used
*
--
2.53.0
^ permalink raw reply related
* [RFC PATCH v2 03/13] x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint
From: Jinchao Wang @ 2026-07-17 13:03 UTC (permalink / raw)
To: Andrew Morton, Peter Zijlstra, Thomas Gleixner, Steven Rostedt,
Masami Hiramatsu
Cc: Ingo Molnar, Borislav Petkov, Dave Hansen, H . Peter Anvin, x86,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Mathieu Desnoyers, David Hildenbrand, Jonathan Corbet,
Matthew Wilcox, Alan Stern, Randy Dunlap, Alexander Potapenko,
Marco Elver, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc, Jinchao Wang
In-Reply-To: <20260717125023.1895892-1-wangjinchao600@gmail.com>
The new arch_reinstall_hw_breakpoint() function can be used in an
atomic context, unlike the more expensive free and re-allocation path.
This allows callers to efficiently re-establish an existing breakpoint,
and x86 advertises the capability via HAVE_REINSTALL_HW_BREAKPOINT.
Since a REINSTALL may change bp_len, setup_hwbp() must clear the
slot's stale len/type and enable bits in DR7 before re-encoding:
OR-merging the new encoding over the old one would keep the CPU
watching with the stale width (verified in QEMU by reading DR7 after
re-arming watch_len=1 over a len8 breakpoint: 0x999906aa merged
without the clearing, 0x199906aa with it).
Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
---
arch/x86/Kconfig | 1 +
arch/x86/include/asm/hw_breakpoint.h | 2 ++
arch/x86/kernel/hw_breakpoint.c | 16 ++++++++++++++--
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bdad90f210e4..5be698db0241 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -246,6 +246,7 @@ config X86
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT
+ select HAVE_REINSTALL_HW_BREAKPOINT
select HAVE_IOREMAP_PROT
select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
select HAVE_IRQ_TIME_ACCOUNTING
diff --git a/arch/x86/include/asm/hw_breakpoint.h b/arch/x86/include/asm/hw_breakpoint.h
index aa6adac6c3a2..c22cc4e87fc5 100644
--- a/arch/x86/include/asm/hw_breakpoint.h
+++ b/arch/x86/include/asm/hw_breakpoint.h
@@ -21,6 +21,7 @@ struct arch_hw_breakpoint {
enum bp_slot_action {
BP_SLOT_ACTION_INSTALL,
+ BP_SLOT_ACTION_REINSTALL,
BP_SLOT_ACTION_UNINSTALL,
};
@@ -65,6 +66,7 @@ extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
int arch_install_hw_breakpoint(struct perf_event *bp);
+int arch_reinstall_hw_breakpoint(struct perf_event *bp);
void arch_uninstall_hw_breakpoint(struct perf_event *bp);
void hw_breakpoint_pmu_read(struct perf_event *bp);
void hw_breakpoint_pmu_unthrottle(struct perf_event *bp);
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 76886467708b..e2dbd43d8e39 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -100,6 +100,10 @@ static int manage_bp_slot(struct perf_event *bp, enum bp_slot_action action)
old_bp = NULL;
new_bp = bp;
break;
+ case BP_SLOT_ACTION_REINSTALL:
+ old_bp = bp;
+ new_bp = bp;
+ break;
case BP_SLOT_ACTION_UNINSTALL:
old_bp = bp;
new_bp = NULL;
@@ -134,10 +138,13 @@ static void setup_hwbp(struct arch_hw_breakpoint *info, int slot, bool enable)
__this_cpu_write(cpu_debugreg[slot], info->address);
dr7 = this_cpu_read(cpu_dr7);
+ /*
+ * Clear the slot's stale len/type and enable bits first: a REINSTALL
+ * with a different bp_len would otherwise OR-merge both encodings.
+ */
+ dr7 &= ~__encode_dr7(slot, 0xf, 0);
if (enable)
dr7 |= encode_dr7(slot, info->len, info->type);
- else
- dr7 &= ~__encode_dr7(slot, info->len, info->type);
/*
* Enabling:
@@ -198,6 +205,11 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
return arch_manage_bp(bp, BP_SLOT_ACTION_INSTALL);
}
+int arch_reinstall_hw_breakpoint(struct perf_event *bp)
+{
+ return arch_manage_bp(bp, BP_SLOT_ACTION_REINSTALL);
+}
+
void arch_uninstall_hw_breakpoint(struct perf_event *bp)
{
arch_manage_bp(bp, BP_SLOT_ACTION_UNINSTALL);
--
2.53.0
^ permalink raw reply related
* [RFC PATCH v2 02/13] x86/hw_breakpoint: Unify breakpoint install/uninstall
From: Jinchao Wang @ 2026-07-17 13:02 UTC (permalink / raw)
To: Andrew Morton, Peter Zijlstra, Thomas Gleixner, Steven Rostedt,
Masami Hiramatsu
Cc: Ingo Molnar, Borislav Petkov, Dave Hansen, H . Peter Anvin, x86,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Mathieu Desnoyers, David Hildenbrand, Jonathan Corbet,
Matthew Wilcox, Alan Stern, Randy Dunlap, Alexander Potapenko,
Marco Elver, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc, Jinchao Wang
In-Reply-To: <20260717125023.1895892-1-wangjinchao600@gmail.com>
Consolidate breakpoint management to reduce code duplication.
The diffstat was misleading, so the stripped code size is compared instead.
After refactoring, it is reduced from 11976 bytes to 11448 bytes on my
x86_64 system built with clang.
This also makes it easier to introduce arch_reinstall_hw_breakpoint().
In addition, including linux/types.h to fix a missing build dependency.
Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
---
arch/x86/include/asm/hw_breakpoint.h | 6 ++
arch/x86/kernel/hw_breakpoint.c | 153 ++++++++++++++++-----------
2 files changed, 95 insertions(+), 64 deletions(-)
diff --git a/arch/x86/include/asm/hw_breakpoint.h b/arch/x86/include/asm/hw_breakpoint.h
index 0bc931cd0698..aa6adac6c3a2 100644
--- a/arch/x86/include/asm/hw_breakpoint.h
+++ b/arch/x86/include/asm/hw_breakpoint.h
@@ -5,6 +5,7 @@
#include <uapi/asm/hw_breakpoint.h>
#define __ARCH_HW_BREAKPOINT_H
+#include <linux/types.h>
/*
* The name should probably be something dealt in
@@ -18,6 +19,11 @@ struct arch_hw_breakpoint {
u8 type;
};
+enum bp_slot_action {
+ BP_SLOT_ACTION_INSTALL,
+ BP_SLOT_ACTION_UNINSTALL,
+};
+
#include <linux/kdebug.h>
#include <linux/percpu.h>
#include <linux/list.h>
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index f846c15f21ca..76886467708b 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b/arch/x86/kernel/hw_breakpoint.c
@@ -49,7 +49,6 @@ static DEFINE_PER_CPU(unsigned long, cpu_debugreg[HBP_NUM]);
*/
static DEFINE_PER_CPU(struct perf_event *, bp_per_reg[HBP_NUM]);
-
static inline unsigned long
__encode_dr7(int drnum, unsigned int len, unsigned int type)
{
@@ -86,96 +85,122 @@ int decode_dr7(unsigned long dr7, int bpnum, unsigned *len, unsigned *type)
}
/*
- * Install a perf counter breakpoint.
- *
- * We seek a free debug address register and use it for this
- * breakpoint. Eventually we enable it in the debug control register.
- *
- * Atomic: we hold the counter->ctx->lock and we only handle variables
- * and registers local to this cpu.
+ * We seek a slot and change it or keep it based on the action.
+ * Returns slot number on success, negative error on failure.
+ * Must be called with IRQs disabled.
*/
-int arch_install_hw_breakpoint(struct perf_event *bp)
+static int manage_bp_slot(struct perf_event *bp, enum bp_slot_action action)
{
- struct arch_hw_breakpoint *info = counter_arch_bp(bp);
- unsigned long *dr7;
- int i;
-
- lockdep_assert_irqs_disabled();
+ struct perf_event *old_bp;
+ struct perf_event *new_bp;
+ int slot;
+
+ switch (action) {
+ case BP_SLOT_ACTION_INSTALL:
+ old_bp = NULL;
+ new_bp = bp;
+ break;
+ case BP_SLOT_ACTION_UNINSTALL:
+ old_bp = bp;
+ new_bp = NULL;
+ break;
+ default:
+ return -EINVAL;
+ }
- for (i = 0; i < HBP_NUM; i++) {
- struct perf_event **slot = this_cpu_ptr(&bp_per_reg[i]);
+ for (slot = 0; slot < HBP_NUM; slot++) {
+ struct perf_event **curr = this_cpu_ptr(&bp_per_reg[slot]);
- if (!*slot) {
- *slot = bp;
- break;
+ if (*curr == old_bp) {
+ *curr = new_bp;
+ return slot;
}
}
- if (WARN_ONCE(i == HBP_NUM, "Can't find any breakpoint slot"))
- return -EBUSY;
+ if (old_bp) {
+ WARN_ONCE(1, "Can't find matching breakpoint slot");
+ return -EINVAL;
+ }
- set_debugreg(info->address, i);
- __this_cpu_write(cpu_debugreg[i], info->address);
+ WARN_ONCE(1, "No free breakpoint slots");
+ return -EBUSY;
+}
- dr7 = this_cpu_ptr(&cpu_dr7);
- *dr7 |= encode_dr7(i, info->len, info->type);
+static void setup_hwbp(struct arch_hw_breakpoint *info, int slot, bool enable)
+{
+ unsigned long dr7;
+
+ set_debugreg(info->address, slot);
+ __this_cpu_write(cpu_debugreg[slot], info->address);
+
+ dr7 = this_cpu_read(cpu_dr7);
+ if (enable)
+ dr7 |= encode_dr7(slot, info->len, info->type);
+ else
+ dr7 &= ~__encode_dr7(slot, info->len, info->type);
/*
- * Ensure we first write cpu_dr7 before we set the DR7 register.
- * This ensures an NMI never see cpu_dr7 0 when DR7 is not.
+ * Enabling:
+ * Ensure we first write cpu_dr7 before we set the DR7 register.
+ * This ensures an NMI never see cpu_dr7 0 when DR7 is not.
*/
+ if (enable)
+ this_cpu_write(cpu_dr7, dr7);
+
barrier();
- set_debugreg(*dr7, 7);
- if (info->mask)
- amd_set_dr_addr_mask(info->mask, i);
+ set_debugreg(dr7, 7);
- return 0;
+ /*
+ * Always push the address mask, even when clearing it (info->mask == 0):
+ * a REINSTALL from a masked range breakpoint to an exact one must drop
+ * the stale mask, or the CPU keeps matching the wider range.
+ * amd_set_dr_addr_mask() is a no-op without X86_FEATURE_BPEXT and skips
+ * redundant MSR writes, so the unconditional call is cheap.
+ */
+ amd_set_dr_addr_mask(enable ? info->mask : 0, slot);
+
+ /*
+ * Disabling:
+ * Ensure the write to cpu_dr7 is after we've set the DR7 register.
+ * This ensures an NMI never see cpu_dr7 0 when DR7 is not.
+ * The barrier keeps the compiler from reordering the two: native
+ * set_debugreg() has no memory clobber of its own.
+ */
+ if (!enable) {
+ barrier();
+ this_cpu_write(cpu_dr7, dr7);
+ }
}
/*
- * Uninstall the breakpoint contained in the given counter.
- *
- * First we search the debug address register it uses and then we disable
- * it.
- *
- * Atomic: we hold the counter->ctx->lock and we only handle variables
- * and registers local to this cpu.
+ * find suitable breakpoint slot and set it up based on the action
*/
-void arch_uninstall_hw_breakpoint(struct perf_event *bp)
+static int arch_manage_bp(struct perf_event *bp, enum bp_slot_action action)
{
- struct arch_hw_breakpoint *info = counter_arch_bp(bp);
- unsigned long dr7;
- int i;
+ struct arch_hw_breakpoint *info;
+ int slot;
lockdep_assert_irqs_disabled();
- for (i = 0; i < HBP_NUM; i++) {
- struct perf_event **slot = this_cpu_ptr(&bp_per_reg[i]);
-
- if (*slot == bp) {
- *slot = NULL;
- break;
- }
- }
-
- if (WARN_ONCE(i == HBP_NUM, "Can't find any breakpoint slot"))
- return;
+ slot = manage_bp_slot(bp, action);
+ if (slot < 0)
+ return slot;
- dr7 = this_cpu_read(cpu_dr7);
- dr7 &= ~__encode_dr7(i, info->len, info->type);
+ info = counter_arch_bp(bp);
+ setup_hwbp(info, slot, action != BP_SLOT_ACTION_UNINSTALL);
- set_debugreg(dr7, 7);
- if (info->mask)
- amd_set_dr_addr_mask(0, i);
+ return 0;
+}
- /*
- * Ensure the write to cpu_dr7 is after we've set the DR7 register.
- * This ensures an NMI never see cpu_dr7 0 when DR7 is not.
- */
- barrier();
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ return arch_manage_bp(bp, BP_SLOT_ACTION_INSTALL);
+}
- this_cpu_write(cpu_dr7, dr7);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp)
+{
+ arch_manage_bp(bp, BP_SLOT_ACTION_UNINSTALL);
}
static int arch_bp_generic_len(int x86_len)
--
2.53.0
^ permalink raw reply related
* [RFC PATCH v2 01/13] arch: add HAVE_REINSTALL_HW_BREAKPOINT
From: Jinchao Wang @ 2026-07-17 13:02 UTC (permalink / raw)
To: Andrew Morton, Peter Zijlstra, Thomas Gleixner, Steven Rostedt,
Masami Hiramatsu
Cc: Ingo Molnar, Borislav Petkov, Dave Hansen, H . Peter Anvin, x86,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Mathieu Desnoyers, David Hildenbrand, Jonathan Corbet,
Matthew Wilcox, Alan Stern, Randy Dunlap, Alexander Potapenko,
Marco Elver, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc, Jinchao Wang
In-Reply-To: <20260717125023.1895892-1-wangjinchao600@gmail.com>
Some architectures can update the address, length or type of an
installed hardware breakpoint in place, without releasing and
re-reserving its slot. Add an opt-in Kconfig symbol so generic code
can offer such an operation on architectures that implement
arch_reinstall_hw_breakpoint().
This is a prerequisite for KWatch, which re-points preallocated
per-CPU breakpoints from atomic context, where the register/release
path (which may sleep and rebalances slot constraints) cannot be
used.
Signed-off-by: Jinchao Wang <wangjinchao600@gmail.com>
---
arch/Kconfig | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/Kconfig b/arch/Kconfig
index fa7507ac8e13..41b3784e0ddd 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -457,6 +457,16 @@ config HAVE_MIXED_BREAKPOINTS_REGS
Select this option if your arch implements breakpoints under the
latter fashion.
+config HAVE_REINSTALL_HW_BREAKPOINT
+ bool
+ depends on HAVE_HW_BREAKPOINT
+ help
+ Depending on the arch implementation of hardware breakpoints,
+ some of them are able to update the breakpoint configuration
+ without release and reserve the hardware breakpoint register.
+ What configuration is able to update depends on hardware and
+ software implementation.
+
config HAVE_USER_RETURN_NOTIFIER
bool
--
2.53.0
^ permalink raw reply related
* [PATCH v3] scripts/kernel-doc: Suggest possible names for excess descriptions
From: Ryszard Knop @ 2026-07-17 12:57 UTC (permalink / raw)
To: Randy Dunlap, linux-doc
Cc: Jonathan Corbet, Shuicheng Lin, Jani Nikula, linux-kernel,
intel-xe
In-Reply-To: <20260714111208.323108-1-ryszard.knop@intel.com>
Recent check_sections() change added a warning if a documentation tag
member name does not match the detected struct/union member names. Since
the checker knows all possible names, we can suggest known names, so
that it's more obvious how to deal with the warning.
Signed-off-by: Ryszard Knop <ryszard.knop@intel.com>
---
Changes in v1:
- Added the suggestion hint in the warning, with basic name substring checks
- Link: https://lore.kernel.org/linux-doc/20260714111208.323108-1-ryszard.knop@intel.com/
Changes in v2:
- Strip trailing whitespace from the warning when the generated hint is empty
- Link: https://lore.kernel.org/linux-doc/20260715111726.394565-1-ryszard.knop@intel.com/
v3:
- Use difflib to generate suggestions even if the tag member is mistyped
- Suggest names based on the nested struct members too
---
tools/lib/python/kdoc/kdoc_parser.py | 51 ++++++++++++++++++++++++++--
1 file changed, 49 insertions(+), 2 deletions(-)
diff --git a/tools/lib/python/kdoc/kdoc_parser.py b/tools/lib/python/kdoc/kdoc_parser.py
index 2dedda215c22..884f42584667 100644
--- a/tools/lib/python/kdoc/kdoc_parser.py
+++ b/tools/lib/python/kdoc/kdoc_parser.py
@@ -11,6 +11,7 @@ and extract embedded documentation comments from it.
import sys
import re
+import difflib
from pprint import pformat
from kdoc.c_lex import CTokenizer, tokenizer_set_log
@@ -558,6 +559,50 @@ class KernelDoc:
self.push_parameter(ln, decl_type, param, dtype,
arg, declaration_name)
+ def get_suggestions_hint(self, decl_name, possible_names):
+ # For decl name 'flags' or 'flgas', suggests 'substruct.flags'
+ submember_exact = []
+ submember_substrings = []
+ submember_suggestions = []
+ for possible_name in possible_names:
+ parts = possible_name.strip().split('.')
+ if len(parts) < 2:
+ continue
+
+ final_part = parts[-1]
+ if decl_name == final_part:
+ submember_exact.append(possible_name)
+ elif decl_name in final_part:
+ submember_substrings.append(possible_name)
+ elif difflib.get_close_matches(decl_name, [final_part]):
+ submember_suggestions.append(possible_name)
+
+ # For decl name 'flgas', suggests 'flags'
+ full_suggestions = difflib.get_close_matches(decl_name, possible_names)
+
+ # For decl name 'member', suggests 'longer_member'
+ full_substrings = [name for name in possible_names if decl_name in name]
+
+ ordered_lists = [
+ submember_exact,
+ submember_substrings,
+ submember_suggestions,
+ full_suggestions,
+ full_substrings,
+ ]
+
+ # Deduplicate but maintain order from most to least likely:
+ unique_suggestions = {}
+ for suggestion_list in ordered_lists:
+ for suggestion in suggestion_list:
+ unique_suggestions[suggestion] = None
+
+ suggestions = list(unique_suggestions.keys())
+ if not suggestions:
+ return ""
+
+ return f"(did you mean one of: '{"', '".join(suggestions)}')"
+
def check_sections(self, ln, decl_name, decl_type):
"""
Check for errors inside sections, emitting warnings if not found
@@ -566,12 +611,13 @@ class KernelDoc:
for section in self.entry.sections:
if section not in self.entry.parameterlist and \
not known_sections.search(section):
+ hint = self.get_suggestions_hint(section, self.entry.parameterlist)
if decl_type == 'function':
dname = f"{decl_type} parameter"
else:
dname = f"{decl_type} member"
self.emit_msg(ln,
- f"Excess {dname} '{section}' description in '{decl_name}'")
+ f"Excess {dname} '{section}' description in '{decl_name}' {hint}".strip())
#
# Check that documented parameter names (from doc comments, including
@@ -591,12 +637,13 @@ class KernelDoc:
if param_name in self.entry.parameterlist:
continue
+ hint = self.get_suggestions_hint(param_name, self.entry.parameterlist)
if decl_type == 'function':
dname = f"{decl_type} parameter"
else:
dname = f"{decl_type} member"
self.emit_msg(ln,
- f"Excess {dname} '{param_name}' description in '{decl_name}'")
+ f"Excess {dname} '{param_name}' description in '{decl_name}' {hint}".strip())
def check_return_section(self, ln, declaration_name, return_type):
"""
--
2.55.0
^ permalink raw reply related
* Re: [RFC PATCH v1 8/8] misc/arm-cla: Add userspace interface
From: Arnd Bergmann @ 2026-07-17 12:54 UTC (permalink / raw)
To: Ryan Roberts, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet
Cc: linux-kernel, linux-arm-kernel, dri-devel, linux-doc
In-Reply-To: <20260717104759.123203-9-ryan.roberts@arm.com>
On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
> Expose CLA devices through a character device so userspace can enumerate
> the available hardware and map accelerator register frames.
>
> Define version 1 of the CLA UAPI with a GET_PARAM ioctl. Report device
> topology, CPU affinity, domain membership, mmap offsets, architecture
> version and attached accelerator masks, together with the IIDR, DEVARCH
> and REVIDR of each accelerator.
>
> CLA registers can only be read from the CPU local to the device, while
> enumeration may occur on any CPU. Validate the supported CLA
> architecture version during device setup and cache the CLA and
> accelerator identification registers for later ioctl queries.
This interface looks very raw at the moment, I expect this will have
one or more larger redesigns.
Most importantly, a single character device to expose an arbitrary
number of underlying hardware features is an inherently flawed security
model. If any specific accelerator is ever found to have a
major vulnerability, that would mean administrators will have to
disable all of them by default.
> Support shared read-write mmap of one or more CLA register pages. Create
> a context for every domain covered by the mapping and resolve faults
> only while that context owns the domain. Queue unassigned contexts with
> the domain scheduler, drop mmap_lock while waiting for assignment and
> retry the fault after the context is woken.
I still need some time to better understand what this means.
Does a CPU have multiple concurrently running contexts? Is a
user process able to starve the allocation of other processes
by just requesting a lot of them?
> +static long cla_ioctl_get_param(unsigned long arg)
> +{
> + struct arm_cla_param __user *uparam = (void __user *)arg;
> + struct arm_cla_param param;
> + int accel_id;
> + int dev_id;
> + int ret;
> +
> + if (copy_from_user(¶m, uparam, sizeof(param)))
> + return -EFAULT;
> +
> + ret = cla_ioctl_validate_param(¶m);
> + if (ret)
> + return ret;
> +
> + dev_id = dev_nospec(ARM_CLA_PARAM_INDEX_DEV(param.index));
> + accel_id = accel_nospec(ARM_CLA_PARAM_INDEX_ACCEL(param.index));
Why is the dev_id/accel_id not a property of the device node itself?
> + switch (param.param) {
> + case ARM_CLA_PARAM_UABI_VERSION:
> + param.value = ARM_CLA_UABI_VERSION;
> + break;
UABI definitions are not versioned, you have to stay compatible
indefinitely. If you need something else, add a new command.
> + wait_event_interruptible(ctx->waitq,
> + READ_ONCE(domain->assigned_ctx) == ctx ||
> + cla_ctx_is_dying(ctx) ||
> + READ_ONCE(domain->broken));
If you call wait_event_interruptible(), you have to check the return
code and deal with it being interrupted.
> +static const struct file_operations cla_fops = {
> + .owner = THIS_MODULE,
> + .mmap = cla_file_mmap,
> + .unlocked_ioctl = cla_file_ioctl,
> +#ifdef CONFIG_COMPAT
> + .compat_ioctl = cla_file_ioctl,
> +#endif
No need for the #ifdef here. Technically setting .compat_ioctl=compat_ptr_ioctl
is the correct way here, though that may change in the future now that
s390 compat mode is gone.
Arnd
^ permalink raw reply
* [RFC PATCH v2 00/13] mm/kwatch: dynamic hardware watchpoints for hunting memory corruption
From: Jinchao Wang @ 2026-07-17 12:50 UTC (permalink / raw)
To: Andrew Morton, Peter Zijlstra, Thomas Gleixner, Steven Rostedt,
Masami Hiramatsu
Cc: Ingo Molnar, Borislav Petkov, Dave Hansen, H . Peter Anvin, x86,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Mathieu Desnoyers, David Hildenbrand, Jonathan Corbet,
Matthew Wilcox, Alan Stern, Randy Dunlap, Alexander Potapenko,
Marco Elver, Mike Rapoport, linux-kernel, linux-mm,
linux-trace-kernel, linux-perf-users, linux-doc, Jinchao Wang
Motivation
==========
The hardest memory corruption bugs are the silent ones: a rogue writer
scribbles over a live object through a stale pointer or a race, and
the victim crashes in a code path far away from the culprit. Any
single developer hits such a bug rarely, but across the kernel's code
base and install base they keep arriving, and each one is
disproportionately expensive to localize. The question to answer is
"who wrote to this object, and from where?", and it is hard to get at
with the existing tools:
- The kernel's own reports - an oops on a clobbered pointer, a
BUG_ON, a list-corruption warning - fire at the victim's access,
not at the corrupting write.
- KASAN/KFENCE catch memory-safety violations: out-of-bounds
accesses and use-after-free. But they have a blind spot: a
corrupting write can be fully memory-safe - a *valid* pointer, in
bounds, to a live object, written just at the wrong time or to the
wrong place - and then they stay silent by design. And even for
the bugs they can catch, KASAN's rebuild, overhead and redzones
change timing and layout enough that racy corruption often no
longer reproduces.
- Hardware watchpoints can catch the writer, but they are scarce
(four slots per CPU on x86), they watch a fixed address, and
registering/releasing one may sleep, so they cannot be managed
from atomic context. Each way of using them also has practical
constraints: the in-kernel API means writing a custom debugging
patch for each hunt, kgdb needs a debug console and stops the
whole machine at every interaction, and perf drives watchpoints
from userspace, so the address must be known before the run.
Design
======
KWatch arms a hardware breakpoint on the exact address a function
invocation is operating on, for exactly as long as that invocation
runs. Four key designs make this work:
1. Hardware breakpoint pool. All breakpoints are preallocated and
parked on a harmless dummy variable. Arming re-points one at the
target address, using a small "reinstall" operation added to the
hw_breakpoint layer; releasing parks it back on the dummy. The
pool is managed locklessly and the arming path calls no sleeping
API, so a breakpoint can be armed from whatever context the
watched function runs in - real NMI excepted - and a hit can
fire and be handled in any context.
2. Function-scoped watch window. A kretprobe pair opens the window
at function entry - resolving the target address and arming a
breakpoint - and closes it on return, releasing the breakpoint.
A depth setting picks which level of a recursion opens the
window, and hits are validated against the arming task and
depth. The window is also what makes the scarce hardware
affordable: every corruption happens within some execution
context, so a breakpoint is armed only while that context runs.
Global variables can also be watched without a window, in a
time-bounded anchor session.
3. Watch expression engine. At each entry it evaluates the
configured expression to resolve that invocation's target
address. The base can be a function argument, the stack pointer,
a symbol or an absolute address; offsets and pointer
dereferences chain on top, so heap fields reachable from an
argument, globals and stack slots are all expressible.
4. Painless deployment. KWatch is fully self-contained and can be
built as a module, loaded only when a corruption hunt needs it.
It is just a debugfs entry until a watch is configured; after
that only the watched function pays the kprobe cost and the
rest of the system runs at full speed, which keeps KWatch usable
on busy, highly concurrent systems.
Together: point KWatch at the suspect function and field with a
single debugfs line, reproduce the bug, and the tracepoint reports
the writer - the writing instruction and its stack trace.
A real case: dummy_hcd
======================
Gadget requests were completing through a clobbered req->complete.
Months of KASAN-enabled syzkaller runs produced only downstream
symptoms, with no lead on the root cause. Watching the victim field
with KWatch:
func_name=usb_gadget_giveback_request watch_expr=arg2+56 \
watch_len=8
caught the writer in the act:
kwatch_hit: KWatch HIT: time=370.399836 ip=memcpy+0xc/0x30
addr=0xffff888109cf5218
=> usb_ep_queue+0xf1/0x3c0
=> raw_process_ep_io+0x5e4/0xd80
=> raw_ioctl+0x251c/0x41c0
=> __se_sys_ioctl+0xfc/0x170
=> do_syscall_64+0x174/0x580
=> entry_SYSCALL_64_after_hwframe+0x77/0x7f
on the same request that crashed an instant later - the crash RIP was
the just-written garbage value. Root cause: dummy_queue()'s single
shared fifo_req is struct-copied over while dummy_timer() is
mid-giveback. A fix based on this diagnosis has been picked up
into the USB tree [1] - KWatch's part was answering who clobbers
the pointer, and from where.
Series layout
=============
Patches 1-4: a minimal "reinstall" operation for hw_breakpoint.
Re-pointing an already-installed breakpoint from a kprobe handler is
not possible with the current API (register/unregister may sleep and
rebalances constraints); reinstall lets the arch rewrite a slot it
already owns, and modify_wide_hw_breakpoint_local() exposes that for
the local CPU - cross-CPU propagation is the caller's job (KWatch
uses async IPIs). Patch 4 is Masami Hiramatsu's work, carried
verbatim from his current wprobe series.
Patches 5-11: KWatch itself, in mm/kwatch/ (patch 7 exports
stack_trace_save_regs() for the modular build).
Patches 12-13: KUnit tests and documentation.
Testing
=======
The dummy_hcd hunt above exercised the function-window path against
a live reproducer. Global watching, session auto-stop and the KUnit
parser suite were verified end to end under QEMU on x86_64. Both
KWATCH=y and KWATCH=m build.
arm64
=====
This RFC deliberately targets x86 only. On arm64 the watchpoint
exception fires before the access, so the arch must single-step over
hits, and today it only does that for the default overflow handler.
Rather than hardcoding a KWatch hook into arm64 core code, I plan a
follow-up that adds a generic way for in-kernel breakpoint consumers
to request stepping, and arm64 support on top of it (a prototype
exists).
Changes in v2
=============
Addressing Steven Rostedt's review and the Sashiko AI review findings
on v1 [2]:
Tracepoint (Steven Rostedt's review):
- u64 field first, count last, and the stack trace is a dynamic
array sized to the captured depth (also fixes leaking the
uninitialized tail of the fixed array).
- div_u64 in TP_printk for 32-bit builds.
Scope:
- Drop access_type: KWatch now always watches for writes. It is a
corruption localizer, and write is the one type that matters for
that job.
hw_breakpoint prerequisites (patches 2-4):
- Restore the compiler barrier before the cpu_dr7 update on the
disable path, lost in the install/uninstall unification.
- Always push the AMD DR address mask, so a reinstall from a masked
range breakpoint to an exact one clears the stale mask.
- Patch 4 updated to Masami's latest version (wprobe v8): parse into
a temporary arch_hw_breakpoint to keep error paths side-effect
free, sync the logical bp->attr fields, -EOPNOTSUPP over -ENOSYS.
Runtime fixes:
- Rate-limit only the cross-CPU arm broadcast, never the local
re-point; suppressed broadcasts are counted and reported as
arm_ipi_suppressed (was: a rate-limited arm skipped the local CPU
too, missing the current window entirely).
- The hit handler reports the per-CPU breakpoint address instead of
the shared attribute another CPU may be re-pointing concurrently.
- Release the context slot claimed by an entry that races the
register/epoch-publish window (slot leak).
- Clamp the context pool size to [256, 32768]: a u16 request above
32768 wrapped roundup_pow_of_two() to zero.
- nmi_rejected and arm_ipi_suppressed are session-scoped now.
- The anchor thread sleeps in TASK_IDLE so a long session no longer
inflates loadavg.
- The debugfs read path takes the control mutex against concurrent
writes and auto-stop.
Kconfig / tests / docs:
- depends on KPROBES/KRETPROBES/STACKTRACE instead of select.
- KWATCH_KUNIT_TEST now explicitly depends on KWATCH=y; the parser
test gets a width-appropriate literal for 32-bit.
- Document that argN bases are only meaningful at function entry,
the IPI rate-limit consequences, and best-effort cleanup when a
task dies abnormally inside the watched function.
Relationship to KStackWatch
===========================
KWatch grew out of KStackWatch [3], an earlier tool aimed at stack
corruption only, and has been substantially reworked since. The
hw_breakpoint prerequisites are carried over from that series.
Major changes since the KStackWatch v8 posting:
- The watch expression engine widens the watchable range from the
stack to any address expressible via function arguments, globals
or stack addresses plus pointer dereference chains.
- The task_struct and scheduler hooks are gone; KWatch is now fully
self-contained, as described above.
- A time-bounded anchor session was added for watching global
variables (duration=N, auto-stop on expiry).
- Hits are reported through a tracepoint carrying a stack trace
instead of printk: safe in NMI-like contexts, and recoverable
after a crash (ftrace_dump_on_oops, kdump, pstore).
- Invocations in real NMI(-like) context are detected and rejected,
with a visible nmi_rejected counter.
- arm64 support and the auto-canary, profiling and test-module
extras were dropped from this series to keep it reviewable.
Feedback on the design, the implementation or the usage is welcome;
if you are staring at a corruption that the existing tools cannot
attribute, give KWatch a try, or simply Cc me - I am glad to help.
[1] https://lore.kernel.org/all/20260714064829.172098-1-wangjinchao600@gmail.com/
[2] https://lore.kernel.org/all/20260714182243.10687-1-wangjinchao600@gmail.com/
[3] https://lore.kernel.org/all/20251110163634.3686676-1-wangjinchao600@gmail.com/
Jinchao Wang (12):
arch: add HAVE_REINSTALL_HW_BREAKPOINT
x86/hw_breakpoint: Unify breakpoint install/uninstall
x86/hw_breakpoint: Add arch_reinstall_hw_breakpoint
mm/kwatch: add watch expression parser and dereference engine
mm/kwatch: add lockless per-task context pool
stacktrace: export stack_trace_save_regs()
mm/kwatch: add hardware breakpoint backend
mm/kwatch: add probe lifecycle runtime
mm/kwatch: add anchor thread for global watchpoints
mm/kwatch: add debugfs control plane
mm/kwatch: add KUnit tests for the watch expression parser
Documentation/dev-tools: document KWatch
Masami Hiramatsu (Google) (1):
HWBP: Add modify_wide_hw_breakpoint_local() API
Documentation/dev-tools/index.rst | 1 +
Documentation/dev-tools/kwatch.rst | 207 ++++++++++++++
MAINTAINERS | 8 +
arch/Kconfig | 10 +
arch/x86/Kconfig | 1 +
arch/x86/include/asm/hw_breakpoint.h | 8 +
arch/x86/kernel/hw_breakpoint.c | 163 ++++++-----
include/linux/hw_breakpoint.h | 6 +
include/trace/events/kwatch.h | 68 +++++
kernel/events/hw_breakpoint.c | 43 +++
kernel/stacktrace.c | 2 +
mm/Kconfig | 1 +
mm/Makefile | 1 +
mm/kwatch/.kunitconfig | 9 +
mm/kwatch/Kconfig | 28 ++
mm/kwatch/Makefile | 4 +
mm/kwatch/anchor.c | 85 ++++++
mm/kwatch/core.c | 324 ++++++++++++++++++++++
mm/kwatch/deref.c | 174 ++++++++++++
mm/kwatch/deref_test.c | 146 ++++++++++
mm/kwatch/hwbp.c | 388 +++++++++++++++++++++++++++
mm/kwatch/kwatch.h | 101 +++++++
mm/kwatch/probe.c | 275 +++++++++++++++++++
mm/kwatch/task_ctx.c | 125 +++++++++
24 files changed, 2115 insertions(+), 63 deletions(-)
create mode 100644 Documentation/dev-tools/kwatch.rst
create mode 100644 include/trace/events/kwatch.h
create mode 100644 mm/kwatch/.kunitconfig
create mode 100644 mm/kwatch/Kconfig
create mode 100644 mm/kwatch/Makefile
create mode 100644 mm/kwatch/anchor.c
create mode 100644 mm/kwatch/core.c
create mode 100644 mm/kwatch/deref.c
create mode 100644 mm/kwatch/deref_test.c
create mode 100644 mm/kwatch/hwbp.c
create mode 100644 mm/kwatch/kwatch.h
create mode 100644 mm/kwatch/probe.c
create mode 100644 mm/kwatch/task_ctx.c
--
2.53.0
^ permalink raw reply
* [GIT PULL] Chinese-docs changes for v7.3
From: Alex Shi @ 2026-07-17 12:43 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, open list, Dongliang Mu, Yanteng Si
The following changes since commit be828e6819ed139b699bf7feb00a546cb7806266:
docs: pt_BR: Translate deprecated interfaces guide to Portuguese
(2026-07-16 16:48:43 -0600)
are available in the Git repository at:
git@gitolite.kernel.org:pub/scm/linux/kernel/git/alexs/linux.git
tags/Chinese-docs-7.3
for you to fetch changes up to 8492d4e6bb7b9b1e78f2d17c4dda5272f25ec118:
docs/zh_CN: Update rust/testing.rst translation (2026-07-17 20:24:09
+0800)
----------------------------------------------------------------
Chinese translation docs for 7.3
This is the Chinese translation subtree for 7.3. It includes
the following changes:
- Add the some rust, module-signing docs translation
- Fix/update couples Chinese translation
Above patches are tested by 'make htmldocs'
Signed-off-by: Alex Shi <alexs@kernel.org>
----------------------------------------------------------------
Ben Guo (5):
docs/zh_CN: add --no-merges to git log example in how-to.rst
docs/zh_CN: Update rust/quick-start.rst translation
docs/zh_CN: Update rust/general-information.rst translation
docs/zh_CN: Update rust/arch-support.rst translation
docs/zh_CN: Update rust/testing.rst translation
Dongliang Mu (2):
docs/zh_CN: polish how-to.rst
docs/zh_CN: restructure how-to.rst patch submission workflow
Ethan Nelson-Moore (2):
docs/zh_CN: fix CONFIG_CGROUP typo for CONFIG_CGROUPS
docs/zh_CN: fix CONFIG_CONPAT typo for CONFIG_COMPAT
Yan Zhu (2):
docs/zh_CN: add module-signing Chinese translation
docs/zh_CN: update admin-guide/index.rst translation
chengyaqiang (1):
docs/zh_CN: fix KASAN SW_TAGS mode description
panzhipop (1):
docs/zh_TW: replace 接口 with 介面 in stable-api-nonsense.rst
Documentation/translations/zh_CN/accounting/psi.rst | 2 +-
Documentation/translations/zh_CN/admin-guide/index.rst | 202
++++++++++++++++++++-------
Documentation/translations/zh_CN/admin-guide/module-signing.rst | 250
++++++++++++++++++++++++++++++++++
Documentation/translations/zh_CN/dev-tools/kasan.rst | 2 +-
Documentation/translations/zh_CN/how-to.rst | 149
+++++++++++++-------
Documentation/translations/zh_CN/rust/arch-support.rst | 1 +
Documentation/translations/zh_CN/rust/general-information.rst | 82
++++++++++-
Documentation/translations/zh_CN/rust/quick-start.rst | 48
+++----
Documentation/translations/zh_CN/rust/testing.rst | 4 +
Documentation/translations/zh_CN/security/self-protection.rst | 2 +-
Documentation/translations/zh_TW/process/stable-api-nonsense.rst | 62
++++-----
11 files changed, 639 insertions(+), 165 deletions(-)
create mode 100644
Documentation/translations/zh_CN/admin-guide/module-signing.rst
^ permalink raw reply
* Re: [RFC PATCH v1 3/8] misc/arm-cla: Probe firmware-described devices
From: Ryan Roberts @ 2026-07-17 12:36 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet
Cc: linux-kernel, linux-arm-kernel, dri-devel, linux-doc
In-Reply-To: <7927c483-57ed-4253-a7df-40104ff2b192@app.fastmail.com>
On 17/07/2026 13:25, Arnd Bergmann wrote:
> On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
>> +
>> +static const struct of_device_id cla_of_match[] = {
>> + {.compatible = "arm,cla",},
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, cla_of_match);
>
> This is missing a device tree binding, and probably needs to versioned
> in some form.
Given the aims of the RFC, I didn't think this would be a blocker for now - of
course it's on the list for if/when we get further along the road.
Thanks,
Ryan
>
> Arnd
^ permalink raw reply
* Re: [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver
From: Ryan Roberts @ 2026-07-17 12:33 UTC (permalink / raw)
To: Marc Zyngier, Will Deacon
Cc: Greg Kroah-Hartman, Arnd Bergmann, Catalin Marinas, Mark Rutland,
Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet, linux-kernel,
linux-arm-kernel, dri-devel, linux-doc, oupton, hch, jgg
In-Reply-To: <87ech1rf6n.wl-maz@kernel.org>
On 17/07/2026 13:09, Marc Zyngier wrote:
> Thanks Will for roping me in.
Sorry - I intentionally didn't include you because last time we spoke you said
you were only really interested in discussions on the virt side of things and I
didn't want to spam your inbox. Perhaps the wrong decision...
>
> On Fri, 17 Jul 2026 12:33:17 +0100,
> Will Deacon <will@kernel.org> wrote:
>>
>>> I'm deliberately constraining the scope to bare-metal support for now.
>>> Virtualization is something we are considering (and have prototyped), but plan
>>> to post a separate RFC for that as follow-up, once we have agreement on
>>> direction for the bare-metal driver.
>>
>> I'd actually like to see what the virtualisation part looks like first
>> because doing it as a bolt-on later feels like the wrong approach. The
>> structure you have at the moment is remarkably clean, given the
>> architectural/CPU interactions (this thing even apparently builds as a
>> module, nice!), but I'm unsure how far you can push the separation once
>> you need to start hacking at KVM. Maybe the MMU notifiers are enough,
>> but I can't tell.
>
> +1.
>
> Virtualisation cannot be a "bolt on the side" exercise. It is an
> integral part of the arm64 tree, particularly for memory management
> and scheduling, all of which have a direct impact on KVM.
>
> I don't think we can really evaluate anything here without looking at
> the full picture.
OK understood - as per reply to Will, we'll prioritise doing a version with virt
support.
Thanks,
Ryan
>
> Thanks,
>
> M.
>
^ permalink raw reply
* Re: [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver
From: Ryan Roberts @ 2026-07-17 12:30 UTC (permalink / raw)
To: Will Deacon
Cc: Greg Kroah-Hartman, Arnd Bergmann, Catalin Marinas, Mark Rutland,
Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet, linux-kernel,
linux-arm-kernel, dri-devel, linux-doc, maz, oupton, hch, jgg
In-Reply-To: <aloS_T3LQvpHeZUV@willie-the-truck>
Hi Will,
On 17/07/2026 12:33, Will Deacon wrote:
> Hi Ryan,
>
> I haven't bothered to look at the code (looks like Sashiko is having fun
> with that), but I'm going to jump at this bit:
Thanks for the quick reply!
JP and I had a quick glance at the Sashiko feedback; looks like some useful
stuff, and a few false alarms. Nothing cricial though. Not that it matters too
much for this stage of discussion.
>
> On Fri, Jul 17, 2026 at 11:47:44AM +0100, Ryan Roberts wrote:
>> * User space availability: The kernel driver exposes the capabilities of the
>> hardware to user space. Arm plans to open source a user space driver, but does
>> not yet have any committed date. I'd like to understand if the availability of
>> this component will be a prerequisite for upstream acceptance of the kernel
>> driver; either way, I'm hoping we can at least progress with some discussion
>> in its absence.
>
> From my perspective, I'm not particularly interested in having code in
> the upstream kernel tree that we can't meaningfully exercise or benefit
> from. I also think that the incentive for Arm to open source the
> user-space driver practically disappears if we merge the kernel part
> first. So, at the moment, this just looks like a burden to me, especially
Understood. Now that I have such a clear statement, hopefully I can use that to
work internally to get commitments and dates to build a proper plan. What I'm
trying to get out of this RFC though, is "is having an open source user space
the main blocker, or are there other significant challenges here too?".
> as it appears to create a brand new, device-specific UAPI for what is
> ostensibly a form of SVA - something which the community is actively
> working on already.
>
> Relatedly, is there a spec and/or fastmodel/qemu (sorry...) support for
> this?
They both exist internally of course. There is a plan to publish the spec, but I
don't think we will converge on a timeframe until after the summer now. I'll
follow up regarding fastmodel.
>
>> I'm deliberately constraining the scope to bare-metal support for now.
>> Virtualization is something we are considering (and have prototyped), but plan
>> to post a separate RFC for that as follow-up, once we have agreement on
>> direction for the bare-metal driver.
>
> I'd actually like to see what the virtualisation part looks like first
> because doing it as a bolt-on later feels like the wrong approach. The
> structure you have at the moment is remarkably clean, given the
> architectural/CPU interactions (this thing even apparently builds as a
> module, nice!), but I'm unsure how far you can push the separation once
> you need to start hacking at KVM. Maybe the MMU notifiers are enough,
> but I can't tell.
The virtualization implementation is not as advanced as bare-metal and JP can
probably comment on it in more detail, but the intention is to expose the HW
using VFIO-MDEV (mediated device framework). We will need exported functions
from (the arm64 part of) KVM to grab the S2 pgdir and to get/put the VMID - we
would not be using MMU notifiers but instead sharing the pgtable and VMID and
piggybacking the CPU's TBLI operations. My current expectation is that it can be
made to work without deep KVM integration and still as a module, but let's see
where we get to with the code. (I have spoken with Marc about this briefly - I
would say he doesn't love it, but agreed to look at the code when we have it).
But I think I'm hearing that to get into a deeper discussion we will need to
post virt support? In which case, I'll prioritise getting something together.
I'm about to be on sabbatical for 4 weeks though, so probably won't be until
~early Sept.
Thanks,
Ryan
>
> Will
^ permalink raw reply
* Re: [RFC PATCH v1 3/8] misc/arm-cla: Probe firmware-described devices
From: Arnd Bergmann @ 2026-07-17 12:25 UTC (permalink / raw)
To: Ryan Roberts, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet
Cc: linux-kernel, linux-arm-kernel, dri-devel, linux-doc
In-Reply-To: <20260717104759.123203-4-ryan.roberts@arm.com>
On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
> +
> +static const struct of_device_id cla_of_match[] = {
> + {.compatible = "arm,cla",},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, cla_of_match);
This is missing a device tree binding, and probably needs to versioned
in some form.
Arnd
^ permalink raw reply
* Re: [RFC PATCH v1 2/8] misc/arm-cla: Add launch operation helpers
From: Arnd Bergmann @ 2026-07-17 12:16 UTC (permalink / raw)
To: Ryan Roberts, Greg Kroah-Hartman, Catalin Marinas, Will Deacon,
Mark Rutland, Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet
Cc: linux-kernel, linux-arm-kernel, dri-devel, linux-doc
In-Reply-To: <20260717104759.123203-3-ryan.roberts@arm.com>
On Fri, Jul 17, 2026, at 12:47, Ryan Roberts wrote:
> From: Jean-Philippe Brucker <jpb@kernel.org>
>
> CLA commands are issued by writing optional payload registers,
> programming the LAUNCH register and polling LRESP until the hardware
> accepts or rejects the operation.
>
> Add a common launch helper that performs this sequence on the CLA's
> local CPU, waits for LRESP completion and translates launch response
> codes into Linux errors.
>
> Build accelerator reset and register read and write support on top of
> it. The register read and write helpers split larger accesses into
> multiple launch operations when an access crosses an eight-register
> window.
I'm a bit confused by the MMIO register access ordering, if this is
not a normal AXI attached device with a DMA master, I think it
would make sense to better document what it is.
> +static inline u64 cla_reg_read(struct cla_dev *dev, off_t reg)
> +{
> + return readq_relaxed(dev->regs + reg);
> +}
> +
> +static inline void cla_reg_write(struct cla_dev *dev, off_t reg, u64
> val)
> +{
> + return writeq_relaxed(val, dev->regs + reg);
> +}
For regular devices that have a DMA master, you cannot use
the relaxed operations by default since they do not serialize
against DMA transfers.
To do this properly, you'd have to define separate cla_reg_read()
and cla_reg_read_relaxed() helpers and then use them as needed,
ideally with a comment for each relaxed instance to explain why
that one is both performance critical and safe.
If for some reason this accelerator is not a DMA master (e.g.
because it is implemented through CPU microcode and accesses
the memory through the CPU's own load/store unit), that should
be documented here to explain that you are relying on
implementation defined behavior outside of the normal driver
and memory model.
> + /*
> + * No barrier needed because accesses use Device-nGnRE, within the
> same
> + * memory-mapped peripheral, so accesses arrive at the endpoint in
> + * program order.
> + */
This comment in turn looks completely useless, as that is true
for any MMIO device. The only barriers that you'd normally need
here on sane architectures (not Alpha) are to serialize MMIO
against DMA.
> +
> + if (launch->data_mode == CLA_DATA_OUT)
> + for (i = 0; i < launch->ndata_m1 + 1; i++)
> + launch->data[i] = cla_reg_read(dev, CLA_REG_DATA(i));
Instead of the open-coded loop, maybe this can be built
on top of __iowrite32_copy()
> +/**
> + * cla_op_wait_lresp - Wait for any LAUNCH op to complete.
> +int cla_op_wait_lresp(struct cla_dev *dev, u64 *lresp)
> +{
> + return readq_relaxed_poll_timeout_atomic(dev->regs + CLA_REG_LRESP,
> + *lresp, FIELD_GET(CLA_LRESP_PENDING, *lresp) == 0,
> + CLA_LRESP_DELAY_US, CLA_LRESP_TIMEOUT_US);
Similarly, the readq_relaxed_poll_timeout_atomic() specifically
does not wait for DMA, so you may need separate helpers for
devices that can do DMA and readq_poll_timeout_atomic() vs devices
that never access memory and can use the relaxed version.
You may also need a non-atomic version, as blocking the CPU
for 100µs is not great for realtime workloads.
Arnd
^ permalink raw reply
* [PATCH 3/3] docs/zh_CN: link to Chinese applying-patches translation
From: Weijie Yuan @ 2026-07-17 12:10 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet, Shuah Khan
Cc: linux-doc, linux-kernel
In-Reply-To: <cover.1784289654.git.wy@wyuan.org>
Now that process/applying-patches.rst has been translated into
Chinese, update the references in zh_CN howto.rst and
admin-guide/README.rst to point to the Chinese translation instead
of the English original.
Signed-off-by: Weijie Yuan <wy@wyuan.org>
---
Documentation/translations/zh_CN/admin-guide/README.rst | 2 +-
Documentation/translations/zh_CN/process/howto.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/zh_CN/admin-guide/README.rst b/Documentation/translations/zh_CN/admin-guide/README.rst
index 7c2ffe7e87c7..0549c79ba1a4 100644
--- a/Documentation/translations/zh_CN/admin-guide/README.rst
+++ b/Documentation/translations/zh_CN/admin-guide/README.rst
@@ -83,7 +83,7 @@ Linux内核6.x版本 <http://kernel.org/>
补丁，则不应先应用6.0.1和6.0.2的补丁。类似地，如果您运行的是6.0.2内核，
并且希望跳转到6.0.3，那么在应用6.0.3补丁之前，必须首先撤销6.0.2补丁
（即patch -R）。更多关于这方面的内容，请阅读
- :ref:`Documentation/process/applying-patches.rst <applying_patches>` 。
+ :ref:`Documentation/translations/zh_CN/process/applying-patches.rst <cn_applying_patches>` 。
或者，脚本 patch-kernel 可以用来自动化这个过程。它能确定当前内核版本并
应用找到的所有补丁::
diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst
index cc47be356dd3..2e39ad557dd4 100644
--- a/Documentation/translations/zh_CN/process/howto.rst
+++ b/Documentation/translations/zh_CN/process/howto.rst
@@ -142,7 +142,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
有助于内核开发的外部文档列表。如果你在内核自带的文档中没有找到你想找
的内容，可以查看这些文档。
- :ref:`Documentation/process/applying-patches.rst <applying_patches>`
+ :ref:`Documentation/translations/zh_CN/process/applying-patches.rst <cn_applying_patches>`
关于补丁是什么以及如何将它打在不同内核开发分支上的好介绍
内核还拥有大量从代码自动生成或者从 ReStructuredText(ReST) 标记生成的文档，
--
2.55.0.369.ge3c30fcd466f
^ permalink raw reply related
* Re: [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver
From: Marc Zyngier @ 2026-07-17 12:09 UTC (permalink / raw)
To: Ryan Roberts, Will Deacon
Cc: Greg Kroah-Hartman, Arnd Bergmann, Catalin Marinas, Mark Rutland,
Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet, linux-kernel,
linux-arm-kernel, dri-devel, linux-doc, oupton, hch, jgg
In-Reply-To: <aloS_T3LQvpHeZUV@willie-the-truck>
Thanks Will for roping me in.
On Fri, 17 Jul 2026 12:33:17 +0100,
Will Deacon <will@kernel.org> wrote:
>
> > I'm deliberately constraining the scope to bare-metal support for now.
> > Virtualization is something we are considering (and have prototyped), but plan
> > to post a separate RFC for that as follow-up, once we have agreement on
> > direction for the bare-metal driver.
>
> I'd actually like to see what the virtualisation part looks like first
> because doing it as a bolt-on later feels like the wrong approach. The
> structure you have at the moment is remarkably clean, given the
> architectural/CPU interactions (this thing even apparently builds as a
> module, nice!), but I'm unsure how far you can push the separation once
> you need to start hacking at KVM. Maybe the MMU notifiers are enough,
> but I can't tell.
+1.
Virtualisation cannot be a "bolt on the side" exercise. It is an
integral part of the arm64 tree, particularly for memory management
and scheduling, all of which have a direct impact on KVM.
I don't think we can really evaluate anything here without looking at
the full picture.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* [PATCH 2/3] docs/zh_CN: add applying-patches to process index
From: Weijie Yuan @ 2026-07-17 12:08 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet, Shuah Khan
Cc: linux-doc, linux-kernel
In-Reply-To: <cover.1784289654.git.wy@wyuan.org>
Now that applying-patches.rst has been translated into Chinese,
add it to the toctree of the zh_CN process index and remove it
from the TODOLIST.
Signed-off-by: Weijie Yuan <wy@wyuan.org>
---
Documentation/translations/zh_CN/process/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst
index 3bcb3bdaf533..3a36ca7d9333 100644
--- a/Documentation/translations/zh_CN/process/index.rst
+++ b/Documentation/translations/zh_CN/process/index.rst
@@ -82,13 +82,13 @@ TODOLIST:
:maxdepth: 1
magic-number
+ applying-patches
volatile-considered-harmful
../arch/riscv/patch-acceptance
../core-api/unaligned-memory-access
TODOLIST:
-* applying-patches
* backporting
* adding-syscalls
* botching-up-ioctls
--
2.55.0.369.ge3c30fcd466f
^ permalink raw reply related
* [PATCH 1/3] docs/zh_CN: add process/applying-patches Chinese translation
From: Weijie Yuan @ 2026-07-17 12:06 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet, Shuah Khan
Cc: linux-doc, linux-kernel
In-Reply-To: <cover.1784289654.git.wy@wyuan.org>
Translate .../process/applying-patches.rst into Chinese.
Update the translation through commit fa04150b8ef7
("Documentation: describe how to apply incremental stable patches")
Signed-off-by: Weijie Yuan <wy@wyuan.org>
---
.../zh_CN/process/applying-patches.rst | 392 ++++++++++++++++++
1 file changed, 392 insertions(+)
create mode 100644 Documentation/translations/zh_CN/process/applying-patches.rst
diff --git a/Documentation/translations/zh_CN/process/applying-patches.rst b/Documentation/translations/zh_CN/process/applying-patches.rst
new file mode 100644
index 000000000000..43ddb808e654
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/applying-patches.rst
@@ -0,0 +1,392 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: ../disclaimer-zh_CN.rst
+
+.. _cn_applying_patches:
+
+:Original: :ref:`Applying Patches To The Linux Kernel <applying_patches>`
+
+:翻译:
+
+ 袁维杰 Weijie Yuan <wy@wyuan.org>
+
+将补丁应用到 Linux 内核
++++++++++++++++++++++++
+
+原文作者：
+ Jesper Juhl，2005 年 8 月
+
+.. note::
+
+ 本文档已经过时。绝大多数情况下，你几乎肯定应该考虑使用 Git，而不是
+ 手工运行 ``patch``。
+
+Linux 内核邮件列表中经常有人询问如何给内核打补丁；更确切地说，为众多
+内核树或分支之一制作的补丁，应当以哪个版本的内核为基础来应用。希望本文
+能够解答这些问题。
+
+除了说明如何应用和撤销补丁，本文还会简要介绍不同的内核树，并举例说明
+如何应用各个内核树特有的补丁。
+
+
+什么是补丁？
+============
+
+补丁是一份短小的文本文档，其中记录了源码树两个不同版本之间的改动。
+补丁由 ``diff`` 程序生成。
+
+要正确应用补丁，你必须知道它是基于哪个版本生成的，又会把源码树更新成
+哪个版本。这两项信息应当记录在补丁文件的元数据中，或者能够根据文件名
+推断出来。
+
+
+如何应用或撤销补丁？
+====================
+
+使用 ``patch`` 程序应用补丁。patch 程序读取 diff 文件（也称补丁
+文件），再按照文件中的描述修改源码树。
+
+Linux 内核补丁以存放内核源码目录的父目录为基准生成。
+
+因此，补丁文件中的路径会带有生成补丁时所用的内核源码目录名（也可能是
+“a/”和“b/”之类的其他目录名）。
+
+这个目录名一般不会恰好与本机的内核源码目录名相同（不过，它往往有助于
+判断未注明版本的补丁是基于哪个版本生成的）。应用补丁时，应先进入内核
+源码目录，再去掉补丁文件所列路径中的第一个组成部分（``patch`` 的
+``-p1`` 参数正是用于此目的）。
+
+要撤销先前应用的补丁，请给 patch 加上 -R 参数。也就是说，如果应用
+补丁时执行的是::
+
+ patch -p1 < ../patch-x.y.z
+
+那么可以这样撤销它::
+
+ patch -R -p1 < ../patch-x.y.z
+
+
+如何把补丁或 diff 文件交给 ``patch``？
+======================================
+
+和 Linux 及其他类 UNIX 操作系统中的许多操作一样，这件事也有好几种
+做法。
+
+下文的所有示例都使用如下语法，通过标准输入（stdin）把未压缩的文件
+交给 patch::
+
+ patch -p1 < path/to/patch-x.y.z
+
+如果你只想照着下文的示例操作，无意了解 patch 的其他用法，那么读到
+这里就可以跳过本节余下的内容。
+
+patch 也能通过 -i 参数取得待处理文件的名称，例如::
+
+ patch -p1 -i path/to/patch-x.y.z
+
+如果补丁文件以 gzip 或 xz 格式压缩，而你不想先解压再应用，可以这样
+把它交给 patch::
+
+ xzcat path/to/patch-x.y.z.xz | patch -p1
+ bzcat path/to/patch-x.y.z.gz | patch -p1
+
+如果想在应用前手工解压补丁文件（下文的示例均假定你已经这样做了），
+只需对文件运行 gunzip 或 xz，例如::
+
+ gunzip patch-x.y.z.gz
+ xz -d patch-x.y.z.xz
+
+执行后会留下一个纯文本的 patch-x.y.z 文件。你可以按自己的喜好，
+通过标准输入或 ``-i`` 参数把它交给 patch。
+
+patch 还有几个很实用的参数：``-s`` 会让 patch 除错误外不输出任何
+信息，以免错误信息很快滚出屏幕；``--dry-run`` 只列出将会发生的事情，
+并不实际修改文件；最后，``--verbose`` 会让 patch 输出更详细的处理
+信息。
+
+
+应用补丁时的常见错误
+====================
+
+应用补丁文件时，patch 会用多种方式检查文件是否合理。
+
+例如，patch 会检查文件是否像一个有效的补丁文件，也会检查待修改代码
+周围的内容是否与补丁提供的上下文相符。这只是它所做的两项基本检查。
+
+如果遇到不太对劲的地方，patch 有两种选择：拒绝应用改动并中止，或者
+稍作调整，设法把补丁应用上去。
+
+patch 会尝试调整的一种情况是：上下文和待修改的行全都匹配，只有行号
+不同。例如，补丁要修改文件中部的内容，但文件开头附近由于某种原因增删
+了几行，就会出现这种情况。此时所有内容其实都能对上，只是整体向前或
+向后移动了一些，patch 通常会相应调整行号并应用补丁。
+
+每当 patch 必须略作调整才能匹配时，它会提示补丁是在经过模糊匹配
+（**fuzz**）后应用的。你应当谨慎对待这样的改动：patch 很可能处理
+正确，但它并不保证每次都能正确处理，有时会得到错误的结果。
+
+如果某项改动无法通过模糊匹配调整，patch 会直接拒绝这项改动，并留下
+一个扩展名为 ``.rej`` 的文件（拒绝文件）。你可以阅读这个文件，准确
+了解哪项改动未能应用，再视需要手工处理。
+
+假如内核源码中没有第三方补丁，只有来自 kernel.org 的补丁，而且补丁
+应用顺序正确，源码文件也没有经过自行修改，那么 patch 绝不应报告模糊
+匹配或拒绝应用。如果还是看到这类信息，你的本地源码树或补丁文件很可能
+已经损坏。此时应先尝试重新下载补丁；如果问题依旧，建议从 kernel.org
+重新下载完整的全新源码树，从头再来。
+
+下面进一步看看 patch 可能输出的几种信息。
+
+如果 patch 停下来并显示 ``File to patch:`` 提示，说明它找不到待修改
+的文件。最可能的原因是你忘记指定 -p1，或者当前目录不对。偶尔也会
+遇到必须用 ``-p0`` 而不是 ``-p1`` 应用的补丁（查看补丁文件便能判断
+是否如此；如果确实如此，是补丁制作者犯了错，但并不致命）。
+
+如果看到 ``Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).``
+或类似信息，说明 patch 必须调整改动的位置才能应用；在这个例子中，
+实际改动位置必须与预期位置相差 7 行才能匹配。
+
+最终得到的文件可能正确，也可能不正确，取决于文件为何与预期不符。
+
+尝试应用一个基于其他内核版本生成的补丁时，经常会出现这种情况。
+
+如果看到 ``Hunk #3 FAILED at 2387.`` 之类的信息，说明补丁未能正确
+应用，patch 程序也无法通过模糊匹配完成应用。此时会生成一个 ``.rej``
+文件，其中包含导致应用失败的改动；还会生成一个 ``.orig`` 文件，其中
+是未能修改的原始内容。
+
+如果看到 ``Reversed (or previously applied) patch detected! Assume
+-R? [n]``，说明 patch 检测到补丁中的改动似乎已经存在。
+
+如果你确实已经应用过这个补丁，只是不慎又应用了一次，请回答 [n]o 并
+中止应用。如果先前应用过补丁，现在本来就想撤销它，只是忘了指定 -R，
+则可以在这里回答 [**y**]es，让 patch 替你撤销。
+
+如果补丁制作者在生成补丁时颠倒了源目录和目标目录，也会出现这条信息；
+在这种情况下，撤销补丁实际上才是在应用补丁。
+
+``patch: **** unexpected end of file in patch`` 或 ``patch unexpectedly
+ends in middle of line`` 之类的信息，表示 patch 无法理解收到的文件。
+可能是文件下载不完整，可能是你没有先解压便把压缩补丁交给了 patch，
+也可能是补丁文件在途经某个邮件客户端或邮件传输代理时遭到破坏，例如
+一行过长的内容被拆成了两行。这类警告通常很容易处理，只需把被拆开的
+两行重新连接（拼接）起来即可。
+
+如前所述，如果把 kernel.org 提供的补丁应用到版本正确、未经修改的
+源码树上，这些错误绝不应出现。因此，如果应用 kernel.org 的补丁时
+遇到这些错误，应当认为补丁文件或源码树已经损坏；建议重新下载完整的
+内核源码树和要应用的补丁，从头再来。
+
+
+除了 ``patch``，还有其他选择吗？
+================================
+
+有。
+
+可以使用 ``interdiff`` 程序（http://cyberelk.net/tim/patchutils/），
+为两个补丁之间的差异生成一个补丁，然后应用生成的补丁。
+
+这样便能一步从 5.7.2 更新到 5.7.3。interdiff 的 -z 参数甚至允许
+直接传入以 gzip 或 bzip2 格式压缩的补丁，无需使用 zcat、bzcat，也
+无需手工解压。
+
+下面是一步从 5.7.2 更新到 5.7.3 的方法::
+
+ interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
+
+尽管 interdiff 能省去一两个步骤，一般仍建议按常规方法多执行这些步骤，
+因为 interdiff 在某些情况下可能产生错误结果。
+
+另一个选择是 ``ketchup``。它是一个自动下载并应用补丁的 Python 脚本
+（https://www.selenic.com/ketchup/）。
+
+其他好用的工具还有：diffstat，用于显示补丁改动的摘要；lsdiff，用于
+简要列出补丁文件影响的文件，还可以选择同时显示各段补丁的起始行号；
+grepdiff，用于在补丁中查找与指定正则表达式匹配的内容，并列出这些内容
+所在的文件。
+
+
+可以从哪里下载补丁？
+====================
+
+补丁可从 https://kernel.org/ 获取。网站首页提供了最新补丁的链接，
+各类补丁也有各自固定的存放位置。
+
+5.x.y（-stable）补丁和 5.x 补丁位于
+
+ https://www.kernel.org/pub/linux/kernel/v5.x/
+
+5.x.y 增量补丁位于
+
+ https://www.kernel.org/pub/linux/kernel/v5.x/incr/
+
+-rc 补丁并不存放在 Web 服务器上，而是根据下面这样的 git 标签按需
+生成
+
+ https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
+
+稳定版的 -rc 补丁位于
+
+ https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
+
+
+5.x 内核
+========
+
+这些是 Linus 发布的基础稳定版本，其中版本号最大者最新。
+
+如果发现回归或其他严重缺陷，会在这个基础版本之上发布 -stable 修复
+补丁（见下文）。每当新的 5.x 基础内核发布时，还会提供一个补丁，用来
+表示上一个 5.x 内核与新内核之间的差异。
+
+要应用从 5.6 更新到 5.7 的补丁，可以按下面的步骤操作。请注意，这类
+补丁**不能**应用到 5.x.y 内核之上，只能应用到基础 5.x 内核之上；
+如果要从 5.x.y 更新到 5.x+1，必须先撤销 5.x.y 补丁。
+
+下面是两个示例::
+
+ # 从 5.6 更新到 5.7
+
+ $ cd ~/linux-5.6 # 进入内核源码目录
+ $ patch -p1 < ../patch-5.7 # 应用 5.7 补丁
+ $ cd ..
+ $ mv linux-5.6 linux-5.7 # 重命名源码目录
+
+ # 从 5.6.1 更新到 5.7
+
+ $ cd ~/linux-5.6.1 # 进入内核源码目录
+ $ patch -p1 -R < ../patch-5.6.1 # 撤销 5.6.1 补丁
+ # 源码目录现在是 5.6
+ $ patch -p1 < ../patch-5.7 # 应用新的 5.7 补丁
+ $ cd ..
+ $ mv linux-5.6.1 linux-5.7 # 重命名源码目录
+
+
+5.x.y 内核
+==========
+
+版本号由三段数字组成的是 -stable 内核。它们包含规模较小但至关重要的
+修复，用于解决某个 5.x 内核中发现的安全问题或严重回归。
+
+对于想使用最新的稳定内核，又无意帮助测试开发版或实验版的用户，推荐
+选择这个分支。
+
+如果没有 5.x.y 内核可用，则版本号最大的 5.x 内核就是当前稳定内核。
+
+-stable 团队既提供普通补丁，也提供增量补丁。下面说明如何应用这两类
+补丁。
+
+普通补丁
+~~~~~~~~
+
+这类补丁不是增量补丁。例如，5.7.3 补丁不能应用到 5.7.2 内核源码
+之上，而应应用到基础 5.7 内核源码之上。
+
+因此，要把 5.7.3 补丁应用到现有的 5.7.2 内核源码，必须先撤销
+5.7.2 补丁（回到基础 5.7 内核源码），再应用新的 5.7.3 补丁。
+
+下面是一个简单的示例::
+
+ $ cd ~/linux-5.7.2 # 进入内核源码目录
+ $ patch -p1 -R < ../patch-5.7.2 # 撤销 5.7.2 补丁
+ $ patch -p1 < ../patch-5.7.3 # 应用新的 5.7.3 补丁
+ $ cd ..
+ $ mv linux-5.7.2 linux-5.7.3 # 重命名内核源码目录
+
+增量补丁
+~~~~~~~~
+
+增量补丁则不同：它们不应用到基础 5.x 内核之上，而应用到前一个稳定版
+内核（5.x.y-1）之上。
+
+下面是应用增量补丁的示例::
+
+ $ cd ~/linux-5.7.2 # 进入内核源码目录
+ $ patch -p1 < ../patch-5.7.2-3 # 应用新的 5.7.3 补丁
+ $ cd ..
+ $ mv linux-5.7.2 linux-5.7.3 # 重命名内核源码目录
+
+
+-rc 内核
+========
+
+这些是候选发布版内核。每当 Linus 认为当前的 git 树（git 是内核的
+源码管理工具）处于相当合理、足以测试的状态时，就会发布这样的开发版内核。
+
+这些内核并不稳定；如果打算运行，就要预料到它们偶尔会出故障。不过，
+在几个主要开发分支中，这是最稳定的一个，而且它最终会成为下一个稳定版
+内核，所以让尽可能多的人参与测试十分重要。
+
+如果你想帮助测试开发版内核，但不想运行真正具有实验性的内容，这个分支
+很合适（有关真正实验性的内容，请参阅下文介绍 -next 和 -mm 内核的
+章节）。
+
+-rc 补丁不是增量补丁；与上文介绍的 5.x.y 补丁一样，它们应用到基础
+5.x 内核之上。-rcN 后缀前面的内核版本号，表示这个 -rc 内核最终会
+成为哪个版本。
+
+因此，5.8-rc5 表示它是 5.8 内核的第五个候选发布版，这个补丁应当
+应用到 5.7 内核源码之上。
+
+下面是三个应用这类补丁的示例::
+
+ # 第一个示例：从 5.7 更新到 5.8-rc3
+
+ $ cd ~/linux-5.7 # 进入 5.7 源码目录
+ $ patch -p1 < ../patch-5.8-rc3 # 应用 5.8-rc3 补丁
+ $ cd ..
+ $ mv linux-5.7 linux-5.8-rc3 # 重命名源码目录
+
+ # 接着从 5.8-rc3 更新到 5.8-rc5
+
+ $ cd ~/linux-5.8-rc3 # 进入 5.8-rc3 目录
+ $ patch -p1 -R < ../patch-5.8-rc3 # 撤销 5.8-rc3 补丁
+ $ patch -p1 < ../patch-5.8-rc5 # 应用新的 5.8-rc5 补丁
+ $ cd ..
+ $ mv linux-5.8-rc3 linux-5.8-rc5 # 重命名源码目录
+
+ # 最后尝试从 5.7.3 更新到 5.8-rc5
+
+ $ cd ~/linux-5.7.3 # 进入内核源码目录
+ $ patch -p1 -R < ../patch-5.7.3 # 撤销 5.7.3 补丁
+ $ patch -p1 < ../patch-5.8-rc5 # 应用新的 5.8-rc5 补丁
+ $ cd ..
+ $ mv linux-5.7.3 linux-5.8-rc5 # 重命名源码目录
+
+
+-mm 补丁与 linux-next 树
+========================
+
+-mm 补丁是 Andrew Morton 发布的实验性补丁。
+
+过去，-mm 树还用于测试子系统补丁；现在这项工作由
+`linux-next` （https://www.kernel.org/doc/man-pages/linux-next.html）
+树承担。子系统维护者先把补丁推送到 linux-next，再在合并窗口期间直接
+发送给 Linus。
+
+-mm 补丁是新功能和其他实验性补丁的试验场，这些补丁并未通过子系统树
+合并。一旦这类补丁在 -mm 中经受一段时间的检验并证明自身价值，Andrew
+就会将其提交给 Linus，以纳入主线。
+
+linux-next 树每天更新，其中包括 -mm 补丁。二者始终处于变化之中，
+含有许多实验性功能、大量不适合主线的调试补丁等，是本文所述各分支中
+实验性最强的。
+
+这些补丁不适合用在必须保持稳定的系统上，运行它们的风险高于其他任何
+分支（务必备有最新的备份；运行任何实验性内核都应如此，运行 -mm 补丁
+或 linux-next 树中的内核时尤其如此）。
+
+我们非常欢迎大家测试 -mm 补丁和 linux-next，因为测试的意义就是在改动
+合入更稳定的 Linus 主线树之前，排查并消除回归、崩溃、数据损坏缺陷、
+构建失败以及其他各种缺陷。
+
+不过，-mm 和 linux-next 的测试者必须明白，这些树发生故障的频率高于
+其他任何内核树。
+
+
+至此，各种内核树已经介绍完毕。希望你现在已经清楚如何应用各类补丁，
+并能帮助测试内核。
+
+感谢 Randy Dunlap、Rolf Eike Beer、Linus Torvalds、Bodo Eggert、
+Johannes Stezenbach、Grant Coady、Pavel Machek，以及其他可能被我
+遗漏的人，感谢他们对本文档的审阅和贡献。
--
2.55.0.369.ge3c30fcd466f
^ permalink raw reply related
* [PATCH 0/3] docs/zh_CN: translate process/applying-patches.rst into Chinese
From: Weijie Yuan @ 2026-07-17 12:06 UTC (permalink / raw)
To: Alex Shi, Yanteng Si, Dongliang Mu, Jonathan Corbet, Shuah Khan
Cc: linux-doc, linux-kernel
Although this page is apparently out of date, perhaps it's not that
bad to add it, which would make our traslation simultaneous with the
English original. That said, I would also be fine if we chose not to
accept this series.
Note that patch 1/3 contains only the translated file itself, so the
document is not part of any toctree yet and Sphinx would emit an
orphan warning ("document isn't included in any toctree") at that
point; patch 2/3 fixes that by adding it to the zh_CN process index.
This follows the existing practice of single-file translation
commits. So if we want to ensure every commit can be successfully
built, I will make the corrections.
Weijie Yuan (3):
docs/zh_CN: add process/applying-patches Chinese translation
docs/zh_CN: add applying-patches to process index
docs/zh_CN: link to Chinese applying-patches translation
.../translations/zh_CN/admin-guide/README.rst | 2 +-
.../zh_CN/process/applying-patches.rst | 392 ++++++++++++++++++
.../translations/zh_CN/process/howto.rst | 2 +-
.../translations/zh_CN/process/index.rst | 2 +-
4 files changed, 395 insertions(+), 3 deletions(-)
create mode 100644 Documentation/translations/zh_CN/process/applying-patches.rst
--
2.55.0.369.ge3c30fcd466f
^ permalink raw reply
* Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Mark Brown @ 2026-07-17 11:51 UTC (permalink / raw)
To: Conor Dooley
Cc: Nuno Sá, Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Jonathan Corbet, Shuah Khan, Marius Cristea, Marcus Folkesson,
Kent Gustavsson, linux-iio, devicetree, linux-kernel, linux-doc,
Janani Sunil, linux-spi, Kent Gustavsson
In-Reply-To: <20260716-stole-copious-7cdaacb6cef6@spud>
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
On Thu, Jul 16, 2026 at 06:06:13PM +0100, Conor Dooley wrote:
> On Thu, Jul 16, 2026 at 01:28:15PM +0100, Mark Brown wrote:
> > Oh, isn't that just multi-pin chip selects then:
> > https://patch.msgid.link/cover.1783729282.git.Jonathan.Santos@analog.com
> No, I think that's something different.
> In this case, there is one chip select that all instances of the device
> share. Both the ADI and Microchip devices then use the upper bits of the
> first/address byte during reads and write to access individual devices.
> In the microchip case that I'm familiar with, what upper bits the device
> responds to are set by fuses in the factory. They also share the same MOSI
> and MISO.
I'm struggling to identify a way in which this is functionally different
to a multi-pin chip select.
> The SPI core already supports two of these devices from Microchip, since
> it just modifies the contents of tx_buf in a spi_transfer.
When I said we'd have to modify the bitstream I was told that wasn't the
case and this was just asserting more pins along with the "chip select".
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] docs: pt_BR: process: Translate the security-bugs.rst
From: Daniel Pereira @ 2026-07-17 11:34 UTC (permalink / raw)
To: Álysson Gleyson da Silva; +Cc: corbet, linux-doc
In-Reply-To: <20260717014310.23809-1-alyssongleyson.dev@gmail.com>
Em qui., 16 de jul. de 2026 às 22:45, Álysson Gleyson da Silva
<alyssongleyson.dev@gmail.com> escreveu:
>
> Translate the documentation on security bugs into Brazilian Portuguese,
> maintaining consistency with the original formatting rules.
>
> Signed-off-by: Álysson Gleyson da Silva <alyssongleyson.dev@gmail.com>
> ---
> Documentation/translations/pt_BR/index.rst | 1 +
> .../pt_BR/process/security-bugs.rst | 370 ++++++++++++++++++
> 2 files changed, 371 insertions(+)
Thank you for sending this patch. I’ve reviewed the translation of
`security-bugs.rst` and it looks great. The terminology is accurate
and consistent with the existing documentation.
I am in full agreement with these changes.
Acked-by: Daniel Pereira <danielmaraboo@gmail.com>
Best regards,
Daniel
^ permalink raw reply
* Re: [RFC PATCH v1 0/8] Arm Core Local Accelerator Driver
From: Will Deacon @ 2026-07-17 11:33 UTC (permalink / raw)
To: Ryan Roberts
Cc: Greg Kroah-Hartman, Arnd Bergmann, Catalin Marinas, Mark Rutland,
Jean-Philippe Brucker, Oded Gabbay, Jonathan Corbet, linux-kernel,
linux-arm-kernel, dri-devel, linux-doc, maz, oupton, hch, jgg
In-Reply-To: <20260717104759.123203-1-ryan.roberts@arm.com>
Hi Ryan,
I haven't bothered to look at the code (looks like Sashiko is having fun
with that), but I'm going to jump at this bit:
On Fri, Jul 17, 2026 at 11:47:44AM +0100, Ryan Roberts wrote:
> * User space availability: The kernel driver exposes the capabilities of the
> hardware to user space. Arm plans to open source a user space driver, but does
> not yet have any committed date. I'd like to understand if the availability of
> this component will be a prerequisite for upstream acceptance of the kernel
> driver; either way, I'm hoping we can at least progress with some discussion
> in its absence.
From my perspective, I'm not particularly interested in having code in
the upstream kernel tree that we can't meaningfully exercise or benefit
from. I also think that the incentive for Arm to open source the
user-space driver practically disappears if we merge the kernel part
first. So, at the moment, this just looks like a burden to me, especially
as it appears to create a brand new, device-specific UAPI for what is
ostensibly a form of SVA - something which the community is actively
working on already.
Relatedly, is there a spec and/or fastmodel/qemu (sorry...) support for
this?
> I'm deliberately constraining the scope to bare-metal support for now.
> Virtualization is something we are considering (and have prototyped), but plan
> to post a separate RFC for that as follow-up, once we have agreement on
> direction for the bare-metal driver.
I'd actually like to see what the virtualisation part looks like first
because doing it as a bolt-on later feels like the wrong approach. The
structure you have at the moment is remarkably clean, given the
architectural/CPU interactions (this thing even apparently builds as a
module, nice!), but I'm unsure how far you can push the separation once
you need to start hacking at KVM. Maybe the MMU notifiers are enough,
but I can't tell.
Will
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v4 5/7] net: wwan: t9xx: Add FSM thread
From: Wu. JackBB (GSM) @ 2026-07-17 11:02 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <cbd2ef0bba8e46efb19f692a2e114149@compal.com>
Hi Simon,
After further internal review, we are correcting several
responses from our previous reply. The following items will
be fixed in v5.
On Jack Wu wrote:
>> [Severity: High]
>> Infinite busy loop on signal pending.
> This is intentional. Channel disable must complete or timeout.
> The loop does not busy-spin: each iteration sleeps in
> wait_event_interruptible_timeout until the condition is met or
> the timeout expires.
Will change wait_event_interruptible_timeout to
wait_event_timeout and remove the -ERESTARTSYS / goto
start_wait block.
>> [Severity: High]
>> Race in mtk_fsm_evt_submit — fsm_handler NULL after spinlock
>> release.
> The GATECLOSED check under evtq_lock ensures fsm_handler is
> valid. After the check passes, the event is submitted and the
> kthread is woken.
Will move wake_up_process inside evtq_lock in evt_submit, and
have mtk_fsm_exit clear fsm_handler under evtq_lock:
evt_submit:
wake_up_process(fsm->fsm_handler);
spin_unlock_irqrestore(&fsm->evtq_lock, flags);
mtk_fsm_exit:
spin_lock_irqsave(&fsm->evtq_lock, flags);
handler = fsm->fsm_handler;
fsm->fsm_handler = NULL;
spin_unlock_irqrestore(&fsm->evtq_lock, flags);
if (handler)
kthread_stop(handler);
>> [Severity: High]
>> rtft_entry->data passed to action callback before data_len
>> validation.
> The action functions only read fixed-size fields. The modem
> firmware is a trusted source.
Will move data_len validation before the callback call in
mtk_fsm_parse_hs2_msg, and pass data_len to the callback.
>> [Severity: High]
>> Uninitialized kernel heap memory in mtk_fsm_send_hs3_msg.
> The reserved[2] field is sent to the local modem over PCIe DMA,
> not exposed to external networks.
Will add memset(skb->data, 0, RTFT_DATA_SIZE) after
__dev_alloc_skb in mtk_fsm_send_hs3_msg.
>> [Severity: High]
>> Silent kcalloc failure in mtk_port_disable.
> Allocation failure is extremely unlikely. Hardware has already
> been power-cycled via PLDR.
Will replace radix_tree_gang_lookup with radix_tree_for_each_slot,
eliminating the temporary array. Same pattern as
mtk_port_search_by_name.
Thanks.
Jack Wu
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v4 4/7] net: wwan: t9xx: Add control port
From: Wu. JackBB (GSM) @ 2026-07-17 11:00 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <3a3b077758604433a0ddca3f3467a561@compal.com>
Hi Simon,
After further internal review, we are correcting several
responses from our previous reply. The following items will
be fixed in v5.
On [date] Jack Wu wrote:
>> [Severity: High]
>> Can this lead to use-after-free and double-free on the skb?
> No. The recv callback (mtk_port_internal_recv) does not free
> the skb on error — it returns -ENXIO and leaves skb ownership
> with the caller.
>> [Severity: High]
>> This is where the second free of the skb occurs when propagating
>> the error from the recv callback.
> As above, the recv callback does not free the skb on error.
>> [Severity: High]
>> This is where the skb is freed on the error path before returning
>> -ENXIO.
> mtk_port_internal_recv() does not call dev_kfree_skb_any() on the
> error path.
Our previous response was incorrect. In Patch 4's code,
mtk_port_internal_recv's drop_data does have
dev_kfree_skb_any(skb) — the double-free and UAF are real.
Will remove dev_kfree_skb_any(skb) from
mtk_port_internal_recv's drop_data path in v5. The caller
(mtk_port_rx_dispatch) is the sole owner and frees the skb
on error.
>> [Severity: High]
>> Could this create an infinite loop in kernel space?
> This is intentional. Channel enable/disable are control plane
> operations that must complete or timeout. The loop does not
> busy-spin: each iteration sleeps in
> wait_event_interruptible_timeout until the condition is met or
> the timeout expires.
>> [Severity: High]
>> This appears to have the same infinite loop risk.
> Same reasoning as mtk_port_ch_enable.
Will change wait_event_interruptible_timeout to
wait_event_timeout in both mtk_port_ch_enable and
mtk_port_ch_disable, and remove the -ERESTARTSYS / goto
start_wait block.
>> [Severity: High]
>> Missing bounds check on msg->port_cnt in
>> mtk_port_status_update.
> The message is already validated by head_pattern, tail_pattern,
> and version checks before the loop. The modem firmware is a
> trusted source.
Will move data_len validation before the callback call in
mtk_fsm_parse_hs2_msg, pass data_len to the callback, and add
a bounds check in mtk_port_status_update:
if (data_len < sizeof(*msg) +
le16_to_cpu(msg->port_cnt) * sizeof(*port_info))
return -EPROTO;
Thanks.
Jack Wu
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v4 3/7] net: wwan: t9xx: Add control DMA interface
From: Wu. JackBB (GSM) @ 2026-07-17 10:57 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <cacde4a05d6a48afbac6425425fe180c@compal.com>
Hi Simon,
After further internal review, we are correcting several
responses from our previous reply. The following items will
be fixed in v5.
On [date] Jack Wu wrote:
>> [Severity: High]
>> Is a dma_rmb() needed after checking the hardware ownership flag?
> The GPD descriptors are allocated from a coherent DMA pool
> (dma_pool_zalloc), so CPU cache coherency is guaranteed by the DMA
> mapping. A dma_rmb() is not needed because coherent memory ensures
> the CPU always observes the latest values written by the device.
We Will remove the rmb() and add dma_rmb() after the HWO check in
both TX and RX done paths:
/* TX done */
if (!req->data_vm_addr ||
(req->gpd->tx_gpd.gpd_flags & CLDMA_GPD_FLAG_HWO))
break;
dma_rmb();
/* RX done */
if (req->gpd->rx_gpd.gpd_flags & CLDMA_GPD_FLAG_HWO)
break;
dma_rmb();
mtk_cldma_rx_skb_adjust(mdev, rxq, req);
>> [Severity: High]
>> If mtk_cldma_reload_rx_skb fails due to memory pressure, it jumps
>> to out without advancing rxq->free_idx.
> If mtk_cldma_reload_rx_skb() fails, the code jumps to "out" which
> unmasks the interrupt. On the next hardware interrupt, rx_done_work
> runs again and retries from the same free_idx.
Will change the failure path to recycle the old buffer and return
the descriptor to hardware, dropping the current packet to
guarantee forward progress.
>> [Severity: High]
>> Does this code safely handle non-linear SKBs?
> When nr_bds == 0, the SKB is always linear — it is allocated
> internally via __dev_alloc_skb() with data copied via skb_put().
Will change skb->len to skb_headlen(skb).
>> [Severity: High]
>> Could there be a race condition here with mtk_cldma_tx_done_work?
> No race exists. tx_done_work sees HWO still set.
Will add a free_idx == wr_idx boundary check at the top of the
done_work loop (using READ_ONCE/WRITE_ONCE) to prevent done_work
from crossing into submit territory on descriptor reuse.
Thanks
^ permalink raw reply
* [PATCH v28 7/7] arm64: dts: imx8ulp-evk: add reserved memory property
From: pankaj.gupta @ 2026-07-17 11:45 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Pankaj Gupta
Cc: linux-doc, linux-kernel, devicetree, imx, linux-arm-kernel
In-Reply-To: <20260717-imx-se-if-v28-0-0a9659c7e69d@nxp.com>
From: Pankaj Gupta <pankaj.gupta@nxp.com>
Reserve 1MB of DDR memory region due to EdgeLock Enclave's hardware
limitation restricting access to DDR addresses from 0x80000000
to 0xafffffff.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 5dea66c1e7aa..16399d921e04 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * Copyright 2021 NXP
+ * Copyright 2021, 2025 NXP
*/
/dts-v1/;
@@ -37,6 +37,12 @@ linux,cma {
linux,cma-default;
};
+ ele_reserved: memory@90000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x90000000 0 0x100000>;
+ no-map;
+ };
+
m33_reserved: noncacheable-section@a8600000 {
reg = <0 0xa8600000 0 0x1000000>;
no-map;
@@ -259,6 +265,10 @@ &usdhc0 {
status = "okay";
};
+&hsm0 {
+ memory-region = <&ele_reserved>;
+};
+
&fec {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_enet>;
--
2.43.0
^ permalink raw reply related
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