linux-kernel - Re: RTL9300 (mips) fails to boot with commit d4a7f2510ff4 ("vmlinux.lds.h: Adjust symbol ordering in text output section")

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF1bQ=QEL3XZYsNL-f7jmbDOVWHSVfhZSYx0iddct3nz8_Yf1A@mail.gmail.com>
Date: Mon, 25 Nov 2024 10:48:07 -0800
From: Rong Xu <xur@...gle.com>
To: Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc: "Han Yao Yeo (atg)" <hanyao.yeo@...iedtelesis.com.sg>, 
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Masahiro Gotoh <gotoh@...ied-telesis.co.jp>, 
	"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: RTL9300 (mips) fails to boot with commit d4a7f2510ff4
 ("vmlinux.lds.h: Adjust symbol ordering in text output section")

Thanks for confirming this! It looks like we do need to put all
symbols from head.o before any other symbols.
To be clear, the patch I mentioned was not trying to do that -- it
just makes sure the _stext is in the right places.

I'll draft a patch for this.

On Sun, Nov 24, 2024 at 12:40 PM Chris Packham
<Chris.Packham@...iedtelesis.co.nz> wrote:
>
> Hi Rong,
>
> On 22/11/24 18:02, Rong Xu wrote:
> > Does the following patch fix your issue?
> > https://lore.kernel.org/lkml/CAK7LNAQSpM2hh2=Wgribb92nHF5_peRb+gxdO1Bt1MkeL8N+hw@mail.gmail.com/t/
> >
> > Masahiro Yamada already applied the patch to kbuild-tree.
> >
> > I also proposed a similar fix as yours. But we believe the above patch
> > should also work (and probably is better).
> >
> > Please try and let us know.
>
> Looks like linux-next already has that patch and no it doesn't fix my
> issue. For the record here's the start of my System.map
>
> $ head System.map
> ffffffff80100000 T __split_text_end
> ffffffff80100000 T __split_text_start
> ffffffff80100000 T __unlikely_text_start
> ffffffff80100000 T _stext
> ffffffff80100000 T _text
> ffffffff80100000 t run_init_process
> ffffffff80100138 t try_to_run_init_process
> ffffffff8010018c t put_page
> ffffffff801001d0 t nr_blocks.isra.0
> ffffffff80100208 T ack_bad_irq
>
> It does look like whatever is supposed to put head.o first isn't kicking
> in for me.
>
> >
> > Thanks!
> >
> > -Rong
> >
> > On Thu, Nov 21, 2024 at 6:29 PM Chris Packham
> > <chris.packham@...iedtelesis.co.nz> wrote:
> >>
> >> On 22/11/24 14:58, Chris Packham wrote:
> >>> Hi Rong,
> >>>
> >>> I was just trying some of my in-flight changes against linux-next and
> >>> found that my RTL9300* based board no longer boots (nothing on the
> >>> serial console after U-Boot hands off to the kernel).
> >>>
> >>> A bisect between Linus's tree and linux-next/master points to commit
> >>> d4a7f2510ff4 ("vmlinux.lds.h: Adjust symbol ordering in text output
> >>> section"). A build on d4a7f2510ff4^ boots successfully. That series is
> >>> well beyond my area of knowledge, there may be something that the MIPS
> >>> SoCs are doing (or not doing) that is being affected by the sections
> >>> moving.
> >> Based on the sparc change that accompanied this commit the following
> >> does seem to restore working order for me:
> >>
> >> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S
> >> index d575f945d422..e90b0f68290c 100644
> >> --- a/arch/mips/kernel/vmlinux.lds.S
> >> +++ b/arch/mips/kernel/vmlinux.lds.S
> >> @@ -62,6 +62,8 @@ SECTIONS
> >>           _text = .;      /* Text and read-only data */
> >>           _stext = .;
> >>           .text : {
> >> +               /* Match text section symbols in head.S first */
> >> +               *head.o(.text)
> >>                   TEXT_TEXT
> >>                   SCHED_TEXT
> >>                   LOCK_TEXT
> >>
> >> No idea if that's appropriate
> >>