Re: WARN: multiple IDs found for 'nf_conn': 92168, 117897 - using 92168

[Jiri Olsa <olsajiri@gmail.com>]

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@centos8 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