linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Feng Tang <feng.tang@intel.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	"Sang, Oliver" <oliver.sang@intel.com>,
	 Mike Kravetz <mike.kravetz@oracle.com>,
	"oe-lkp@lists.linux.dev" <oe-lkp@lists.linux.dev>,
	lkp <lkp@intel.com>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jann Horn <jannh@google.com>,
	 "Song, Youquan" <youquan.song@intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>, Jan Kara <jack@suse.cz>,
	 John Hubbard <jhubbard@nvidia.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	 Matthew Wilcox <willy@infradead.org>,
	Michal Hocko <mhocko@kernel.org>,
	 Muchun Song <songmuchun@bytedance.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	 "Yin, Fengwei" <fengwei.yin@intel.com>,
	hongjiu.lu@intel.com
Subject: Re: [linus:master] [hugetlb] 7118fc2906: kernel_BUG_at_lib/list_debug.c
Date: Wed, 18 Jan 2023 09:10:45 -0800	[thread overview]
Message-ID: <CAHk-=wh0pdJm6tS4-ywR3Zi70PnBjMXeCkuQKnu8utcSKjxNEw@mail.gmail.com> (raw)
In-Reply-To: <Y8f0miUc//BQXN3A@feng-clx>

On Wed, Jan 18, 2023 at 5:33 AM Feng Tang <feng.tang@intel.com> wrote:
>
> > Finally, your objdump version also does some horrendous decoding, like
> >
> >   c13b3e29:       8d b4 26 00 00 00 00    lea    0x0(%esi,%eiz,1),%esi
>
> I know little about these tools, and I tried objdump tool from
> Cent OS 9 (objdump version 2.35.2) and Ubuntu 22.04 (objdump version
> 2.38), they both dumped similar assembly. Please let me know if you
> want us to try other version of objdump.

It's fine - it just makes things even less legible than they already were.

I personally very seldom try to look at objdump output - I tend to do
things like

     make mm/page_alloc.s

and look at the compiler-generated assembly instead. That ends up
generally being a lot more legible for various reasons, not the least
of which is the variable name commentary that the compiler also
outputs.

So objdump is kind of a last resort, and then you just have to deal
with the fact that its output format is very nasty.

> We modify the kconfig to disable GCOV and UBSAN, and the issue can't
> be reproudced in 1000 runs.

Ok, it does seem like this is a compiler bug, as per Vlastimil's decoding.

And the reason it happens on 32-bit is probably that we just have much
fewer registers available there, and the 64-bit GCOV counts then
complicate things even more, and then some interaction between that
and UBSAN just generates crazy code.

And it probably has very little compiler test coverage in real life anyway.

From Vlastimil's decode, it does look like gcc has mixed up the
"update GCOV counts" with actual real values for "nr_pages", and is
using %eax for both things because of some register allocation
mistake.

So I think we can dismiss this one as a compiler bug. It might be good
to see if it happens with a newer version of gcc too, and even perhaps
post a gcc bugzilla entry, but since this probably isn't really a very
interesting config for real life, I'm not sure how interested people
are going to be.

                Linus


  reply	other threads:[~2023-01-18 17:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-17  7:10 kernel test robot
2023-01-17  7:39 ` Vlastimil Babka
2023-01-17  7:47   ` Yin, Fengwei
2023-01-17  8:01   ` Feng Tang
2023-01-17 12:20     ` Feng Tang
2023-01-17 18:25       ` Linus Torvalds
2023-01-18  1:07         ` Feng Tang
2023-01-18 13:31         ` Feng Tang
2023-01-18 17:10           ` Linus Torvalds [this message]
2023-01-19  2:19             ` Feng Tang
2023-01-18 13:35         ` Vlastimil Babka
2023-01-18 15:07           ` Feng Tang
2023-01-17 18:50 ` Mike Kravetz

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='CAHk-=wh0pdJm6tS4-ywR3Zi70PnBjMXeCkuQKnu8utcSKjxNEw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=feng.tang@intel.com \
    --cc=fengwei.yin@intel.com \
    --cc=hongjiu.lu@intel.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mhocko@kernel.org \
    --cc=mike.kravetz@oracle.com \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=songmuchun@bytedance.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=youquan.song@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox