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
