Re: [linus:master] [hugetlb] 7118fc2906: kernel_BUG_at_lib/list_debug.c

[Feng Tang <feng.tang@intel.com>]

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