On Tue, 1 Oct 2019 22:18:18 +0000
Alexei Starovoitov [off-list ref] wrote:

quoted

And then you can just format the string from the bpf_trace_printk()
into msg, and then have:

	trace_bpf_print(msg);  

It's an interesting idea, but I don't think it can work.
Please see bpf_trace_printk implementation in kernel/trace/bpf_trace.c
It's a lot more than string printing.

Well, trace_printk() is just string printing. I was thinking that the
bpf_trace_printk() could just use a vsnprintf() into a temporary buffer
(like trace_printk() does), and then call the trace event to write it
out.

quoted

The user could then just enable the trace event from the file system. I
could also work on making instances work like /tmp does (with the
sticky bit) in creation. That way people with write access to the
instances directory, can make their own buffers that they can use (and
others can't access).  

We tried instances in bcc in the past and eventually removed all the 
support. The overhead of instances is too high to be usable.

What overhead? An ftrace instance should not have any more overhead than
the root one does (it's the same code). Or are you talking about memory
overhead?

quoted

quoted

Both 'trace' and 'trace_pipe' have quirky side effects.
Like opening 'trace' file will make all parallel trace_printk() to be ignored.
While reading 'trace_pipe' file will clear it.
The point that traditional 'read' and 'write' ACLs don't map as-is
to tracefs, so I would be careful categorizing things into
confidentiality vs integrity only based on access type.  

What exactly is the bpf_trace_printk() used for? I may have other ideas
that can help.  

It's debugging of bpf programs. Same is what printk() is used for
by kernel developers.

How is it extracted? Just read from the trace or trace_pipe file?

-- Steve