From: Feng Tang <feng.tang@intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
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:07:50 +0800 [thread overview]
Message-ID: <Y8dGZkhytk25iyr1@feng-clx> (raw)
In-Reply-To: <CAHk-=wiS84nS9apjs_Vt=jjZ_+j+F8HQ3B+ABSvbzcqtW9x5Kg@mail.gmail.com>
On Tue, Jan 17, 2023 at 10:25:17AM -0800, Linus Torvalds wrote:
> On Tue, Jan 17, 2023 at 4:22 AM Feng Tang <feng.tang@intel.com> wrote:
> >
> > With the following patch to use 'O1' instead 'O2' gcc optoin for
> > page_alloc.c, the list corruption issue can't be reproduced for
> > commit 7118fc2906 in 1000 runs.
>
> Ugh.
>
> It would be lovely if you could just narrow it down with
>
> #pragma GCC optimize ("O1")
> ...
> #pragma GCC optimize ("O2")
>
> around just that prep_compound_page(), but when I tried it myself I
> get some function attribute mismatch errors.
Good to know, thanks! will try this.
>
> > As is can't be reproduced with X86_64 build, it could be i386
> > compiling related.
>
> Your particular config causes a huge amount of nasty 64-bit arithmetic
> according to the objdump code, with sequences like
>
> c13b3cbb: 83 05 d0 28 6c c5 01 addl $0x1,0xc56c28d0
> c13b3cc2: 83 15 d4 28 6c c5 00 adcl $0x0,0xc56c28d4
>
> which seems to be just from some coverage profiling being on
> (CONFIG_GCOV?), or something. It makes it very hard to read the code.
>
> You also have UBSAN enabled, which - again - makes for some really
> grotty asm that hides any actual logic.
Yes, you are right, CONFIG_GCOV_PROFILE_ALL and a bunch of UBSAN
configs are enabled.
AFAIK, this is a random generated config for sanity test, Oliver/Philip
can correct me on this.
> Finally, your objdump version also does some horrendous decoding, like
>
> c13b3e29: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi
>
> which is just a 7-byte 'nop' instruction, but again, it makes it
> rather hard to actually read the code.
>
> With the i386 defconfig, gcc generates a function that is just ~30
> instructions for me, so this makes a huge difference in the legibility
> of the code.
>
> I wonder if you can recreate the issue with a much more
> straightforward config. By all means, leave DEBUG_PAGEALLOC and SLUB
> debugging on, but without the things like UBSAN and GCOV.
Oliver and I can try this, and will report back.
> > I also objdumped 'prep_compound_page' for vmlinux of 7118fc2906 and
> > its parent commit 48b8d744ea84, which have big difference than the
> > simple 'set_page_count()' change, but I can't tell which part is
> > abnormal, so attach them for further check.
>
> Yeah, I can't make heads or tails of them either, see above on how
> illegible the objdump files are. And that's despite not even having
> all of prep_compound_page() in them (it's missing
> prep_compound_page.cold, which is probably just UBSAN fixup code, but
> who knows..)
>
> That said, with the i386 defconfig, the only change from adding
> set_page_count() to the loop seems to be exactly that:
>
> .L589:
> - movl $1024, 12(%eax)
> + movl $0, 28(%eax)
> addl $32, %eax
> + movl $1024, -20(%eax)
> movl %esi, -28(%eax)
> movl $0, -12(%eax)
> cmpl %edx, %eax
>
> (don't ask me why gcc does *one* access using the pre-incremented
> pointer, and then the rest to the post-incremented ones, but whatever
> - it means that it's not just "add a mov $0", it's also changing how
> the
>
> p->mapping = TAIL_MAPPING;
>
> instruction is done, which is that
>
> - movl $1024, 12(%eax)
> + movl $1024, -20(%eax)
>
> part of the change)
This version of assembly diff looks more reasonable. One thing I
note is the sizeof(page) with this config is 32, while it's 40 for
the randconfig used in this report.
Thanks for the analyzing and debug suggestion!
- Feng
> Linus
next prev parent reply other threads:[~2023-01-18 1:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 7:10 [linus:master] [hugetlb] 7118fc2906: kernel_BUG_at_lib/list_debug.c 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 [this message]
2023-01-18 13:31 ` Feng Tang
2023-01-18 17:10 ` Linus Torvalds
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=Y8dGZkhytk25iyr1@feng-clx \
--to=feng.tang@intel.com \
--cc=42.hyeyoo@gmail.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--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=torvalds@linux-foundation.org \
--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;
as well as URLs for NNTP newsgroup(s).