[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y0iJXajhKPlqjOIO@krava>
Date: Thu, 13 Oct 2022 23:55:41 +0200
From: Jiri Olsa <olsajiri@...il.com>
To: Jakub Kicinski <kuba@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Cc: Jiri Olsa <olsajiri@...il.com>,
Martin KaFai Lau <martin.lau@...nel.org>,
bpf@...r.kernel.org,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: WARN: multiple IDs found for 'nf_conn': 92168, 117897 - using
92168
On Thu, Oct 13, 2022 at 08:05:17AM -0700, Jakub Kicinski wrote:
> On Wed, 5 Oct 2022 22:07:57 +0200 Jiri Olsa wrote:
> > > Yeah, it's there on linux-next, too.
> > >
> > > Let me grab a fresh VM and try there. Maybe it's my system. Somehow.
> >
> > ok, I will look around what's the way to install that centos 8 thing
>
> Any luck?
yea, sorry for delay, I reproduced that.. first objtool warnings ;-)
[jolsa@...tos8 linux-next]$ make
UPD include/generated/compile.h
CALL scripts/checksyscalls.sh
DESCEND objtool
DESCEND bpf/resolve_btfids
CC init/version.o
AR init/built-in.a
AR built-in.a
AR vmlinux.a
LD vmlinux.o
vmlinux.o: warning: objtool: relocate_restore_code+0x3c: relocation to !ENDBR: next_arg+0x8
vmlinux.o: warning: objtool: ___ksymtab+bpf_dispatcher_xdp_func+0x0: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0
vmlinux.o: warning: objtool: bpf_dispatcher_xdp+0x20: data relocation to !ENDBR: bpf_dispatcher_xdp_func+0x0
...
Peter,
as for objtool warnings, looks like with gcc we'll get
endbr64 instruction generated after nops
with centos gcc 8.5:
ffffffff818d2e20 <bpf_dispatcher_xdp_func>:
ffffffff818d2e20: 90 nop
ffffffff818d2e21: 90 nop
ffffffff818d2e22: 90 nop
ffffffff818d2e23: 90 nop
ffffffff818d2e24: 90 nop
ffffffff818d2e25: f3 0f 1e fa endbr64
ffffffff818d2e29: e9 92 eb 52 00 jmpq ffffffff81e019c0 <__x86_indirect_thunk_rdx>
ffffffff818d2e2e: 66 90 xchg %ax,%ax
while latest gcc 12 will put it after:
ffffffff82736900 <bpf_dispatcher_xdp_func>:
ffffffff82736900: f3 0f 1e fa endbr64
ffffffff82736904: 90 nop
ffffffff82736905: 90 nop
ffffffff82736906: 90 nop
ffffffff82736907: 90 nop
ffffffff82736908: 90 nop
ffffffff82736909: 41 54 push %r12
ffffffff8273690b: 49 89 f4 mov %rsi,%r12
ffffffff8273690e: 55 push %rbp
ffffffff8273690f: 48 89 fd mov %rdi,%rbp
ffffffff82736912: 53 push %rbx
ffffffff82736913: 48 89 d3 mov %rdx,%rbx
ffffffff82736916: e8 65 f6 cf fe call ffffffff81435f80 <__sanitizer_cov_trace_pc>
ffffffff8273691b: 4c 89 e6 mov %r12,%rsi
ffffffff8273691e: 48 89 ef mov %rbp,%rdi
ffffffff82736921: 48 89 d8 mov %rbx,%rax
ffffffff82736924: 5b pop %rbx
ffffffff82736925: 5d pop %rbp
ffffffff82736926: 41 5c pop %r12
ffffffff82736928: e9 b3 b6 8c 00 jmp ffffffff83001fe0 <__x86_indirect_thunk_array>
any idea where's the problem? bad backport? ;-)
in any case (unrelated), I'll check the bpf dispatcher code,
I'm not sure the nop update code is aware of the endbr64 instruction
jirka
Powered by blists - more mailing lists