linux-kernel - Re: [linus:master] [hugetlb] 7118fc2906: kernel_BUG_at_lib/list

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y8ioo5EWrMCDkoU5@feng-clx>
Date:   Thu, 19 Jan 2023 10:19:15 +0800
From:   Feng Tang <feng.tang@...el.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Vlastimil Babka <vbabka@...e.cz>,
        "Sang, Oliver" <oliver.sang@...el.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        "oe-lkp@...ts.linux.dev" <oe-lkp@...ts.linux.dev>,
        lkp <lkp@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jann Horn <jannh@...gle.com>,
        "Song, Youquan" <youquan.song@...el.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Jan Kara <jack@...e.cz>, John Hubbard <jhubbard@...dia.com>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Matthew Wilcox <willy@...radead.org>,
        Michal Hocko <mhocko@...nel.org>,
        Muchun Song <songmuchun@...edance.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Hyeonggon Yoo <42.hyeyoo@...il.com>,
        "Yin, Fengwei" <fengwei.yin@...el.com>, <hongjiu.lu@...el.com>
Subject: Re: [linus:master] [hugetlb] 7118fc2906:
 kernel_BUG_at_lib/list_debug.c

On Wed, Jan 18, 2023 at 09:10:45AM -0800, Linus Torvalds wrote:
> On Wed, Jan 18, 2023 at 5:33 AM Feng Tang <feng.tang@...el.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.
 
Just tried this, the generated assembly is much more readable, thanks
for the tip!

> 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.

Yes.

> 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.

I guess the O1/O2 difference is also the 'fewer registers' case, that
O1 make many functions not inlined into prep_compound_page() and
needs less registers.

> 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.

I tried to file a gcc bug, but was stuck in creating account phase,
will follow up.

I don't know if it makes sense to make GCOV_KERNEL option depend on
!X86_32 for now, till the problem is solved. Or we can ask 0Day to
disable GCOV for i386 build, assuming GCOV+i386 is not a common
usage model.

Thanks,
Feng

>                 Linus
>