Re: GNU Binutils 2.33.1 has been released.

[Alan Modra <amodra at gmail dot com>]

On Tue, Dec 03, 2019 at 09:59:48PM +0100, Romain Naour wrote:
> Hi,
> 
> Le lun. 2 déc. 2019 à 05:17, Alan Modra <amodra@gmail.com> a écrit :
> 
> > On Sat, Nov 30, 2019 at 12:05:55PM +0100, Romain Naour wrote:
> > > The system doesn't boot but if It I revert the commit [1], the system
> > boot.
> > >
> > > Since it's a commit not related to sh4, it's weird that is the only
> > affected
> > > architecture.
> > >
> > > [1]
> > >
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e
> >
> > Difference in vmlinux linker map file (I added -Map vmlinux.map to ld
> > flags) between 2.33.1 and 2.33.1 with [1] reverted is:
> >
> >                  0x000000008c3ff5b0       0x11 lib/timerqueue.o
> >   *fill*         0x000000008c3ff5c1        0x3
> >   .rodata.str1.4
> > -                0x000000008c3ff5c4      0x13f lib/vsprintf.o
> > +                0x000000008c3ff5c4      0x140 lib/vsprintf.o
> >                                          0x1bf (size before relaxing)
> > -                0x000000008c3ff703                __start_ro_after_init =
> > .
> > +                0x000000008c3ff704                __start_ro_after_init =
> > .
> >   *(.data..ro_after_init)
> > - *fill*         0x000000008c3ff703        0x1
> >   .data..ro_after_init
> >                  0x000000008c3ff704       0x1c kernel/ksysfs.o
> >   .data..ro_after_init
> >
> > I believe there is a kernel bug in handling of __start_ro_after_init.
> > If you take a look at kmemleak.c:scan_block you'll see that the start
> > address is aligned up to a pointer sized boundary.  That's fine, but
> > scan_large_block calls scan_block repeatedly without first aligning
> > the start address, with the result that one word is missed from the
> > scan every MAX_SCAN_SIZE bytes when __start_ro_after_init is not
> > aligned.  The following untested patch should fix this.
> > Alternatively, align __start_ro_after_init in the script.
> >
> > --- mm/kmemleak.c~      2019-01-17 07:34:38.000000000 +1030
> > +++ mm/kmemleak.c       2019-12-02 14:33:20.997174278 +1030
> > @@ -1377,6 +1377,7 @@ static void scan_large_block(void *start
> >  {
> >         void *next;
> >
> > +       start = PTR_ALIGN(start, BYTES_PER_POINTER);
> >
> 
> scan_large_block is only user when CONFIG_SMP is enabled but it is not in
> the kernel config I'm using
> 
> I tested with this patch but the kernel doesn't boot.
> 

I built a kernel using your buildroot and binutils-2.33.1 with and
without patch [1].  cmp -l shows 41 bytes different in vmlinux.  These
are in the .notes section (build id), .rodata (date and time string),
.data (date and time string again), and .symtab (the value of
__start_ro_after_init).

Yet you claim that a kernel built with binutils-2.33.1 with patch
[1] reverted works.  Which very likely means your description of how
to reproduce the problem is missing some critical detail.  Have you
compared vmlinux binaries for differences?

> 
>         while (start < end) {
> >                 next = min(start + MAX_SCAN_SIZE, end);
> >                 scan_block(start, next, NULL);
> >

-- 
Alan Modra
Australia Development Lab, IBM