[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1594641154-18897-1-git-send-email-alan.maguire@oracle.com>
Date: Mon, 13 Jul 2020 12:52:32 +0100
From: Alan Maguire <alan.maguire@...cle.com>
To: rostedt@...dmis.org, mingo@...hat.com, ast@...nel.org,
daniel@...earbox.net
Cc: kafai@...com, songliubraving@...com, yhs@...com, andriin@...com,
john.fastabend@...il.com, kpsingh@...omium.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
bpf@...r.kernel.org, Alan Maguire <alan.maguire@...cle.com>
Subject: [PATCH v3 bpf-next 0/2] bpf: fix use of trace_printk() in BPF
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
Alan Maguire (2):
bpf: use dedicated bpf_trace_printk event instead of trace_printk()
selftests/bpf: add selftests verifying bpf_trace_printk() behaviour
kernel/trace/Makefile | 2 +
kernel/trace/bpf_trace.c | 42 ++++++++++--
kernel/trace/bpf_trace.h | 34 ++++++++++
.../selftests/bpf/prog_tests/trace_printk.c | 75 ++++++++++++++++++++++
tools/testing/selftests/bpf/progs/trace_printk.c | 21 ++++++
5 files changed, 169 insertions(+), 5 deletions(-)
create mode 100644 kernel/trace/bpf_trace.h
create mode 100644 tools/testing/selftests/bpf/prog_tests/trace_printk.c
create mode 100644 tools/testing/selftests/bpf/progs/trace_printk.c
--
1.8.3.1
Powered by blists - more mailing lists