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: <CAMj1kXGSG0KLa0NNnMM-_zh+wEJm94b2zpHtkSeUi1hdxMYa_Q@mail.gmail.com>
Date:   Tue, 24 Oct 2023 15:42:20 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Will Deacon <will@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build warning after merge of the arm64 tree

On Tue, 24 Oct 2023 at 11:55, Catalin Marinas <catalin.marinas@....com> wrote:
>
> + Ard
>
> On Tue, Oct 24, 2023 at 05:24:09PM +1100, Stephen Rothwell wrote:
> > After merging the arm64 tree, today's linux-next build (arm64 defconfig)
> > produced this warning:
> >
> > WARNING: modpost: vmlinux: section mismatch in reference: __pi_$x+0x38 (section: .text) -> __pi_map_range (section: .init.text)
> >
> > I don't know what caused this.
>
> For some reason, building linux-next doesn't inline all the functions in
> the map_range.c file and we end up with some of them in different
> sections. I didn't get this when building the arm64 for-next/core
> separately.
>

Strange, I never ran into this before.

I guess commit 24cc769d70d8bda055a028aa6a is implicated in this, if we
run into more trouble like this i'll look whether we can bring that
logic back in some way.

The fix looks fine to me.


> My fix (I'll push it to the arm64 branch):
>
> diff --git a/arch/arm64/kernel/pi/map_kernel.c b/arch/arm64/kernel/pi/map_kernel.c
> index be7caf07bfa7..e07f3ece5430 100644
> --- a/arch/arm64/kernel/pi/map_kernel.c
> +++ b/arch/arm64/kernel/pi/map_kernel.c
> @@ -20,17 +20,17 @@ extern const u8 __eh_frame_start[], __eh_frame_end[];
>
>  extern void idmap_cpu_replace_ttbr1(void *pgdir);
>
> -static void map_segment(pgd_t *pg_dir, u64 *pgd, u64 va_offset,
> -                       void *start, void *end, pgprot_t prot,
> -                       bool may_use_cont, int root_level)
> +static void __init map_segment(pgd_t *pg_dir, u64 *pgd, u64 va_offset,
> +                              void *start, void *end, pgprot_t prot,
> +                              bool may_use_cont, int root_level)
>  {
>         map_range(pgd, ((u64)start + va_offset) & ~PAGE_OFFSET,
>                   ((u64)end + va_offset) & ~PAGE_OFFSET, (u64)start,
>                   prot, root_level, (pte_t *)pg_dir, may_use_cont, 0);
>  }
>
> -static void unmap_segment(pgd_t *pg_dir, u64 va_offset, void *start,
> -                         void *end, int root_level)
> +static void __init unmap_segment(pgd_t *pg_dir, u64 va_offset, void *start,
> +                                void *end, int root_level)
>  {
>         map_segment(pg_dir, NULL, va_offset, start, end, __pgprot(0),
>                     false, root_level);
> @@ -205,7 +205,7 @@ static void __init remap_idmap_for_lpa2(void)
>         memset(init_pg_dir, 0, (u64)init_pg_end - (u64)init_pg_dir);
>  }
>
> -static void map_fdt(u64 fdt)
> +static void __init map_fdt(u64 fdt)
>  {
>         static u8 ptes[INIT_IDMAP_FDT_SIZE] __initdata __aligned(PAGE_SIZE);
>         u64 efdt = fdt + MAX_FDT_SIZE;
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ