On 11/17/21 7:28 AM, Matteo Croce wrote:
On Wed, Nov 17, 2021 at 5:34 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
On Tue, Nov 16, 2021 at 4:48 PM Matteo Croce <mcroce@xxxxxxxxxxxxxxxxxxx> wrote:
On Fri, Nov 12, 2021 at 6:02 AM Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
From: Alexei Starovoitov <ast@xxxxxxxxxx>
v1->v2:
. Refactor uapi to pass 'struct bpf_core_relo' from LLVM into libbpf and further
into the kernel instead of bpf_core_apply_relo() bpf helper. Because of this
change the CO-RE algorithm has an ability to log error and debug events through
the standard bpf verifer log mechanism which was not possible with helper
approach.
. #define RELO_CORE macro was removed and replaced with btf_member_bit_offset() patch.
This set introduces CO-RE support in the kernel.
There are several reasons to add such support:
1. It's a step toward signed BPF programs.
2. It allows golang like languages that struggle to adopt libbpf
to take advantage of CO-RE powers.
3. Currently the field accessed by 'ldx [R1 + 10]' insn is recognized
by the verifier purely based on +10 offset. If R1 points to a union
the verifier picks one of the fields at this offset.
With CO-RE the kernel can disambiguate the field access.
Great, I tested the same code which was failing with the RFC series,
now there isn't any error.
This is the output with pr_debug() enabled:
root@debian64:~/core# ./core
[ 5.690268] prog '(null)': relo #-2115894237: kind <(null)>
(163299788), spec is
[ 5.690272] prog '(null)': relo #-2115894246: (null) candidate #-2115185528
[ 5.690392] prog '(null)': relo #2: patched insn #208 (LDX/ST/STX)
off 208 -> 208
[ 5.691045] prog '(efault)': relo #-2115894237: kind <(null)>
(163299788), spec is
[ 5.691047] prog '(efault)': relo #-2115894246: (null) candidate
#-2115185528
[ 5.691148] prog '(efault)': relo #3: patched insn #208
(LDX/ST/STX) off 208 -> 208
[ 5.692456] prog '(null)': relo #-2115894237: kind <(null)>
(163302708), spec is
[ 5.692459] prog '(null)': relo #-2115894246: (null) candidate #-2115185668
[ 5.692564] prog '(null)': relo #2: patched insn #104 (LDX/ST/STX)
off 104 -> 104
[ 5.693179] prog '(efault)': relo #-2115894237: kind <(null)>
(163299788), spec is
[ 5.693181] prog '(efault)': relo #-2115894246: (null) candidate
#-2115185528
[ 5.693258] prog '(efault)': relo #3: patched insn #208
(LDX/ST/STX) off 208 -> 208
[ 5.696141] prog '(null)': relo #-2115894237: kind <(null)>
(163302708), spec is
[ 5.696143] prog '(null)': relo #-2115894246: (null) candidate #-2115185668
[ 5.696255] prog '(null)': relo #2: patched insn #104 (LDX/ST/STX)
off 104 -> 104
[ 5.696733] prog '(efault)': relo #-2115894237: kind <(null)>
(163299788), spec is
[ 5.696734] prog '(efault)': relo #-2115894246: (null) candidate
#-2115185528
[ 5.696833] prog '(efault)': relo #3: patched insn #208
(LDX/ST/STX) off 208 -> 208
All the logged values are completely wrong, some corruption somewhere.
But I tried to see it for myself and I couldn't figure out how to get
these logs with lskel. How did you get the above?
Alexei, any guidance on how to get those verifier logs back with
test_progs? ./test_progs -vvv didn't help, I also checked trace_pipe
output, it was empty. I thought that maybe verifier truncates logs on
success and simulated failed prog validation, but still nothing.
And the syscall returns success:
bpf(BPF_PROG_TEST_RUN, {test={prog_fd=4, retval=0, data_size_in=0,
data_size_out=0, data_in=NULL, data_out=NULL, repeat=0, duration=0,
ctx_size_in=68, ctx_size_out=0, ctx_in=0x5590b97dd2a0, ctx_out=NULL}},
160) = 0
Regards,
--
per aspera ad upstream
Sorry, there was an off-by-one in the macro.
I just aliased all the pr_* to printk, this is the correct output:
This hack is not necessary. The debug messages are going to the verifier
log and it's printed when prog fails to load.
To see successful log the hack to lskel's prog_load_and_run is needed.
I'll add -vvv support in the follow up, so it's easier.
Currently neither standard skel nor lskel support -v, unfortunately,
so a bit of plumbing is necessary (which is not related to "CO-RE in the
kernel" work).
