[RFC PATCH 0/5] Improvements to unwind user

[RFC PATCH 0/5] Improvements to unwind user

[Mathieu Desnoyers]

Here are a few improvements to unwind user for feedback.

Thanks,

Mathieu

Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Indu Bhagat <indu.bhagat@oracle.com>
Cc: "Jose E. Marchesi" <jemarch@gnu.org>
Cc: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Jens Remus <jremus@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>

Mathieu Desnoyers (5):
  unwind_user: Fix userspace unwind iterator 32-bit compat handling
  unwind: Export unwind_user symbol to GPL modules
  unwind deferred: Introduce unwind_user_trace_cached
  unwind: Rename unwind_stacktrace to unwind_user_stacktrace
  unwind: Introduce unwind user entry type

 arch/Kconfig                             |   4 -
 arch/x86/Kconfig                         |   1 -
 arch/x86/include/asm/unwind_user.h       |   9 +-
 arch/x86/include/asm/unwind_user_types.h |   4 +-
 arch/x86/kernel/stacktrace.c             |   6 +-
 include/linux/unwind_deferred.h          |   8 +-
 include/linux/unwind_deferred_types.h    |   6 +-
 include/linux/unwind_user.h              |  11 +-
 include/linux/unwind_user_types.h        |  36 ++++--
 kernel/unwind/deferred.c                 |  35 +++++-
 kernel/unwind/user.c                     | 147 ++++++++++++++---------
 11 files changed, 167 insertions(+), 100 deletions(-)

-- 
2.43.0

[RFC PATCH 1/5] unwind_user: Fix userspace unwind iterator 32-bit compat handling

[Mathieu Desnoyers]

Refactor the stack unwind iterator to clean the overall design and fix
32-bit compat corner-cases that arise due to confusion over the semantic
of the struct unwind_user_state type field.

Observed Issue
==============

Before this refactor, the struct unwind_user_state type field identifies:

- Whether sframe is available in the current process, for at least
  portions of the address space,
- Whether frame pointers should be used for stack walk,
- Whether frame pointers should be used for stack walk in a 32-bit
  compat process.

It would be natural for the unwind iterator caller to expect the
"state->type" to contain the type of stack walk operation performed for
the most recent unwind iteration (unwind_user_next()), but it actually
acts as an internal cache and is unrelated to the current iteration,
which makes this field confusing.

It is not only confusing to the caller, but also to the implementation
of unwind_user_next(). Is has the following drawbacks:

- A 32-bit compat process will favor using frame pointers rather than
  sframe for its next unwind iterator, which is an unexpected priority
  order because sframe is more accurate than frame pointers when
  available.
- Because the "UNWIND_USER_TYPE_SFRAME" state type is unaware of 32-bit
  compat, handling of sframe would be broken on 32-bit compat because
  compat_fp_state() would return false, thus expecting 64-bit unsigned
  long types.

Moreover, only IA32 compat emulation is supported. x32 support appears
to be missing.

Cause
=====

Associating a semantic to a single enumeration field that consists of:

- many orthogonal properties, without listing all those properties
  (sframe vs frame pointer, compat vs non-compat) within each of the
  enumeration labels,
- an implicit priority,

leads to confusion in the unwind iterator implementation.

Using ifdef based on CONFIG_IA32_EMULATION and re-implementing a custom
"in_compat_mode" rather than using the pre-existing in_compat_syscall()
contributes to mishandling of x32 binaries.

Solution
========

Split this type field into three fields:

- A "current_type" field, which can be queried by the iterator caller
  and by architecture code to learn which method is used for the
  current unwind iteration,
- An "available_types" field, which is a bitmask of available user types.
  It is used internally by the iterator implementation.
- A "compat" field to track whether the unwind targets a 32-bit compat
  process.

This allows removing the "UNWIND_USER_TYPE_COMPAT_FP" label from the
unwind types, since it is now implicitly taken into account by the
"compat" field.

This approach will also make it easier to introduce new unwind types
in the future, such as an unwinder for JIT code.

Also use CONFIG_COMPAT ifdef rather than CONFIG_IA32_EMULATION, and
remove the in_compat_mode() custom macro in favor of
in_compat_syscall(). This aims to fix x32 support.

Known Drawbacks
===============

None.

[ This is based on linux-trace unwind/sframe ]

Fixes: 1abc29eeca39 ("unwind_user/sframe: Wire up unwind_user to sframe")
Fixes: ce8d69a1a578 ("unwind_user/x86: Enable compat mode frame pointer unwinding on x86")
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Indu Bhagat <indu.bhagat@oracle.com>
Cc: "Jose E. Marchesi" <jemarch@gnu.org>
Cc: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Jens Remus <jremus@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 arch/Kconfig                             |   4 -
 arch/x86/Kconfig                         |   1 -
 arch/x86/include/asm/unwind_user.h       |   9 +-
 arch/x86/include/asm/unwind_user_types.h |   4 +-
 arch/x86/kernel/stacktrace.c             |   6 +-
 include/linux/unwind_user.h              |   9 --
 include/linux/unwind_user_types.h        |  25 ++++-
 kernel/unwind/user.c                     | 137 +++++++++++++----------
 8 files changed, 109 insertions(+), 86 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 86eec85cb898..c2f12135db92 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -442,10 +442,6 @@ config HAVE_UNWIND_USER_FP
 	bool
 	select UNWIND_USER
 
-config HAVE_UNWIND_USER_COMPAT_FP
-	bool
-	depends on HAVE_UNWIND_USER_FP
-
 config HAVE_UNWIND_USER_SFRAME
 	bool
 	select UNWIND_USER
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8a382a6b9be3..05dbfa3eb8ea 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -302,7 +302,6 @@ config X86
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_UACCESS_VALIDATION		if HAVE_OBJTOOL
 	select HAVE_UNSTABLE_SCHED_CLOCK
-	select HAVE_UNWIND_USER_COMPAT_FP	if IA32_EMULATION
 	select HAVE_UNWIND_USER_FP		if X86_64
 	select HAVE_UNWIND_USER_SFRAME		if X86_64
 	select HAVE_USER_RETURN_NOTIFIER
diff --git a/arch/x86/include/asm/unwind_user.h b/arch/x86/include/asm/unwind_user.h
index 19634a73612d..77f7af37aa82 100644
--- a/arch/x86/include/asm/unwind_user.h
+++ b/arch/x86/include/asm/unwind_user.h
@@ -3,6 +3,7 @@
 #define _ASM_X86_UNWIND_USER_H
 
 #include <linux/unwind_user_types.h>
+#include <linux/compat.h>
 
 #define ARCH_INIT_USER_FP_FRAME							\
 	.cfa_off	= (s32)sizeof(long) *  2,				\
@@ -10,7 +11,7 @@
 	.fp_off		= (s32)sizeof(long) * -2,				\
 	.use_fp		= true,
 
-#ifdef CONFIG_IA32_EMULATION
+#ifdef CONFIG_COMPAT
 
 #define ARCH_INIT_USER_COMPAT_FP_FRAME						\
 	.cfa_off	= (s32)sizeof(u32)  *  2,				\
@@ -18,14 +19,12 @@
 	.fp_off		= (s32)sizeof(u32)  * -2,				\
 	.use_fp		= true,
 
-#define in_compat_mode(regs) !user_64bit_mode(regs)
-
 void arch_unwind_user_init(struct unwind_user_state *state,
 			   struct pt_regs *regs);
 
 static inline void arch_unwind_user_next(struct unwind_user_state *state)
 {
-	if (state->type != UNWIND_USER_TYPE_COMPAT_FP)
+	if (!in_compat_syscall())
 		return;
 
 	state->ip += state->arch.cs_base;
@@ -35,7 +34,7 @@ static inline void arch_unwind_user_next(struct unwind_user_state *state)
 #define arch_unwind_user_init arch_unwind_user_init
 #define arch_unwind_user_next arch_unwind_user_next
 
-#endif /* CONFIG_IA32_EMULATION */
+#endif /* CONFIG_COMPAT */
 
 #include <asm-generic/unwind_user.h>
 
diff --git a/arch/x86/include/asm/unwind_user_types.h b/arch/x86/include/asm/unwind_user_types.h
index f93d535f900e..7b940520659e 100644
--- a/arch/x86/include/asm/unwind_user_types.h
+++ b/arch/x86/include/asm/unwind_user_types.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_UNWIND_USER_TYPES_H
 #define _ASM_X86_UNWIND_USER_TYPES_H
 
-#ifdef CONFIG_IA32_EMULATION
+#ifdef CONFIG_COMPAT
 
 struct arch_unwind_user_state {
 	unsigned long ss_base;
@@ -10,7 +10,7 @@ struct arch_unwind_user_state {
 };
 #define arch_unwind_user_state arch_unwind_user_state
 
-#endif /* CONFIG_IA32_EMULATION */
+#endif /* CONFIG_COMPAT */
 
 #include <asm-generic/unwind_user_types.h>
 
diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index 8ef9d8c71df9..396897851b00 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -131,13 +131,13 @@ void arch_stack_walk_user(stack_trace_consume_fn consume_entry, void *cookie,
 	}
 }
 
-#ifdef CONFIG_IA32_EMULATION
+#ifdef CONFIG_COMPAT
 void arch_unwind_user_init(struct unwind_user_state *state,
 			   struct pt_regs *regs)
 {
 	unsigned long cs_base, ss_base;
 
-	if (state->type != UNWIND_USER_TYPE_COMPAT_FP)
+	if (user_64bit_mode(regs))
 		return;
 
 	cs_base = insn_get_seg_base(regs, INAT_SEG_REG_CS);
@@ -155,4 +155,4 @@ void arch_unwind_user_init(struct unwind_user_state *state,
 	state->sp += ss_base;
 	state->fp += ss_base;
 }
-#endif /* CONFIG_IA32_EMULATION */
+#endif /* CONFIG_COMPAT */
diff --git a/include/linux/unwind_user.h b/include/linux/unwind_user.h
index 8a4af0214ecb..0308adb349fc 100644
--- a/include/linux/unwind_user.h
+++ b/include/linux/unwind_user.h
@@ -5,15 +5,6 @@
 #include <linux/unwind_user_types.h>
 #include <asm/unwind_user.h>
 
-#ifndef ARCH_INIT_USER_FP_FRAME
- #define ARCH_INIT_USER_FP_FRAME
-#endif
-
-#ifndef ARCH_INIT_USER_COMPAT_FP_FRAME
- #define ARCH_INIT_USER_COMPAT_FP_FRAME
- #define in_compat_mode(regs) false
-#endif
-
 /*
  * If an architecture needs to initialize the state for a specific
  * reason, for example, it may need to do something different
diff --git a/include/linux/unwind_user_types.h b/include/linux/unwind_user_types.h
index 4d50476e950e..fc440ae3a29b 100644
--- a/include/linux/unwind_user_types.h
+++ b/include/linux/unwind_user_types.h
@@ -9,11 +9,23 @@
 struct arch_unwind_user_state {};
 #endif
 
+
+/*
+ * unwind types, listed in priority order: lower numbers are attempted first if
+ * available.
+ */
+enum unwind_user_type_bits {
+	UNWIND_USER_TYPE_SFRAME_BIT =		0,
+	UNWIND_USER_TYPE_FP_BIT =		1,
+
+	_NR_UNWIND_USER_TYPE_BITS,
+};
+
 enum unwind_user_type {
-	UNWIND_USER_TYPE_NONE,
-	UNWIND_USER_TYPE_FP,
-	UNWIND_USER_TYPE_COMPAT_FP,
-	UNWIND_USER_TYPE_SFRAME,
+	/* Type "none" for the start of stack walk iteration. */
+	UNWIND_USER_TYPE_NONE =			0,
+	UNWIND_USER_TYPE_SFRAME =		(1U << UNWIND_USER_TYPE_SFRAME_BIT),
+	UNWIND_USER_TYPE_FP =			(1U << UNWIND_USER_TYPE_FP_BIT),
 };
 
 struct unwind_stacktrace {
@@ -33,7 +45,10 @@ struct unwind_user_state {
 	unsigned long sp;
 	unsigned long fp;
 	struct arch_unwind_user_state arch;
-	enum unwind_user_type type;
+	/* Unwind time used for the most recent unwind traversal iteration. */
+	enum unwind_user_type current_type;
+	/* Unwind types available in the current context. Bitmask of enum unwind_user_type. */
+	unsigned int available_types;
 	bool done;
 };
 
diff --git a/kernel/unwind/user.c b/kernel/unwind/user.c
index 6e7ca9f1293a..349bdd72390b 100644
--- a/kernel/unwind/user.c
+++ b/kernel/unwind/user.c
@@ -8,75 +8,48 @@
 #include <linux/unwind_user.h>
 #include <linux/uaccess.h>
 #include <linux/sframe.h>
+#include <linux/compat.h>
 
 static struct unwind_user_frame fp_frame = {
 	ARCH_INIT_USER_FP_FRAME
 };
 
+#ifdef CONFIG_COMPAT
 static struct unwind_user_frame compat_fp_frame = {
 	ARCH_INIT_USER_COMPAT_FP_FRAME
 };
+#endif
 
-static inline bool fp_state(struct unwind_user_state *state)
+static struct unwind_user_frame *get_fp_frame(void)
 {
-	return IS_ENABLED(CONFIG_HAVE_UNWIND_USER_FP) &&
-	       state->type == UNWIND_USER_TYPE_FP;
+#ifdef CONFIG_COMPAT
+	if (in_compat_syscall())
+		return &compat_fp_frame;
+#endif
+	return &fp_frame;
 }
 
 #define for_each_user_frame(state) \
 	for (unwind_user_start(state); !(state)->done; unwind_user_next(state))
 
-static inline bool compat_fp_state(struct unwind_user_state *state)
-{
-	return IS_ENABLED(CONFIG_HAVE_UNWIND_USER_COMPAT_FP) &&
-	       state->type == UNWIND_USER_TYPE_COMPAT_FP;
-}
-
-static inline bool sframe_state(struct unwind_user_state *state)
-{
-	return IS_ENABLED(CONFIG_HAVE_UNWIND_USER_SFRAME) &&
-	       state->type == UNWIND_USER_TYPE_SFRAME;
-}
-
-#define unwind_get_user_long(to, from, state)				\
+#define unwind_get_user_long(to, from)					\
 ({									\
 	int __ret;							\
-	if (compat_fp_state(state))					\
+	if (in_compat_syscall())					\
 		__ret = get_user(to, (u32 __user *)(from));		\
 	else								\
 		__ret = get_user(to, (unsigned long __user *)(from));	\
 	__ret;								\
 })
 
-static int unwind_user_next(struct unwind_user_state *state)
+static int unwind_user_next_common(struct unwind_user_state *state, struct unwind_user_frame *frame)
 {
-	struct unwind_user_frame *frame;
-	struct unwind_user_frame _frame;
-	unsigned long cfa = 0, fp, ra = 0;
+	unsigned long cfa, fp, ra = 0;
 	unsigned int shift;
 
-	if (state->done)
-		return -EINVAL;
-
-	if (compat_fp_state(state)) {
-		frame = &compat_fp_frame;
-	} else if (sframe_state(state)) {
-		/* sframe expects the frame to be local storage */
-		frame = &_frame;
-		if (sframe_find(state->ip, frame)) {
-			if (!IS_ENABLED(CONFIG_HAVE_UNWIND_USER_FP))
-				goto done;
-			frame = &fp_frame;
-		}
-	} else if (fp_state(state)) {
-		frame = &fp_frame;
-	} else {
-		goto done;
-	}
-
 	if (frame->use_fp) {
 		if (state->fp < state->sp)
-			goto done;
+			return -EINVAL;
 		cfa = state->fp;
 	} else {
 		cfa = state->sp;
@@ -87,30 +60,84 @@ static int unwind_user_next(struct unwind_user_state *state)
 
 	/* stack going in wrong direction? */
 	if (cfa <= state->sp)
-		goto done;
+		return -EINVAL;
 
 	/* Make sure that the address is word aligned */
-	shift = sizeof(long) == 4 || compat_fp_state(state) ? 2 : 3;
+	shift = (sizeof(long) == 4 || in_compat_syscall()) ? 2 : 3;
 	if ((cfa + frame->ra_off) & ((1 << shift) - 1))
-		goto done;
+		return -EINVAL;
 
 	/* Find the Return Address (RA) */
-	if (unwind_get_user_long(ra, cfa + frame->ra_off, state))
-		goto done;
+	if (unwind_get_user_long(ra, cfa + frame->ra_off))
+		return -EINVAL;
 
-	if (frame->fp_off && unwind_get_user_long(fp, cfa + frame->fp_off, state))
-		goto done;
+	if (frame->fp_off && unwind_get_user_long(fp, cfa + frame->fp_off))
+		return -EINVAL;
 
 	state->ip = ra;
 	state->sp = cfa;
 	if (frame->fp_off)
 		state->fp = fp;
+	return 0;
+}
 
-	arch_unwind_user_next(state);
+static int unwind_user_next_sframe(struct unwind_user_state *state)
+{
+	struct unwind_user_frame _frame, *frame;
+
+	/* sframe expects the frame to be local storage */
+	frame = &_frame;
+	if (sframe_find(state->ip, frame))
+		return -ENOENT;
+	return unwind_user_next_common(state, frame);
+}
 
+static int unwind_user_next_fp(struct unwind_user_state *state)
+{
+	return unwind_user_next_common(state, get_fp_frame());
+}
+
+static int unwind_user_next(struct unwind_user_state *state)
+{
+	unsigned long iter_mask = state->available_types;
+	unsigned int bit;
+
+	if (state->done)
+		return -EINVAL;
+
+	for_each_set_bit(bit, &iter_mask, _NR_UNWIND_USER_TYPE_BITS) {
+		enum unwind_user_type type = 1U << bit;
+
+		state->current_type = type;
+		switch (type) {
+		case UNWIND_USER_TYPE_SFRAME:
+			switch (unwind_user_next_sframe(state)) {
+			case 0:
+				goto end;
+			case -ENOENT:
+				continue;	/* Try next method. */
+			default:
+				goto done;
+			}
+		case UNWIND_USER_TYPE_FP:
+			if (!unwind_user_next_fp(state))
+				goto end;
+			else
+				goto done;
+		case UNWIND_USER_TYPE_NONE:
+			break;
+		}
+	}
+
+	/* No successful unwind method. */
+	goto done;
+
+end:
+	arch_unwind_user_next(state);
 	return 0;
 
 done:
+	state->current_type = UNWIND_USER_TYPE_NONE;
 	state->done = true;
 	return -EINVAL;
 }
@@ -126,14 +153,10 @@ static int unwind_user_start(struct unwind_user_state *state)
 		return -EINVAL;
 	}
 
-	if (IS_ENABLED(CONFIG_HAVE_UNWIND_USER_COMPAT_FP) && in_compat_mode(regs))
-		state->type = UNWIND_USER_TYPE_COMPAT_FP;
-	else if (current_has_sframe())
-		state->type = UNWIND_USER_TYPE_SFRAME;
-	else if (IS_ENABLED(CONFIG_HAVE_UNWIND_USER_FP))
-		state->type = UNWIND_USER_TYPE_FP;
-	else
-		state->type = UNWIND_USER_TYPE_NONE;
+	if (current_has_sframe())
+		state->available_types |= UNWIND_USER_TYPE_SFRAME;
+	if (IS_ENABLED(CONFIG_HAVE_UNWIND_USER_FP))
+		state->available_types |= UNWIND_USER_TYPE_FP;
 
 	state->ip = instruction_pointer(regs);
 	state->sp = user_stack_pointer(regs);
-- 
2.43.0

[RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Mathieu Desnoyers]

Allow the unwind_user symbol to be used by GPL modules, for instance
LTTng.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Indu Bhagat <indu.bhagat@oracle.com>
Cc: "Jose E. Marchesi" <jemarch@gnu.org>
Cc: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Jens Remus <jremus@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 kernel/unwind/user.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/unwind/user.c b/kernel/unwind/user.c
index 349bdd72390b..9aefbfc8427a 100644
--- a/kernel/unwind/user.c
+++ b/kernel/unwind/user.c
@@ -187,3 +187,4 @@ int unwind_user(struct unwind_stacktrace *trace, unsigned int max_entries)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(unwind_user);
-- 
2.43.0

[RFC PATCH 3/5] unwind deferred: Introduce unwind_user_trace_cached

[Mathieu Desnoyers]

Introduce unwind_user_trace_cached which copies the stack trace if it
was previously stored into the cache since the last reset of the cache.

The expected use-case is sampling a stack trace from a faultable context
at system call entry (coping it into the cache), and then copying the
stack trace from the cache from non-faultable context to a ring buffer.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Indu Bhagat <indu.bhagat@oracle.com>
Cc: "Jose E. Marchesi" <jemarch@gnu.org>
Cc: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Jens Remus <jremus@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/unwind_deferred.h |  2 ++
 kernel/unwind/deferred.c        | 31 +++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)

diff --git a/include/linux/unwind_deferred.h b/include/linux/unwind_deferred.h
index a9d5b100d6b2..ddc985ba982a 100644
--- a/include/linux/unwind_deferred.h
+++ b/include/linux/unwind_deferred.h
@@ -34,6 +34,7 @@ void unwind_task_init(struct task_struct *task);
 void unwind_task_free(struct task_struct *task);
 
 int unwind_user_faultable(struct unwind_stacktrace *trace);
+int unwind_user_trace_cached(struct unwind_stacktrace *trace);
 
 int unwind_deferred_init(struct unwind_work *work, unwind_callback_t func);
 int unwind_deferred_request(struct unwind_work *work, u64 *cookie);
@@ -67,6 +68,7 @@ static inline void unwind_task_init(struct task_struct *task) {}
 static inline void unwind_task_free(struct task_struct *task) {}
 
 static inline int unwind_user_faultable(struct unwind_stacktrace *trace) { return -ENOSYS; }
+static inline int unwind_user_trace_cached(struct unwind_stacktrace *trace) { return -ENOSYS; }
 static inline int unwind_deferred_init(struct unwind_work *work, unwind_callback_t func) { return -ENOSYS; }
 static inline int unwind_deferred_request(struct unwind_work *work, u64 *timestamp) { return -ENOSYS; }
 static inline void unwind_deferred_cancel(struct unwind_work *work) {}
diff --git a/kernel/unwind/deferred.c b/kernel/unwind/deferred.c
index 039e12700d49..02ab1d2afc21 100644
--- a/kernel/unwind/deferred.c
+++ b/kernel/unwind/deferred.c
@@ -145,6 +145,37 @@ int unwind_user_faultable(struct unwind_stacktrace *trace)
 
 	return 0;
 }
+EXPORT_SYMBOL_GPL(unwind_user_faultable);
+
+/**
+ * unwind_user_trace_cached - Copy user stack trace from cache
+ * @trace: The descriptor that will store the user stacktrace
+ *
+ * Copy user stack trace from cache if the cache was populated by
+ * unwind_user_faultable prior to this call. The returned trace
+ * entries are only valid until the cache is reset.
+ *
+ * Return: 0 on success and negative on error
+ *         On success @trace will contain the user space stacktrace
+ */
+int unwind_user_trace_cached(struct unwind_stacktrace *trace)
+{
+	struct unwind_task_info *info = &current->unwind_info;
+	struct unwind_cache *cache;
+
+	if (!current->mm)
+		return -EINVAL;
+
+	cache = info->cache;
+	if (!cache || !cache->nr_entries)
+		return -ENOENT;
+
+	trace->nr = cache->nr_entries;
+	trace->entries = cache->entries;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(unwind_user_trace_cached);
 
 static void process_unwind_deferred(struct task_struct *task)
 {
-- 
2.43.0

[RFC PATCH 4/5] unwind: Rename unwind_stacktrace to unwind_user_stacktrace

[Mathieu Desnoyers]

Rename the unwind_stacktrace structure to unwind_user_stacktrace to make
it consistent with the rest of the API.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Indu Bhagat <indu.bhagat@oracle.com>
Cc: "Jose E. Marchesi" <jemarch@gnu.org>
Cc: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Jens Remus <jremus@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/unwind_deferred.h   | 10 +++++-----
 include/linux/unwind_user.h       |  2 +-
 include/linux/unwind_user_types.h |  2 +-
 kernel/unwind/deferred.c          |  6 +++---
 kernel/unwind/user.c              |  2 +-
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/linux/unwind_deferred.h b/include/linux/unwind_deferred.h
index ddc985ba982a..62f1faf5f2b8 100644
--- a/include/linux/unwind_deferred.h
+++ b/include/linux/unwind_deferred.h
@@ -8,7 +8,7 @@
 
 struct unwind_work;
 
-typedef void (*unwind_callback_t)(struct unwind_work *work, struct unwind_stacktrace *trace, u64 cookie);
+typedef void (*unwind_callback_t)(struct unwind_work *work, struct unwind_user_stacktrace *trace, u64 cookie);
 
 struct unwind_work {
 	struct list_head		list;
@@ -33,8 +33,8 @@ enum {
 void unwind_task_init(struct task_struct *task);
 void unwind_task_free(struct task_struct *task);
 
-int unwind_user_faultable(struct unwind_stacktrace *trace);
-int unwind_user_trace_cached(struct unwind_stacktrace *trace);
+int unwind_user_faultable(struct unwind_user_stacktrace *trace);
+int unwind_user_trace_cached(struct unwind_user_stacktrace *trace);
 
 int unwind_deferred_init(struct unwind_work *work, unwind_callback_t func);
 int unwind_deferred_request(struct unwind_work *work, u64 *cookie);
@@ -67,8 +67,8 @@ static __always_inline void unwind_reset_info(void)
 static inline void unwind_task_init(struct task_struct *task) {}
 static inline void unwind_task_free(struct task_struct *task) {}
 
-static inline int unwind_user_faultable(struct unwind_stacktrace *trace) { return -ENOSYS; }
-static inline int unwind_user_trace_cached(struct unwind_stacktrace *trace) { return -ENOSYS; }
+static inline int unwind_user_faultable(struct unwind_user_stacktrace *trace) { return -ENOSYS; }
+static inline int unwind_user_trace_cached(struct unwind_user_stacktrace *trace) { return -ENOSYS; }
 static inline int unwind_deferred_init(struct unwind_work *work, unwind_callback_t func) { return -ENOSYS; }
 static inline int unwind_deferred_request(struct unwind_work *work, u64 *timestamp) { return -ENOSYS; }
 static inline void unwind_deferred_cancel(struct unwind_work *work) {}
diff --git a/include/linux/unwind_user.h b/include/linux/unwind_user.h
index 0308adb349fc..6022c77518f3 100644
--- a/include/linux/unwind_user.h
+++ b/include/linux/unwind_user.h
@@ -25,6 +25,6 @@ static inline void arch_unwind_user_init(struct unwind_user_state *state, struct
 static inline void arch_unwind_user_next(struct unwind_user_state *state) {}
 #endif
 
-int unwind_user(struct unwind_stacktrace *trace, unsigned int max_entries);
+int unwind_user(struct unwind_user_stacktrace *trace, unsigned int max_entries);
 
 #endif /* _LINUX_UNWIND_USER_H */
diff --git a/include/linux/unwind_user_types.h b/include/linux/unwind_user_types.h
index fc440ae3a29b..860f84cd7998 100644
--- a/include/linux/unwind_user_types.h
+++ b/include/linux/unwind_user_types.h
@@ -28,7 +28,7 @@ enum unwind_user_type {
 	UNWIND_USER_TYPE_FP =			(1U << UNWIND_USER_TYPE_FP_BIT),
 };
 
-struct unwind_stacktrace {
+struct unwind_user_stacktrace {
 	unsigned int	nr;
 	unsigned long	*entries;
 };
diff --git a/kernel/unwind/deferred.c b/kernel/unwind/deferred.c
index 02ab1d2afc21..4006d253c793 100644
--- a/kernel/unwind/deferred.c
+++ b/kernel/unwind/deferred.c
@@ -105,7 +105,7 @@ static u64 get_cookie(struct unwind_task_info *info)
  * Return: 0 on success and negative on error
  *         On success @trace will contain the user space stacktrace
  */
-int unwind_user_faultable(struct unwind_stacktrace *trace)
+int unwind_user_faultable(struct unwind_user_stacktrace *trace)
 {
 	struct unwind_task_info *info = &current->unwind_info;
 	struct unwind_cache *cache;
@@ -158,7 +158,7 @@ EXPORT_SYMBOL_GPL(unwind_user_faultable);
  * Return: 0 on success and negative on error
  *         On success @trace will contain the user space stacktrace
  */
-int unwind_user_trace_cached(struct unwind_stacktrace *trace)
+int unwind_user_trace_cached(struct unwind_user_stacktrace *trace)
 {
 	struct unwind_task_info *info = &current->unwind_info;
 	struct unwind_cache *cache;
@@ -180,7 +180,7 @@ EXPORT_SYMBOL_GPL(unwind_user_trace_cached);
 static void process_unwind_deferred(struct task_struct *task)
 {
 	struct unwind_task_info *info = &task->unwind_info;
-	struct unwind_stacktrace trace;
+	struct unwind_user_stacktrace trace;
 	struct unwind_work *work;
 	unsigned long bits;
 	u64 cookie;
diff --git a/kernel/unwind/user.c b/kernel/unwind/user.c
index 9aefbfc8427a..dfe7bf50d8f6 100644
--- a/kernel/unwind/user.c
+++ b/kernel/unwind/user.c
@@ -167,7 +167,7 @@ static int unwind_user_start(struct unwind_user_state *state)
 	return 0;
 }
 
-int unwind_user(struct unwind_stacktrace *trace, unsigned int max_entries)
+int unwind_user(struct unwind_user_stacktrace *trace, unsigned int max_entries)
 {
 	struct unwind_user_state state;
 
-- 
2.43.0

[RFC PATCH 5/5] unwind: Introduce unwind user entry type

[Mathieu Desnoyers]

Introduce a unwind user entry type to allow unwind iterator users to
know which method was used to obtain each of the stack frames.

This allows iterator users to know whether they can trust the
information provided by the stack trace. For instance, on a system with
binaries built with frame pointers omitted, the stack frames fetched
using the frame pointer method should be considered unreliable, whereas
those fetched using sframe should be reliable.

Note that the "none" entry type denotes the first address (start of
iteration), which is present in the pt_regs, and therefore is always
reliable.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Indu Bhagat <indu.bhagat@oracle.com>
Cc: "Jose E. Marchesi" <jemarch@gnu.org>
Cc: Beau Belgrave <beaub@linux.microsoft.com>
Cc: Jens Remus <jremus@linux.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 include/linux/unwind_deferred_types.h | 6 ++++--
 include/linux/unwind_user_types.h     | 9 +++++++--
 kernel/unwind/user.c                  | 7 +++++--
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/include/linux/unwind_deferred_types.h b/include/linux/unwind_deferred_types.h
index db6c65daf185..ef9818456fd5 100644
--- a/include/linux/unwind_deferred_types.h
+++ b/include/linux/unwind_deferred_types.h
@@ -2,9 +2,11 @@
 #ifndef _LINUX_UNWIND_USER_DEFERRED_TYPES_H
 #define _LINUX_UNWIND_USER_DEFERRED_TYPES_H
 
+#include <linux/unwind_user_types.h>
+
 struct unwind_cache {
-	unsigned int		nr_entries;
-	unsigned long		entries[];
+	unsigned int			nr_entries;
+	struct unwind_user_entry	entries[];
 };
 
 
diff --git a/include/linux/unwind_user_types.h b/include/linux/unwind_user_types.h
index 860f84cd7998..ab29c419099c 100644
--- a/include/linux/unwind_user_types.h
+++ b/include/linux/unwind_user_types.h
@@ -28,9 +28,14 @@ enum unwind_user_type {
 	UNWIND_USER_TYPE_FP =			(1U << UNWIND_USER_TYPE_FP_BIT),
 };
 
+struct unwind_user_entry {
+	enum unwind_user_type type;
+	unsigned long ip;
+};
+
 struct unwind_user_stacktrace {
-	unsigned int	nr;
-	unsigned long	*entries;
+	unsigned int nr;
+	struct unwind_user_entry *entries;
 };
 
 struct unwind_user_frame {
diff --git a/kernel/unwind/user.c b/kernel/unwind/user.c
index dfe7bf50d8f6..9a88fe757327 100644
--- a/kernel/unwind/user.c
+++ b/kernel/unwind/user.c
@@ -180,8 +180,11 @@ int unwind_user(struct unwind_user_stacktrace *trace, unsigned int max_entries)
 		return 0;
 
 	for_each_user_frame(&state) {
-		trace->entries[trace->nr++] = state.ip;
-		if (trace->nr >= max_entries)
+		unsigned int i = trace->nr++;
+
+		trace->entries[i].type = state.current_type;
+		trace->entries[i].ip = state.ip;
+		if (i >= max_entries)
 			break;
 	}
 
-- 
2.43.0

Re: [RFC PATCH 4/5] unwind: Rename unwind_stacktrace to unwind_user_stacktrace

[Steven Rostedt]

On Wed,  9 Jul 2025 17:25:51 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> Rename the unwind_stacktrace structure to unwind_user_stacktrace to make
> it consistent with the rest of the API.

We originally had that name, but decided it was too long. As only the
deferred unwind uses "unwind_" and it is currently only for user space, do
we really need to have a 22 character structure name? 17 is already big
enough.

And say we make an unwind_kernel_stacktrace()? I doubt we ever would, but
if we did, it would still use the same structure. There's nothing
inherently user space here (with maybe the exception of the compat type,
but still).

And how is this unique to user space? The kernel can have sframes too.

Actually, I think we should rename "enum unwind_user_type" to
"enum unwind_type".

struct unwind_entry {
	enum unwind_type	type;
	unsigned long		ip;
};

As it is only being used for user space now, but it doesn't mean it can't
be used for the kernel.

Heck, there's already work to use sframes in kernel code to replace ORC so
that architectures like ARM64 can have live kernel patching.

-- Steve

Re: [RFC PATCH 4/5] unwind: Rename unwind_stacktrace to unwind_user_stacktrace

[Steven Rostedt]

On Wed, 9 Jul 2025 17:41:39 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Wed,  9 Jul 2025 17:25:51 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
> > Rename the unwind_stacktrace structure to unwind_user_stacktrace to make
> > it consistent with the rest of the API.  
> 
> We originally had that name, but decided it was too long. As only the
> deferred unwind uses "unwind_" and it is currently only for user space, do
> we really need to have a 22 character structure name? 17 is already big
> enough.
> 
> And say we make an unwind_kernel_stacktrace()? I doubt we ever would, but
> if we did, it would still use the same structure. There's nothing
> inherently user space here (with maybe the exception of the compat type,
> but still).
> 
> And how is this unique to user space? The kernel can have sframes too.
> 
> Actually, I think we should rename "enum unwind_user_type" to
> "enum unwind_type".
> 
> struct unwind_entry {
> 	enum unwind_type	type;
> 	unsigned long		ip;
> };
> 
> As it is only being used for user space now, but it doesn't mean it can't
> be used for the kernel.
> 
> Heck, there's already work to use sframes in kernel code to replace ORC so
> that architectures like ARM64 can have live kernel patching.

Actually, I'm going to leave everything as is. The "struct unwind_user_*"
is only used internally in the user code and is not part of the API of
the infrastructure. The "struct unwind_stackframe" is used in the API
as a parameter. To me, it makes more sense to keep it short than adding
"user" to it and making all the callbacks have a longer name.

I know your patch 5 exposes more, but we'll deal with that when the
time comes.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Christoph Hellwig]

On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote:
> Allow the unwind_user symbol to be used by GPL modules, for instance
> LTTng.

I don't see a LTTng submission or any other user in this series.
So the usual prohibition against adding unused exports applies here
as usual.

Re: [RFC PATCH 3/5] unwind deferred: Introduce unwind_user_trace_cached

[Christoph Hellwig]

On Wed, Jul 09, 2025 at 05:25:50PM -0400, Mathieu Desnoyers wrote:
> Introduce unwind_user_trace_cached which copies the stack trace if it
> was previously stored into the cache since the last reset of the cache.
> 
> The expected use-case is sampling a stack trace from a faultable context
> at system call entry (coping it into the cache), and then copying the
> stack trace from the cache from non-faultable context to a ring buffer.

Why is this and the following patches adding unused code?

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

[ Adding the TAB to this as well ]

On Fri, 11 Jul 2025 00:36:28 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote:
> > Allow the unwind_user symbol to be used by GPL modules, for instance
> > LTTng.  
> 
> I don't see a LTTng submission or any other user in this series.
> So the usual prohibition against adding unused exports applies here
> as usual.

I want to bring up this discussion. I understand there's a policy not to
add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
proper. My question is, does this policy have to be draconian?

The LTTng project and specifically its maintainer Mathieu has a long
history of working along side of the Linux kernel and actively adding
enhancements to the code. This is not an Nvidia or VMware situation where
the modules add special secret sauce that they do not want to share. This
is a long standing kernel contributor and maintainer that has proved
himself time and time again to be an asset to the Linux kernel community.

It's not even that LTTng wants to be out of tree. There's been several
attempts to get LTTng merged. But they all failed due to disagreements in
approaches and other aspects of the design. With perf and ftrace already in
the kernel which focus toward helping kernel developers debug their issue,
several maintainers do not see the point of LTTng. But LTTng focuses more
on non kernel developers. Mathieu and I have come to a conclusion that
LTTng and ftrace have two different audiences. And we actively work with
each other to improve both ftrace and LTTng.

LTTng was redesigned to work as a very non-intrusive external kernel module
that could be ported to newer kernels without much pain. This approach has
worked for both Mathieu and the kernel maintainers for several years.

It is not because Mathieu doesn't want LTTng in the kernel that is keeping
it out of the tree. He would very much like it in-tree! LTTng is not in the
kernel because the kernel maintainers themselves have been blocking it. I
do not feel that we should be also add the extra burden to prevent any call
it could use from being EXPORT_SYMBOL_GPL().

Mathieu has been very helpful in the work to develop this deferred unwind
code that will help ftrace, perf and BPF. I would also like it to help
LTTng. The only way to do so is to have an EXPORT_SYMBOL_GPL() for it.

Now you can argue that we need to get LTTng into mainline before it can use
this new work that the maintainer of LTTng has been very involved in to
develop. But that would probably take a long time and from past
experiences, may fail completely. So for now, I am saying that we give
LTTng an exception to the rule that functions can not be
EXPORT_SYMBOL_GPL() unless there's a in-tree kernel module that requires it.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Greg KH]

On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> 
> [ Adding the TAB to this as well ]
> 
> On Fri, 11 Jul 2025 00:36:28 -0700
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote:
> > > Allow the unwind_user symbol to be used by GPL modules, for instance
> > > LTTng.  
> > 
> > I don't see a LTTng submission or any other user in this series.
> > So the usual prohibition against adding unused exports applies here
> > as usual.
> 
> I want to bring up this discussion. I understand there's a policy not to
> add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
> proper. My question is, does this policy have to be draconian?

It's not "draconian", it is "we do not add exports for stuff that is
not in our kernel tree."  Simple, direct, and obvious.  We have no idea
how, or if, external modules do anything with apis that we export and do
not use internally, so we can't change them without breaking anything,
so it's simpler and more obvious to not even attempt to care about them.

If external users want to use a symbol, they should get merged into the
tree.

Yes, lttng is a "good citizen" of the kernel community, and yes, it's
not merged into the tree, but that's not our issue, and living outside
of the tree has it's penalities, both economic and technical.  This is
one of those penalities, sorry.

So no, we shouldn't change this at all.  And I think we need to start
doing more of the "only export this symbol for this subsystem/module"
trimming as well.  I see the horrors that out-of-tree kernel code does
and by removing the ability of them to even get access to the things
they do have access to today, would be good for everyone involved (i.e.
our community, AND the users of Linux to allow them to have a more
stable and trustworthy base to rely on.)

thanks,

greg k-h

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Fri, 11 Jul 2025 13:38:07 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> > 
> > [ Adding the TAB to this as well ]
> > 
> > On Fri, 11 Jul 2025 00:36:28 -0700
> > Christoph Hellwig <hch@infradead.org> wrote:
> >   
> > > On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote:  
> > > > Allow the unwind_user symbol to be used by GPL modules, for instance
> > > > LTTng.    
> > > 
> > > I don't see a LTTng submission or any other user in this series.
> > > So the usual prohibition against adding unused exports applies here
> > > as usual.  
> > 
> > I want to bring up this discussion. I understand there's a policy not to
> > add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
> > proper. My question is, does this policy have to be draconian?  
> 
> It's not "draconian", it is "we do not add exports for stuff that is
> not in our kernel tree."  Simple, direct, and obvious.  We have no idea
> how, or if, external modules do anything with apis that we export and do
> not use internally, so we can't change them without breaking anything,
> so it's simpler and more obvious to not even attempt to care about them.

Let me clear up a misunderstanding on my part. That is, this *will* be used
internally when an EXPORT_SYMBOL_GPL() is added to it. Ftrace, perf and
probably BPF will be using the function. But all of these are not modules,
but the only one that is a module would be LTTng, and it is adaptable to
change. Just like a BPF program would be.

I mean, if I made a part of ftrace into a loadable module that used this
feature, then we could make this EXPORT_SYMBOL_GPL()?

> 
> If external users want to use a symbol, they should get merged into the
> tree.
> 
> Yes, lttng is a "good citizen" of the kernel community, and yes, it's
> not merged into the tree, but that's not our issue, and living outside
> of the tree has it's penalities, both economic and technical.  This is
> one of those penalities, sorry.

But it is our issue. We are the ones keeping it out. We can try to get it
in again, but it will be a long and tedious process. Mathieu is at a
disadvantage here because he has no leverage as most of his customers are
non-kernel developers. So the decisions he makes is for them, not us. And
this has caused tension when it came to the way he did things compared to
what we wanted. His keeping it out of tree has worked so far. And now he's
been an active contributor on a new feature that will benefit perf, ftrace
and BPF but because we've been keeping him out of tree, he doesn't get to
use the work he's contributed to?

> 
> So no, we shouldn't change this at all.  And I think we need to start
> doing more of the "only export this symbol for this subsystem/module"
> trimming as well.  I see the horrors that out-of-tree kernel code does
> and by removing the ability of them to even get access to the things
> they do have access to today, would be good for everyone involved (i.e.
> our community, AND the users of Linux to allow them to have a more
> stable and trustworthy base to rely on.)

Yes, but you mostly see drivers and side functions that really do nothing
for the kernel. LTTng has contributed tracepoints, several RCU
enhancements, restartable sequences and more.

The user stack unwinding that we are adding is a new feature to do stack
unwinding without frame pointers that Fedora is working on adding. There's
two functions that LTTng would need to get this, and both will be used by
ftrace and perf. It only gives the module a user stack unwind. It's
information only and not something that tweaks the kernel in any way.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Fri, 11 Jul 2025 13:38:07 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> Yes, lttng is a "good citizen" of the kernel community, and yes, it's
> not merged into the tree, but that's not our issue, and living outside
> of the tree has it's penalities, both economic and technical.  This is
> one of those penalities, sorry.

BTW, when it comes to tracers, being out of tree is actually a huge
advantage. Tracers, unlike drivers, are only monitoring the kernel. Which
means it doesn't really rely on the workings of the kernel, so it really
doesn't get much help from changes made by other kernel developers. Like
the BPF folks have said keeping BPF programs up to date, isn't that much of
a burden.

The huge advantage that LTTng has over perf and ftrace for being out of
tree is that it controls the ABI between the LTTng kernel side and the user
space side. LTTng can experiment with new interfaces, and if something
breaks, it can simply change it and deliver a new tool that includes the
new module with the update.

One thing that perf and ftrace struggle with is getting the API correct the
first time. That's because they have no control over what other tools may use
their interface. If I expose something that another tool starts to use
(like powertop) and then I change it to enhance tracing and it breaks that
tool, that change gets reverted. To make any new update, I have to guess at
what are all the ways a tool could abuse this interface and also make sure
it works well into the future when new things come up. There's a lot of
interfaces I would love to change but can't, simply because they are now
ABI.

LTTng doesn't have the burden of worrying about "what other tool may use
this kernel interface?", and can even change it much later if Mathieu finds
a better way to do it.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Mathieu Desnoyers]

On 2025-07-11 10:02, Steven Rostedt wrote:
> On Fri, 11 Jul 2025 13:38:07 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
>> Yes, lttng is a "good citizen" of the kernel community, and yes, it's
>> not merged into the tree, but that's not our issue, and living outside
>> of the tree has it's penalities, both economic and technical.  This is
>> one of those penalities, sorry.
> 
> BTW, when it comes to tracers, being out of tree is actually a huge
> advantage. Tracers, unlike drivers, are only monitoring the kernel. Which
> means it doesn't really rely on the workings of the kernel, so it really
> doesn't get much help from changes made by other kernel developers. Like
> the BPF folks have said keeping BPF programs up to date, isn't that much of
> a burden.
> 
> The huge advantage that LTTng has over perf and ftrace for being out of
> tree is that it controls the ABI between the LTTng kernel side and the user
> space side. LTTng can experiment with new interfaces, and if something
> breaks, it can simply change it and deliver a new tool that includes the
> new module with the update.
> 
> One thing that perf and ftrace struggle with is getting the API correct the
> first time. That's because they have no control over what other tools may use
> their interface. If I expose something that another tool starts to use
> (like powertop) and then I change it to enhance tracing and it breaks that
> tool, that change gets reverted. To make any new update, I have to guess at
> what are all the ways a tool could abuse this interface and also make sure
> it works well into the future when new things come up. There's a lot of
> interfaces I would love to change but can't, simply because they are now
> ABI.
> 
> LTTng doesn't have the burden of worrying about "what other tool may use
> this kernel interface?", and can even change it much later if Mathieu finds
> a better way to do it.

This is indeed one advantage LTTng has: it controls both the kernel
and userspace sides of the software.

I should point out however that since about LTTng 2.7 (2015) we've made
it a project policy to never break the LTTng-modules userspace ABI.
Those ABIs are effectively append-only (with possible gradual
deprecation) to make life easier for distro vendors for which the
userspace vs kernel modules packages are not in sync sometimes.
ABI-breaking changes to LTTng-modules makes packaging of kernel + OOT
modules + userspace tricky for distros. Similarly to the Linux kernel,
our "do not break userspace ABI" policy takes care of this.

So even though LTTng does not _break_ ABIs, it benefits from controlling
what userspace is allowed to interact with it. The fact that we have
an aligned release cycle across LTTng-Tools, the LTTng userspace tracer,
and the LTTng kernel tracer allows us to deprecate ABIs at a faster pace
than what typical kernel ABIs with arbitrary userspace consumers can do.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Greg KH]

On Fri, Jul 11, 2025 at 09:17:34AM -0400, Steven Rostedt wrote:
> On Fri, 11 Jul 2025 13:38:07 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> > > 
> > > [ Adding the TAB to this as well ]
> > > 
> > > On Fri, 11 Jul 2025 00:36:28 -0700
> > > Christoph Hellwig <hch@infradead.org> wrote:
> > >   
> > > > On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers wrote:  
> > > > > Allow the unwind_user symbol to be used by GPL modules, for instance
> > > > > LTTng.    
> > > > 
> > > > I don't see a LTTng submission or any other user in this series.
> > > > So the usual prohibition against adding unused exports applies here
> > > > as usual.  
> > > 
> > > I want to bring up this discussion. I understand there's a policy not to
> > > add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
> > > proper. My question is, does this policy have to be draconian?  
> > 
> > It's not "draconian", it is "we do not add exports for stuff that is
> > not in our kernel tree."  Simple, direct, and obvious.  We have no idea
> > how, or if, external modules do anything with apis that we export and do
> > not use internally, so we can't change them without breaking anything,
> > so it's simpler and more obvious to not even attempt to care about them.
> 
> Let me clear up a misunderstanding on my part. That is, this *will* be used
> internally when an EXPORT_SYMBOL_GPL() is added to it. Ftrace, perf and
> probably BPF will be using the function. But all of these are not modules,
> but the only one that is a module would be LTTng, and it is adaptable to
> change. Just like a BPF program would be.
> 
> I mean, if I made a part of ftrace into a loadable module that used this
> feature, then we could make this EXPORT_SYMBOL_GPL()?

Don't be silly, and don't attempt to "skirt the rules" like this.
Otherwise you will have a huge onflux of people/companies claiming that
they too deserve symbol exports for their long-out-of-tree-monstrosities
that they never worked to merge.

Again, let's keep the rule simple, exports are only for in-kernel users.

> > If external users want to use a symbol, they should get merged into the
> > tree.
> > 
> > Yes, lttng is a "good citizen" of the kernel community, and yes, it's
> > not merged into the tree, but that's not our issue, and living outside
> > of the tree has it's penalities, both economic and technical.  This is
> > one of those penalities, sorry.
> 
> But it is our issue. We are the ones keeping it out. We can try to get it
> in again, but it will be a long and tedious process. Mathieu is at a
> disadvantage here because he has no leverage as most of his customers are
> non-kernel developers. So the decisions he makes is for them, not us. And
> this has caused tension when it came to the way he did things compared to
> what we wanted. His keeping it out of tree has worked so far. And now he's
> been an active contributor on a new feature that will benefit perf, ftrace
> and BPF but because we've been keeping him out of tree, he doesn't get to
> use the work he's contributed to?

Sure he can, by virtue of it being in perf, ftrace, and bpf :)

Again, export stuff for in-tree users only.

> > So no, we shouldn't change this at all.  And I think we need to start
> > doing more of the "only export this symbol for this subsystem/module"
> > trimming as well.  I see the horrors that out-of-tree kernel code does
> > and by removing the ability of them to even get access to the things
> > they do have access to today, would be good for everyone involved (i.e.
> > our community, AND the users of Linux to allow them to have a more
> > stable and trustworthy base to rely on.)
> 
> Yes, but you mostly see drivers and side functions that really do nothing
> for the kernel. LTTng has contributed tracepoints, several RCU
> enhancements, restartable sequences and more.

Somehow those little drivers are "doing something" for the kernel by
virtue of you being able to use your keyboard and network card :)

Seriously, don't conflate tracing core code as some how being more
"important" than any existing driver in the tree, when both, in the end,
are necessary for a user to get their job done.  One could even say that
the tracing stuff is NOT needed, as if code works properly, no one
should be needing to use it...

Anyway, I see stuff all over the place, not just drivers, for "real"
things on a weekly basis.  Go poke in the Android kernel tree if you
want to see loads of examples of where vendors feel they can export/hook
into core parts of Linux just to get their work done.  I would argue
that most of them are NOT needed and are doing crazy things, but as
users have real hardware that sometimes requires it, it's a hard thing
to argue against.

I'll show one real-world example, the USB offload path code, that you
are using today on your Android phones that saves loads of battery life.
In older kernels, the hooks/exports needed for that were all over the
place, it took an engineer years to get this all working for lots of
different hardware types and merged upstream properly.  They knew that
they could not just get the upstream developers to export the needed
functions, they had to get their working code merged in order to be able
to have it happen.  And they did!

That was a non-trivial task, and while you might not feel it "does
nothing", the power savings you rely on daily would beg to differ.

So get the lttng code merged into the tree please, it seems that you are
the one objecting to the merge, not me :)

thanks,

greg k-h

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[James Bottomley]

On Fri, 2025-07-11 at 13:38 +0200, Greg KH wrote:
> On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> > 
> > [ Adding the TAB to this as well ]
> > 
> > On Fri, 11 Jul 2025 00:36:28 -0700
> > Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > > On Wed, Jul 09, 2025 at 05:25:49PM -0400, Mathieu Desnoyers
> > > wrote:
> > > > Allow the unwind_user symbol to be used by GPL modules, for
> > > > instance LTTng.  
> > > 
> > > I don't see a LTTng submission or any other user in this series.
> > > So the usual prohibition against adding unused exports applies
> > > here as usual.
> > 
> > I want to bring up this discussion. I understand there's a policy
> > not to add EXPORT_SYMBOL_GPL() unless there's a current user of it
> > in the kernel proper. My question is, does this policy have to be
> > draconian?
> 
> It's not "draconian", it is "we do not add exports for stuff that is
> not in our kernel tree."  Simple, direct, and obvious.  We have no
> idea how, or if, external modules do anything with apis that we
> export and do not use internally, so we can't change them without
> breaking anything, so it's simpler and more obvious to not even
> attempt to care about
> them.

Since the argument is still going on, I've got to say I agree with
Greg: it's not draconian it's a simple technical rule which is easily
enforceable and gets us out of making political decisions like what's a
"good" use of a symbol and what isn't.  Once we start making political
decisions about kernel symbol exports we open ourselves up to
accusations of partisanship and favouritism ... since we have a clear
technical criterion, it's just way easier not to descend that slippery
slope.

Regards,

James

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Fri, 11 Jul 2025 18:39:40 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> > Yes, but you mostly see drivers and side functions that really do nothing
> > for the kernel. LTTng has contributed tracepoints, several RCU
> > enhancements, restartable sequences and more.  
> 
> Somehow those little drivers are "doing something" for the kernel by
> virtue of you being able to use your keyboard and network card :)

I meant contributions to other parts of the kernel than just tracing.
This is more like PREEMPT_RT, where improvements to the core kernel was
made to help both LTTng and the kernel proper.

If you want to talk about precedent, we have it. raw_spin_lock() was
used *only* for PREEMPT_RT years before it was ever added to the kernel.

> 
> Seriously, don't conflate tracing core code as some how being more
> "important" than any existing driver in the tree, when both, in the end,
> are necessary for a user to get their job done.  One could even say that
> the tracing stuff is NOT needed, as if code works properly, no one
> should be needing to use it...

I'll even argue that this is fine for EXPORT_SYMBOL_GPL() because it
*isn't important*! I'm not saying it's more important. I'll agree with
you and say its less important. The point that the function I want to
export gives you information only and doesn't give you any operational
hooks into the kernel, means it's just a outside observer of the
system. It's not changing how the system works in any way.

I always tell people that tracing is a second class citizen when it
comes to the kernel. It should try it's damn best to not effect the
system it is trying to observe. If there's a decision to be made that
can improve tracing with the cost of hurting the system performance
when tracing is off, I'll make the decision not to do it. This is why
we have jump_label. To have nops when tracing is disabled and jmps when
it is, so that tracing doesn't affect normal operations. Not to mention
all the hacks done for function tracing to keep its overhead down to a
bare minimum.

> 
> Anyway, I see stuff all over the place, not just drivers, for "real"
> things on a weekly basis.  Go poke in the Android kernel tree if you
> want to see loads of examples of where vendors feel they can export/hook
> into core parts of Linux just to get their work done.  I would argue
> that most of them are NOT needed and are doing crazy things, but as
> users have real hardware that sometimes requires it, it's a hard thing
> to argue against.

I know you see real things. I think you misunderstood my comment. I
didn't mean to say what you see is anyway less than what happens in
core kernel. I find drivers are a key part of the kernel. The core
kernel is just a tool to have applications interact with the hardware,
and without drivers, the kernel is useless. My point was merely stating
that you and I have different view points of the kernel. I in no way
was saying mine was more important. In fact, I would say it's less
important.

> 
> I'll show one real-world example, the USB offload path code, that you
> are using today on your Android phones that saves loads of battery life.
> In older kernels, the hooks/exports needed for that were all over the
> place, it took an engineer years to get this all working for lots of
> different hardware types and merged upstream properly.  They knew that
> they could not just get the upstream developers to export the needed
> functions, they had to get their working code merged in order to be able
> to have it happen.  And they did!

I'm not sure how that is comparable? It sounds like they needed to
clean up a bunch of other code for other hardware so they could use
this feature.

The feature I'm talking about is fully available. It's just a way to
get a user space stack trace from the kernel. Nothing more. The work
being done is to make it generic so all the tracers could use it. All
that's upstream. The two functions I would like to export is "give me a
user space stack trace now" and "defer the user space stack trace
from NMI to when the task goes back to user space".

> 
> That was a non-trivial task, and while you might not feel it "does
> nothing", the power savings you rely on daily would beg to differ.
> 
> So get the lttng code merged into the tree please, it seems that you are
> the one objecting to the merge, not me :)

It was actually others, and it was years ago. Perhaps we could just
accept the LTTng kernel module as is, as a module, and leave it at that?

Then these functions would still have to be EXPORT_SYMBOL_GPL() but at
least it would be for an in-tree module.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[dan.j.williams]

Steven Rostedt wrote:
> On Fri, 11 Jul 2025 13:38:07 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > Yes, lttng is a "good citizen" of the kernel community, and yes, it's
> > not merged into the tree, but that's not our issue, and living outside
> > of the tree has it's penalities, both economic and technical.  This is
> > one of those penalities, sorry.
> 
> BTW, when it comes to tracers, being out of tree is actually a huge
> advantage. Tracers, unlike drivers, are only monitoring the kernel. Which
> means it doesn't really rely on the workings of the kernel, so it really
> doesn't get much help from changes made by other kernel developers. Like
> the BPF folks have said keeping BPF programs up to date, isn't that much of
> a burden.
> 
> The huge advantage that LTTng has over perf and ftrace for being out of
> tree is that it controls the ABI between the LTTng kernel side and the user
> space side. LTTng can experiment with new interfaces, and if something
> breaks, it can simply change it and deliver a new tool that includes the
> new module with the update.

It is odd to read this claimed benefit when viewing it from the wider
Linux kernel project. Upstream maintenance of ABI contracts is the
fundamental struggle of subsystems. The request, "can we get the kernel
out of the way and maintain our own ABI to our users?" is a consistent
refrain, and it consistently receives a qualified "no" for regression,
security, and other interface evolution concerns.

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Fri, 11 Jul 2025 11:10:06 -0700
<dan.j.williams@intel.com> wrote:

> > The huge advantage that LTTng has over perf and ftrace for being out of
> > tree is that it controls the ABI between the LTTng kernel side and the user
> > space side. LTTng can experiment with new interfaces, and if something
> > breaks, it can simply change it and deliver a new tool that includes the
> > new module with the update.  
> 
> It is odd to read this claimed benefit when viewing it from the wider
> Linux kernel project. Upstream maintenance of ABI contracts is the
> fundamental struggle of subsystems. The request, "can we get the kernel
> out of the way and maintain our own ABI to our users?" is a consistent
> refrain, and it consistently receives a qualified "no" for regression,
> security, and other interface evolution concerns.

Well I think the history matters a bit here. Mathieu tried to get LTTng
upstream several times. There was never a "Can I keep it out of tree so
I have this flexibility". Only after he gave up trying to get it
upstream, did this advantage play a role. There's been a few times
LTTng was able to take advantage of this "feature".

Note, as Mathieu has stated, LTTng now has a "stable ABI" similar to
what Linux has to make it easier for distributions to maintain LTTng.
But he also said that he can deprecate older interfaces much easier
than he would if it was upstream in Linux.

My comment wasn't to advocate such a approach, it was to counter Greg's
comment of "and living outside of the tree has it's penalities, both
economic and technical.

The main penalty that LTTng has being out of tree is the lack of access
to these functions. But it's been doing very well outside of that.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Greg KH]

On Fri, Jul 11, 2025 at 01:32:40PM -0400, Steven Rostedt wrote:
> > So get the lttng code merged into the tree please, it seems that you are
> > the one objecting to the merge, not me :)
> 
> It was actually others, and it was years ago. Perhaps we could just
> accept the LTTng kernel module as is, as a module, and leave it at that?

That's up to the maintainers of the subsystem where it would be, not me.

And that would solve this problem, so I do recommend it :)

thanks,

greg k-h

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Fri, 11 Jul 2025 20:24:37 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> On Fri, Jul 11, 2025 at 01:32:40PM -0400, Steven Rostedt wrote:
> > > So get the lttng code merged into the tree please, it seems that you are
> > > the one objecting to the merge, not me :)  
> > 
> > It was actually others, and it was years ago. Perhaps we could just
> > accept the LTTng kernel module as is, as a module, and leave it at that?  
> 
> That's up to the maintainers of the subsystem where it would be, not me.

It would likely be its own subsystem (under kernel/lttng?), so I guess
it would be Linus's decision.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Christoph Hellwig]

On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> I want to bring up this discussion. I understand there's a policy not to
> add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
> proper. My question is, does this policy have to be draconian?

Yes.  Making exception for friends and family is like Austrian law
enforcement and thus errodes the whole principle.  If you think lttng
is useful help ustreaming it.

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Christoph Hellwig]

On Fri, Jul 11, 2025 at 11:10:06AM -0700, dan.j.williams@intel.com wrote:
> It is odd to read this claimed benefit when viewing it from the wider
> Linux kernel project. Upstream maintenance of ABI contracts is the
> fundamental struggle of subsystems. The request, "can we get the kernel
> out of the way and maintain our own ABI to our users?" is a consistent
> refrain, and it consistently receives a qualified "no" for regression,
> security, and other interface evolution concerns.

Exactly.

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Sun, 13 Jul 2025 23:39:29 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Fri, Jul 11, 2025 at 06:57:42AM -0400, Steven Rostedt wrote:
> > I want to bring up this discussion. I understand there's a policy not to
> > add EXPORT_SYMBOL_GPL() unless there's a current user of it in the kernel
> > proper. My question is, does this policy have to be draconian?  
> 
> Yes.  Making exception for friends and family is like Austrian law

This has nothing to do with Mathieu being a friend. He's a long time Linux
kernel contributor and has played a key role in developing a new feature
that will help both perf and ftrace, but without the EXPORT_SYMBOL_GPL(),
LTTng can't use it. It's basically saying "thank you Mathieu for helping us
with this new feature, now go F*** off!"

> enforcement and thus errodes the whole principle.  If you think lttng
> is useful help ustreaming it.

That's the entire point. I have no stake in LTTng getting upstream. I just
sympathize with Mathieu as he has been very helpful in improving ftrace. To
me, open source software should work with each other.

Now, I would not block LTTng from getting upstream. I had a conversation
with Mathieu to discuss why it failed last time, and that's because we went
with the approach of trying to merge the features of ftrace and LTTng where
it made sense, and that became way more work than either of us had, and we
found no real benefit from it (besides getting LTTng upstream). It would
require at least 3 or 4 full months of manpower which I don't have time for.

From what Mathieu told me, LTTng's kernel module is 75K SLOC, with 20 years
of development. It already has its own ecosystem. The only practical way
for it to get upstream is if it were to become its own subsystem (like
kernel/lttng).

Who's going to review 75K of SLOC? I don't have the time to. The only
reason I would want LTTng in the kernel is to officially welcome Mathieu
into our community. Other than that, I have no need for LTTng.

What would you recommend Mathieu to do? He's been helping us for several
years and the work he does helps perf and ftrace and other parts of the
kernel (he's helped improve RCU). But to get LTTng upstream, it would take
a massive amount of work. And Mathieu has tried before without success. Why
should he spend all this time to break up the code into reviewable portions
without anyone willing to review it?

As I mentioned before, Mathieu is at a bit of a disadvantage. His customers
are non-kernel developers. But he needs the interest of kernel developers
to review his code. But he can't find anyone willing to do that. He doesn't
want to waste his time trying spending months of work to get LTTng upstream
if there's no guarantee that it will be accepted.

Would be willing to review his work?

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Christoph Hellwig]

On Mon, Jul 14, 2025 at 06:27:24AM -0400, Steven Rostedt wrote:
> This has nothing to do with Mathieu being a friend. He's a long time Linux
> kernel contributor and has played a key role in developing a new feature
> that will help both perf and ftrace, but without the EXPORT_SYMBOL_GPL(),
> LTTng can't use it. It's basically saying "thank you Mathieu for helping us
> with this new feature, now go F*** off!"

You don't have to be as explicit, but otherwise that's exactly how
it works.  No one gets a free ride just because they are nice and/or
contributed something.

The rest of your mail looks just as confused.

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Mon, 14 Jul 2025 04:38:33 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jul 14, 2025 at 06:27:24AM -0400, Steven Rostedt wrote:
> > This has nothing to do with Mathieu being a friend. He's a long time Linux
> > kernel contributor and has played a key role in developing a new feature
> > that will help both perf and ftrace, but without the EXPORT_SYMBOL_GPL(),
> > LTTng can't use it. It's basically saying "thank you Mathieu for helping us
> > with this new feature, now go F*** off!"  
> 
> You don't have to be as explicit, but otherwise that's exactly how
> it works.  No one gets a free ride just because they are nice and/or
> contributed something.

Why is that?

And yes, I still consider it draconian.

> 
> The rest of your mail looks just as confused.

Let me rephrase it then.

How would you recommend getting LTTng into the kernel? It's a relatively
large project that has 75K of lines of code with development that lasted
around 20 years.

Should it be one big code drop?

Should Mathieu copy the history of his git tree into the kernel/lttng
directory and suggest a git pull request to Linus?

To break it up now, into reviewable patches would be a huge undertaking.
And who is going to review it? I don't have the time, do you?

Basically, Mathieu has been a good Linux kernel community member, and even
wants his code upstream. But when he's the only one with a stake in getting
it upstream, and it's a long time large project, there's no easy path for
him to do it.

Now he's helped out with a simple feature that lets perf and ftrace get
user space stack traces without the need for frame pointers, and he can't
use it unless his code gets upstream.

Have any suggestions for him, or do you just not care? But you are one of
the gate keepers of EXPORT_SYMBOL_GPL() which affects him.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Greg KH]

On Mon, Jul 14, 2025 at 07:54:26AM -0400, Steven Rostedt wrote:
> On Mon, 14 Jul 2025 04:38:33 -0700
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > On Mon, Jul 14, 2025 at 06:27:24AM -0400, Steven Rostedt wrote:
> > > This has nothing to do with Mathieu being a friend. He's a long time Linux
> > > kernel contributor and has played a key role in developing a new feature
> > > that will help both perf and ftrace, but without the EXPORT_SYMBOL_GPL(),
> > > LTTng can't use it. It's basically saying "thank you Mathieu for helping us
> > > with this new feature, now go F*** off!"  
> > 
> > You don't have to be as explicit, but otherwise that's exactly how
> > it works.  No one gets a free ride just because they are nice and/or
> > contributed something.
> 
> Why is that?
> 
> And yes, I still consider it draconian.
> 
> > 
> > The rest of your mail looks just as confused.
> 
> Let me rephrase it then.
> 
> How would you recommend getting LTTng into the kernel? It's a relatively
> large project that has 75K of lines of code with development that lasted
> around 20 years.

The same exact way any such out-of-tree project gets merged into the
kernel tree.  This isn't unusual, why is anyone confused here?

> To break it up now, into reviewable patches would be a huge undertaking.
> And who is going to review it? I don't have the time, do you?

The maintainers of the subsystems in which the new code interacts with
are the reviewers, as always.  Again, nothing unusual here.

> Have any suggestions for him, or do you just not care? But you are one of
> the gate keepers of EXPORT_SYMBOL_GPL() which affects him.

This is not the issue at all, sorry Just submit it like normal.

I think there's a whole in-kernel document that describes the process :)

thanks,

greg k-h

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Mon, 14 Jul 2025 07:54:26 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> And yes, I still consider it draconian.

It's not that Mathieu doesn't want to work with upstream. It's more like
upstream doesn't want to work with Mathieu.

And I'll admit that I haven't helped in this regard. In the past I've
considered LTTng as more of an annoyance. But over the years of working
with Mathieu, we have found that ftrace and LTTng have two different
audiences with a little overlap. And because Mathieu has helped out where
he could, I started helping him where I could. That's called, collaboration.

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Mon, 14 Jul 2025 13:59:56 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> The maintainers of the subsystems in which the new code interacts with
> are the reviewers, as always.  Again, nothing unusual here.

What subsystems does it interact with? It is an observer, it doesn't affect
any subsystem. It's basically stand alone. It only needs to use the
tracepoint infrastructure (which BTW, Matiheu is the maintainer of).

Just like perf and ftrace. They are stand alone subsystems where other
subsystems may interact with them, but they don't really interact with
anything else (besides the normal utilities like allocation of memory and
such).

> 
> > Have any suggestions for him, or do you just not care? But you are one of
> > the gate keepers of EXPORT_SYMBOL_GPL() which affects him.  
> 
> This is not the issue at all, sorry Just submit it like normal.

So he could just send a thousand patch series that doesn't touch any other
subsystem? It would have a diffstat that touches nothing but kernel/lttng,
kernel/Makefile and kernel/Kconfig. Who's going to review it? Who's going
to accept it?


-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Mon, 14 Jul 2025 08:20:33 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> Just like perf and ftrace. They are stand alone subsystems where other

I should clarify, I'm using "ftrace" to reference the "tracing" subsystem,
as "ftrace" technically is the function hook mechanism that is tightly
coupled with every architecture that uses it.

So here, when I say "ftrace" I mean kernel/trace/*, and I really should say
"the tracing subsystem"

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Greg KH]

On Mon, Jul 14, 2025 at 08:20:33AM -0400, Steven Rostedt wrote:
> On Mon, 14 Jul 2025 13:59:56 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > The maintainers of the subsystems in which the new code interacts with
> > are the reviewers, as always.  Again, nothing unusual here.
> 
> What subsystems does it interact with? It is an observer, it doesn't affect
> any subsystem. It's basically stand alone. It only needs to use the
> tracepoint infrastructure (which BTW, Matiheu is the maintainer of).
> 
> Just like perf and ftrace. They are stand alone subsystems where other
> subsystems may interact with them, but they don't really interact with
> anything else (besides the normal utilities like allocation of memory and
> such).
> 
> > 
> > > Have any suggestions for him, or do you just not care? But you are one of
> > > the gate keepers of EXPORT_SYMBOL_GPL() which affects him.  
> > 
> > This is not the issue at all, sorry Just submit it like normal.
> 
> So he could just send a thousand patch series that doesn't touch any other
> subsystem? It would have a diffstat that touches nothing but kernel/lttng,
> kernel/Makefile and kernel/Kconfig. Who's going to review it? Who's going
> to accept it?

Again, this is all things that we all know how to do and aren't new.
Get someone in a subsystem relevant to it to review a patch series that
adds the needed files to the kernel in a way that they can actually be
reviewed.

As it seems that we do have other tracing/perf developers already, start
with them and go forward to see what they say.

good luck!

greg k-h

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Mon, 14 Jul 2025 15:26:47 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> As it seems that we do have other tracing/perf developers already, start
> with them and go forward to see what they say.

We tried that. I don't have the time and I'm sure the perf folks don't
care. I advocate for LTTng because of the support that Mathieu has given
us.

The only other option is to allow LTTng to have access to a couple of
functions that Mathieu helped develop. Otherwise it's forcing me to say
"Thank you Mathieu for all your work, now go F*** off!".

Which appears to be the only option :-(

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Arjan van de Ven]

On Mon, Jul 14, 2025 at 6:28 AM Greg KH <gregkh@linuxfoundation.org> wrote:
 > So he could just send a thousand patch series that doesn't touch any other
> > subsystem? It would have a diffstat that touches nothing but kernel/lttng,
> > kernel/Makefile and kernel/Kconfig. Who's going to review it? Who's going
> > to accept it?
>
> Again, this is all things that we all know how to do and aren't new.
> Get someone in a subsystem relevant to it to review a patch series that
> adds the needed files to the kernel in a way that they can actually be
> reviewed.
>
> As it seems that we do have other tracing/perf developers already, start
> with them and go forward to see what they say.


and a good best practice before posting 1000 series is .. to identify
the most likely reviews and ask them upfront what their preferred way
to do this is...

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Greg KH]

On Mon, Jul 14, 2025 at 09:35:47AM -0400, Steven Rostedt wrote:
> On Mon, 14 Jul 2025 15:26:47 +0200
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > As it seems that we do have other tracing/perf developers already, start
> > with them and go forward to see what they say.
> 
> We tried that. I don't have the time and I'm sure the perf folks don't
> care. I advocate for LTTng because of the support that Mathieu has given
> us.

When was this last tried?  If you don't have time, then the fault is on
you, not us :)

> The only other option is to allow LTTng to have access to a couple of
> functions that Mathieu helped develop. Otherwise it's forcing me to say
> "Thank you Mathieu for all your work, now go F*** off!".
> 
> Which appears to be the only option :-(

Stop making this false argument please, we aren't telling anyone
anything different from what we have always been saying for decades now.

Again, we don't export symbols for when there are no in-tree users.
That's it.

lttng not getting merged because you don't have time to review it should
not make the above rule somehow invalid.

sorry,

greg k-h

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Mon, 14 Jul 2025 15:56:14 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> lttng not getting merged because you don't have time to review it should
> not make the above rule somehow invalid.

Well, it's because LTTng is a separate entity that handles different
users than I worry about.

I'm having enough trouble keeping up with what is already in the
kernel. If we can find someone else to help out, I'm all for it.
Currently the tracing subsystem has two maintainers (Masami and
myself), and there's still not enough time to review the current code.
Mathieu is listed as a reviewer on the tracing subsystem. Could he
review his own code?

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Christoph Hellwig]

On Mon, Jul 14, 2025 at 07:54:26AM -0400, Steven Rostedt wrote:
> On Mon, 14 Jul 2025 04:38:33 -0700
> Christoph Hellwig <hch@infradead.org> wrote:
> 
> > On Mon, Jul 14, 2025 at 06:27:24AM -0400, Steven Rostedt wrote:
> > > This has nothing to do with Mathieu being a friend. He's a long time Linux
> > > kernel contributor and has played a key role in developing a new feature
> > > that will help both perf and ftrace, but without the EXPORT_SYMBOL_GPL(),
> > > LTTng can't use it. It's basically saying "thank you Mathieu for helping us
> > > with this new feature, now go F*** off!"  
> > 
> > You don't have to be as explicit, but otherwise that's exactly how
> > it works.  No one gets a free ride just because they are nice and/or
> > contributed something.
> 
> Why is that?

Why would it be any different?  We have a clear reason both for technical
reasons, and to get code upstream.  Making exceptions for vaguely defined
friends and family defeats the entire purpose.

If you want to help Mathieu or others do that by putting your effort
behind the cause instead of making up exceptions.

> How would you recommend getting LTTng into the kernel? It's a relatively
> large project that has 75K of lines of code with development that lasted
> around 20 years.

I honestly don't care.  Not my business.  And you're probably also
asking the wrong question, as those giant old out of tree projects
tend to be a mess because of that.  The right question is really what
functionality does LTTng have that we want in the kernel and work on
that.

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Tue, 15 Jul 2025 00:19:16 -0700
Christoph Hellwig <hch@infradead.org> wrote:

> I honestly don't care.  Not my business.  And you're probably also
> asking the wrong question, as those giant old out of tree projects
> tend to be a mess because of that.  The right question is really what
> functionality does LTTng have that we want in the kernel and work on
> that.

See my reply to Linus in the other thread you were Cc'd on.

https://lore.kernel.org/all/20250715052459.0000e119@gandalf.local.home/

-- Steve

Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules

[Steven Rostedt]

On Fri, 11 Jul 2025 18:39:40 +0200
Greg KH <gregkh@linuxfoundation.org> wrote:

> I'll show one real-world example, the USB offload path code, that you
> are using today on your Android phones that saves loads of battery life.
> In older kernels, the hooks/exports needed for that were all over the
> place, it took an engineer years to get this all working for lots of
> different hardware types and merged upstream properly.  They knew that
> they could not just get the upstream developers to export the needed
> functions, they had to get their working code merged in order to be able
> to have it happen.  And they did!

So how did this work? Did they write infrastructure in the core kernel
code with EXPORT_SYMBOL_GPL() to that this new functionality could be
used by other USB drivers?

In doing that, the work is adding functionality to all users inside the
kernel as well as to out of tree modules.

When I said that tracers are different, it comes down to that the
in-tree tracers are never a module. Any new infrastructure they use
will not be exported. There's no way that LTTng can add infrastructure
for perf and ftrace and then use it. So how is it suppose to work to
integrate with the kernel if we do not allow it to access the shared
infrastructure?

If perf and ftrace were modules, there would likely be a lot of
infrastructure functions with EXPORT_SYMBOL_GPL() that LTTng could use
and work to change its infrastructure to use the same infrastructure as
perf and ftrace. But because perf and ftrace are never a module,
there's no way for LTTng to work with the same code.

I explain this in more detail with my reply to Linus in the other
thread that you were Cc'd on.

https://lore.kernel.org/all/20250715052459.0000e119@gandalf.local.home/

-- Steve