All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Paul Moore <paul@paul-moore.com>, Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
	Ondrej Mosnacek <omosnace@redhat.com>
Subject: Re: selftest/bpf/test_verifier_log fails on v5.11-rc5
Date: Sat, 30 Jan 2021 21:48:10 +0100	[thread overview]
Message-ID: <YBXGChWt/E2UDgZc@krava> (raw)
In-Reply-To: <CAADnVQKbku+Mv++h2TKYZfFN7NjPgaeLHJsw0oFNUhjUZ6ehSQ@mail.gmail.com>

On Fri, Jan 29, 2021 at 07:13:21PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 29, 2021 at 2:15 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Mon, Jan 25, 2021 at 5:42 PM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > > On Mon, Jan 25, 2021 at 12:54 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > Hello all,
> > > >
> > > > My apologies if this has already been reported, but I didn't see
> > > > anything obvious with a quick search through the archives.  I have a
> > > > test program that behaves very similar to the existing
> > > > selftest/bpf/test_verifier_log test that has started failing this week
> > > > with v5.11-rc5; it ran without problem last week on v5.11-rc4.  Is
> > > > this a known problem with a fix already, or is this something new?
> > > >
> > > > % uname -r
> > > > 5.11.0-0.rc5.134.fc34.x86_64
> > > > % pwd
> > > > /.../linux/tools/testing/selftests/bpf
> > > > % git log --oneline | head -n 1
> > > > 6ee1d745b7c9 Linux 5.11-rc5
> > > > % make test_verifier_log
> > > >   ...
> > > >   BINARY   test_verifier_log
> > > > % ./test_verifier_log
> > > > Test log_level 0...
> > > > Test log_size < 128...
> > > > Test log_buff = NULL...
> > > > Test oversized buffer...
> > > > ERROR: Program load returned: ret:-1/errno:22, expected ret:-1/errno:13
> > >
> > > Thanks for reporting.
> > > bpf and bpf-next don't have this issue. Not sure what changed.
> >
> > I haven't had a chance to look into this any further, but Ondrej
> > Mosnacek (CC'd) found the following today:
> >
> > "So I was trying to debug this further and I think I've identified what
> > triggers the problem. It seems that the BTF debuginfo generation
> > became broken with CONFIG_DEBUG_INFO_DWARF4=n somewhere between -rc4
> > and -rc5. It also seems to depend on a recent (Fedora Rawhide) version
> > of some component of the build system (GCC, probably), because the
> > problem disappeared when I tried to build the "bad" kernel in F33
> > buildroot instead of Rawhide."
> 
> I see. There were fixes for dwarf and btf, but I lost the track.
> I believe it was a combination of gcc bug that was worked around in pahole.
> Arnaldo, Jiri, Andrii,
> what is the status? Did all fixes land in pahole?

I checked on rawhide and besides many pahole warnings,
the resulted BTF data have many duplications in core structs

	  BTFIDS  vmlinux
	WARN: multiple IDs found for 'task_struct': 132, 1247 - using 132
	WARN: multiple IDs found for 'file': 440, 1349 - using 440
	WARN: multiple IDs found for 'inode': 698, 1645 - using 698
	WARN: multiple IDs found for 'path': 729, 1672 - using 729
	WARN: multiple IDs found for 'task_struct': 132, 2984 - using 132
	WARN: multiple IDs found for 'task_struct': 132, 3043 - using 132
	WARN: multiple IDs found for 'file': 440, 3085 - using 440
	WARN: multiple IDs found for 'seq_file': 1469, 3125 - using 1469
	WARN: multiple IDs found for 'inode': 698, 3336 - using 698
	WARN: multiple IDs found for 'path': 729, 3366 - using 729
	WARN: multiple IDs found for 'task_struct': 132, 5337 - using 132
	WARN: multiple IDs found for 'inode': 698, 5360 - using 698
	WARN: multiple IDs found for 'path': 729, 5388 - using 729
	WARN: multiple IDs found for 'file': 440, 5412 - using 440
	WARN: multiple IDs found for 'seq_file': 1469, 5639 - using 1469
	WARN: multiple IDs found for 'task_struct': 132, 6243 - using 132
	...

	# gcc --version
	gcc (GCC) 11.0.0 20210123 (Red Hat 11.0.0-0)

I'm guessing there are some DWARF changes that screwed BTF
generation.. I'll check

it's not covered by the fix I posted recently, but I think
Arnaldo is now fixing some related stuff.. Arnaldo, maybe
you are seeing same errors?

I uploaded the build log from linking part to:
  http://people.redhat.com/~jolsa/build.out.gz

jirka


  reply	other threads:[~2021-01-30 20:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25 20:51 selftest/bpf/test_verifier_log fails on v5.11-rc5 Paul Moore
2021-01-25 22:42 ` Alexei Starovoitov
2021-01-29 22:15   ` Paul Moore
2021-01-30  3:13     ` Alexei Starovoitov
2021-01-30 20:48       ` Jiri Olsa [this message]
2021-01-31 21:36         ` Jiri Olsa
2021-02-01 12:25           ` Arnaldo Carvalho de Melo
2021-02-01 14:50             ` Jiri Olsa
2021-02-01 20:23               ` Jiri Olsa
2021-02-01 22:43                 ` Ondrej Mosnacek
2021-02-01 23:28                   ` Paul Moore
2021-02-02 12:43                   ` Arnaldo Carvalho de Melo
2021-02-02 15:24                     ` Paul Moore

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=YBXGChWt/E2UDgZc@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jolsa@kernel.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    /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.