Re: [PATCH v2] RISC-V: fix sifive and thead section mismatches in errata

[Evan Green]

On Sat, Apr 29, 2023 at 10:58 AM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote:
>
>
>
> On 4/29/23 10:48, Evan Green wrote:
> > On Sat, Apr 29, 2023 at 10:24 AM Conor Dooley <conor@xxxxxxxxxx> wrote:
> >>
> >> On Sat, Apr 29, 2023 at 10:21:39AM -0700, Evan Green wrote:
> >>> On Sat, Apr 29, 2023 at 8:52 AM Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote:
> >>>>
> >>>> When CONFIG_MODULES is set, __init_or_module becomes <empty>, but when
> >>>> CONFIG_MODULES is not set, __init_or_module becomes __init.
> >>>> In the latter case, it causes section mismatch warnings:
> >>>>
> >>>> WARNING: modpost: vmlinux.o: section mismatch in reference: riscv_fill_cpu_mfr_info (section: .text) -> sifive_errata_patch_func (section: .init.text)
> >>>> WARNING: modpost: vmlinux.o: section mismatch in reference: riscv_fill_cpu_mfr_info (section: .text) -> thead_errata_patch_func (section: .init.text)
> >>>>
> >>>> Fixes: bb3f89487fd9 ("RISC-V: hwprobe: Remove __init on probe_vendor_features()")
> >>>> Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
> >>>> Cc: Heiko Stuebner <heiko@xxxxxxxxx>
> >>>> Cc: Paul Walmsley <paul.walmsley@xxxxxxxxxx>
> >>>> Cc: Palmer Dabbelt <palmer@xxxxxxxxxxx>
> >>>> Cc: Albert Ou <aou@xxxxxxxxxxxxxxxxx>
> >>>> Cc: linux-riscv@xxxxxxxxxxxxxxxxxxx
> >>>> Cc: Conor Dooley <conor@xxxxxxxxxx>
> >>>> Cc: Evan Green <evan@xxxxxxxxxxxx>
> >>>> ---
> >>>
> >>> Thanks, Randy. I'm confused at how I didn't see that when I made the
> >>> original fix. I feel like repro of these section mismatch errors
> >>> depend on some other factor I'm not understanding. In any case:
> >>
> >> Perhaps you had a cut-down config that did not enable either of the
> >> relevant ARCH_ options to get those errata compiled?
> >
> > It was weird, my original "fix" (the one listed in this Fixes tag) was
> > needed because while the hwprobe series was clean on Palmer's branch,
> > it generated a "section mismatch" on linux-next. As noted here, it was
> > only with !CONFIG_MODULES, so I explicitly remember generating that
> > config and checking it on linux-next to generate this "fix", and it
> > came out clean. It's like the robots are getting smarter.
> > -Evan
>
> I observed the problem in 8 out of 20 randconfig builds,
> using linux-next 20230427.

Oh interesting, so not the stock k210_nommu defconfig. That makes me
feel a little better at least.
-Evan