On 2026-04-29 11:43, Steven Rostedt wrote:
[...]
AFAIU this is a functional iteration of my prior RFC here:
https://lore.kernel.org/lkml/[email protected]/
perhaps it would be valuable to refer to that thread ?
}
+
+/**
+ * sys_stacktrace_setup - register an address for user space stacktrace
walking.
+ * @op: Type of operation to perform
+ * @addr_start: The virtual address of the stacktrace information
+ * @addr_length: The length of the stacktrace information
+ * @text_start: The virtual address of the text that @addr_start represents
+ * @text_length: The length of teh text
the
also, perhaps add @flags just in case ? This allows changing the
behavior without having to insert entirely new set of ops.
+ *
+ * This system call is used by dynamic library utilities to inform the kernel
Out of curiosity: what would happen if the application chooses to invoke
this system call to register sframe for the main executable ? Should it be
allowed ?
+ * of meta data that it loaded that can be used by the kernel to know how
+ * to stack walk the given text locations.
+ *
+ * Currently only sframes are supported, but in the future, this may be used
+ * to tell the kernel about JIT code which will most likely have a different
+ * format.
+ *
+ * The type command may be extended and parameters may be used for other
+ * purposes.
"type" or "op" ?
Thanks,
Mathieu
+ *
+ * Return: 0 if successful, otherwise a negative error.
+ */
+SYSCALL_DEFINE5(stacktrace_setup, int, op, unsigned long, addr_start,
+ unsigned long, addr_length, unsigned long, text_start,
+ unsigned long, text_length)
+{
+ switch (op) {
+ case STACKTRACE_REGISTER_SFRAME:
+ return sframe_add_section(addr_start, addr_start + addr_length,
+ text_start, text_start+text_length);
+ case STACKTRACE_UNREGISTER_SFRAME:
+ return sframe_remove_section(addr_start);
+ }
+ return -EINVAL;
+}
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
