On 2024-10-27 21:23, Andrii Nakryiko wrote:
On Sun, Oct 27, 2024 at 7:19 AM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
[...]
include/linux/tracepoint-defs.h | 2 ++
include/linux/tracepoint.h | 24 ++++++++++++++++++++++++
include/trace/define_trace.h | 2 +-
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
index 967c08d9da84..53119e074c87 100644
--- a/include/linux/tracepoint-defs.h
+++ b/include/linux/tracepoint-defs.h
@@ -32,6 +32,8 @@ struct tracepoint_func {
struct tracepoint_ext {
int (*regfunc)(void);
void (*unregfunc)(void);
+ /* Flags. */
+ unsigned int syscall:1;
I wonder if we should call it "sleepable" instead? For this patch set
do we really care if it's a system call or not? It's really if the
tracepoint is sleepable or not that's the issue. System calls are just
one user of it, there may be more in the future, and the changes to BPF
will still be needed.
I agree with this. Even if currently we restrict only syscall events
can be sleep, "tracepoint_is_syscall()" requires to add comment to
explain why on all call sites e.g.
+1 to naming this "sleepable" (or at least "faultable"). BPF world
uses "sleepable BPF" terminology for BPF programs and attachment hooks
that can take page fault (and wait/sleep waiting for those to be
handled), so this would be consistent with that. Also, from BPF
standpoint this will be advertised as attaching to sleepable
tracepoints regardless, so "syscall" terminology is too specific and
misleading, because while current set of tracepoints are
syscall-specific, the important part is taking page fault, no tracing
syscalls.
+1 for "faultable".
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
