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

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Mon, Jul 13, 2020 at 4:53 AM Alan Maguire <alan.maguire@oracle.com> 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@oasis.local.home

Applied. Thanks