Re: [PATCH v3 bpf-next 0/2] bpf: fix use of trace_printk() in BPF

From: Alexei Starovoitov
Date: Mon Jul 13 2020 - 20:02:08 EST


On Mon, Jul 13, 2020 at 4:53 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote:
>
> Steven suggested a way to resolve the appearance of the warning banner
> that appears as a result of using trace_printk() in BPF [1].
> Applying the patch and testing reveals all works as expected; we
> can call bpf_trace_printk() and see the trace messages in
> /sys/kernel/debug/tracing/trace_pipe and no banner message appears.
>
> Also add a test prog to verify basic bpf_trace_printk() helper behaviour.
>
> Changes since v2:
>
> - fixed stray newline in bpf_trace_printk(), use sizeof(buf)
> rather than #defined value in vsnprintf() (Daniel, patch 1)
> - Daniel also pointed out that vsnprintf() returns 0 on error rather
> than a negative value; also turns out that a null byte is not
> appended if the length of the string written is zero, so to fix
> for cases where the string to be traced is zero length we set the
> null byte explicitly (Daniel, patch 1)
> - switch to using getline() for retrieving lines from trace buffer
> to ensure we don't read a portion of the search message in one
> read() operation and then fail to find it (Andrii, patch 2)
>
> Changes since v1:
>
> - reorder header inclusion in bpf_trace.c (Steven, patch 1)
> - trace zero-length messages also (Andrii, patch 1)
> - use a raw spinlock to ensure there are no issues for PREMMPT_RT
> kernels when using bpf_trace_printk() within other raw spinlocks
> (Steven, patch 1)
> - always enable bpf_trace_printk() tracepoint when loading programs
> using bpf_trace_printk() as this will ensure that a user disabling
> that tracepoint will not prevent tracing output from being logged
> (Steven, patch 1)
> - use "tp/raw_syscalls/sys_enter" and a usleep(1) to trigger events
> in the selftest ensuring test runs faster (Andrii, patch 2)
>
> [1] https://lore.kernel.org/r/20200628194334.6238b933@xxxxxxxxxxxxxxxx

Applied. Thanks