Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
MIME-Version: 1.0
References: <20231024172409.7b519868@canb.auug.org.au> <ZTeUhsf1xWmkJcRh@arm.com>
In-Reply-To: <ZTeUhsf1xWmkJcRh@arm.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Tue, 24 Oct 2023 15:42:20 +0200
Message-ID: <CAMj1kXGSG0KLa0NNnMM-_zh+wEJm94b2zpHtkSeUi1hdxMYa_Q@mail.gmail.com>
Subject: Re: linux-next: build warning after merge of the arm64 tree
To:     Catalin Marinas <catalin.marinas@arm.com>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Will Deacon <will@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 24 Oct 2023 at 11:55, Catalin Marinas <catalin.marinas@arm.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;
>