All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <olsajiri@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, Jakub Kicinski <kuba@kernel.org>,
	Martin KaFai Lau <martin.lau@kernel.org>,
	bpf@vger.kernel.org,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: WARN: multiple IDs found for 'nf_conn': 92168, 117897 - using 92168
Date: Fri, 14 Oct 2022 08:47:26 +0200	[thread overview]
Message-ID: <Y0kF/radV0cg4JYk@krava> (raw)
In-Reply-To: <CAEf4Bzbow+8-f4rg2LRRRUD+=1wbv1MjpAh-P4=smUPtrzfZ3Q@mail.gmail.com>

On Thu, Oct 13, 2022 at 03:24:59PM -0700, Andrii Nakryiko wrote:
> On Thu, Oct 13, 2022 at 3:12 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > 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?
> >
> > now BTFIDS warnings..
> >
> > I can see following on centos8 with gcc 8.5:
> >
> >           BTFIDS  vmlinux
> >         WARN: multiple IDs found for 'task_struct': 300, 56614 - using 300
> >         WARN: multiple IDs found for 'file': 540, 56649 - using 540
> >         WARN: multiple IDs found for 'vm_area_struct': 549, 56652 - using 549
> >         WARN: multiple IDs found for 'seq_file': 953, 56690 - using 953
> >         WARN: multiple IDs found for 'inode': 1132, 56966 - using 1132
> >         WARN: multiple IDs found for 'path': 1164, 56995 - using 1164
> >         WARN: multiple IDs found for 'task_struct': 300, 61905 - using 300
> >         WARN: multiple IDs found for 'file': 540, 61943 - using 540
> >         WARN: multiple IDs found for 'vm_area_struct': 549, 61946 - using 549
> >         WARN: multiple IDs found for 'inode': 1132, 62029 - using 1132
> >         WARN: multiple IDs found for 'path': 1164, 62058 - using 1164
> >         WARN: multiple IDs found for 'cgroup': 1190, 62067 - using 1190
> >         WARN: multiple IDs found for 'seq_file': 953, 62253 - using 953
> >         WARN: multiple IDs found for 'sock': 7960, 62374 - using 7960
> >         WARN: multiple IDs found for 'sk_buff': 1876, 62485 - using 1876
> >         WARN: multiple IDs found for 'bpf_prog': 6094, 62542 - using 6094
> >         WARN: multiple IDs found for 'socket': 7993, 62545 - using 7993
> >         WARN: multiple IDs found for 'xdp_buff': 6191, 62836 - using 6191
> >         WARN: multiple IDs found for 'sock_common': 8164, 63152 - using 8164
> >         WARN: multiple IDs found for 'request_sock': 17296, 63204 - using 17296
> >         WARN: multiple IDs found for 'inet_request_sock': 36292, 63222 - using 36292
> >         WARN: multiple IDs found for 'inet_sock': 32700, 63225 - using 32700
> >         WARN: multiple IDs found for 'inet_connection_sock': 33944, 63240 - using 33944
> >         WARN: multiple IDs found for 'tcp_request_sock': 36299, 63260 - using 36299
> >         WARN: multiple IDs found for 'tcp_sock': 33969, 63264 - using 33969
> >         WARN: multiple IDs found for 'bpf_map': 6623, 63343 - using 6623
> >
> > I'll need to check on that..
> >
> > and I just actually saw the 'nf_conn' warning on linux-next/master with
> > latest fedora/gcc-12:
> >
> >           BTF [M] net/netfilter/nf_nat.ko
> >         WARN: multiple IDs found for 'nf_conn': 106518, 120156 - using 106518
> >         WARN: multiple IDs found for 'nf_conn': 106518, 121853 - using 106518
> >         WARN: multiple IDs found for 'nf_conn': 106518, 123126 - using 106518
> >         WARN: multiple IDs found for 'nf_conn': 106518, 124537 - using 106518
> >         WARN: multiple IDs found for 'nf_conn': 106518, 126442 - using 106518
> >         WARN: multiple IDs found for 'nf_conn': 106518, 128256 - using 106518
> >           LD [M]  net/netfilter/nf_nat_tftp.ko
> >
> > looks like maybe dedup missed this struct for some reason
> >
> > nf_conn dump from module:
> >
> >         [120155] PTR '(anon)' type_id=120156
> >         [120156] STRUCT 'nf_conn' size=320 vlen=14
> >                 'ct_general' type_id=105882 bits_offset=0
> >                 'lock' type_id=180 bits_offset=64
> >                 'timeout' type_id=113 bits_offset=640
> >                 'zone' type_id=106520 bits_offset=672
> >                 'tuplehash' type_id=106533 bits_offset=704
> >                 'status' type_id=1 bits_offset=1600
> >                 'ct_net' type_id=3215 bits_offset=1664
> >                 'nat_bysource' type_id=139 bits_offset=1728
> >                 '__nfct_init_offset' type_id=949 bits_offset=1856
> >                 'master' type_id=120155 bits_offset=1856
> >                 'mark' type_id=106351 bits_offset=1920
> >                 'secmark' type_id=106351 bits_offset=1952
> >                 'ext' type_id=106536 bits_offset=1984
> >                 'proto' type_id=106532 bits_offset=2048
> >
> > nf_conn dump from vmlinux:
> >
> >         [106517] PTR '(anon)' type_id=106518
> >         [106518] STRUCT 'nf_conn' size=320 vlen=14
> >                 'ct_general' type_id=105882 bits_offset=0
> >                 'lock' type_id=180 bits_offset=64
> >                 'timeout' type_id=113 bits_offset=640
> >                 'zone' type_id=106520 bits_offset=672
> >                 'tuplehash' type_id=106533 bits_offset=704
> >                 'status' type_id=1 bits_offset=1600
> >                 'ct_net' type_id=3215 bits_offset=1664
> >                 'nat_bysource' type_id=139 bits_offset=1728
> >                 '__nfct_init_offset' type_id=949 bits_offset=1856
> >                 'master' type_id=106517 bits_offset=1856
> >                 'mark' type_id=106351 bits_offset=1920
> >                 'secmark' type_id=106351 bits_offset=1952
> >                 'ext' type_id=106536 bits_offset=1984
> >                 'proto' type_id=106532 bits_offset=2048
> >
> > look identical.. Andrii, any idea?
> 
> I'm pretty sure they are not identical. There is somewhere a STRUCT vs
> FWD difference. We had a similar discussion recently with Alan
> Maguire.
> 
> >                 'master' type_id=120155 bits_offset=1856
> 
> vs
> 
> >                 'master' type_id=106517 bits_offset=1856

master is pointer to same 'nf_conn' object, and rest of the ids are same

jirka

  reply	other threads:[~2022-10-14  6:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04  2:05 objtool: bpf_dispatcher_xdp+0xa0: data relocation to !ENDBR: Jakub Kicinski
2022-10-04  4:49 ` WARN: multiple IDs found for 'nf_conn': 92168, 117897 - using 92168 Jakub Kicinski
2022-10-04  6:42   ` Jiri Olsa
2022-10-04 14:25     ` Jakub Kicinski
2022-10-05  9:45       ` Jiri Olsa
2022-10-05 15:44         ` Jakub Kicinski
2022-10-05 16:18           ` Jakub Kicinski
2022-10-05 20:07             ` Jiri Olsa
2022-10-13 15:05               ` Jakub Kicinski
2022-10-13 21:55                 ` Jiri Olsa
2022-10-13 22:12                 ` Jiri Olsa
2022-10-13 22:24                   ` Andrii Nakryiko
2022-10-14  6:47                     ` Jiri Olsa [this message]
2022-10-14 17:17                       ` Alan Maguire
2022-10-16 13:07                         ` Jiri Olsa
2022-10-21 18:18                       ` Andrii Nakryiko
2022-10-21 21:34                         ` Jiri Olsa
2022-10-22  5:36                           ` Jakub Kicinski
2022-10-23  1:18                             ` Alexei Starovoitov
2022-10-24 18:21                               ` Jakub Kicinski
2022-10-04 14:46   ` Daniel Xu
2022-10-04 15:34     ` Jakub Kicinski
2022-10-18 15:11     ` Christian Borntraeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y0kF/radV0cg4JYk@krava \
    --to=olsajiri@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=kuba@kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.