linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
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>
Subject: Re: linux-next: build warning after merge of the arm64 tree
Date: Tue, 24 Oct 2023 15:42:20 +0200	[thread overview]
Message-ID: <CAMj1kXGSG0KLa0NNnMM-_zh+wEJm94b2zpHtkSeUi1hdxMYa_Q@mail.gmail.com> (raw)
In-Reply-To: <ZTeUhsf1xWmkJcRh@arm.com>

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;
>

  reply	other threads:[~2023-10-24 13:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-24  6:24 linux-next: build warning after merge of the arm64 tree Stephen Rothwell
2023-10-24  9:55 ` Catalin Marinas
2023-10-24 13:42   ` Ard Biesheuvel [this message]
2023-10-24 16:14     ` Catalin Marinas
  -- strict thread matches above, loose matches on Subject: below --
2023-06-13  6:23 Stephen Rothwell
2023-06-13 15:59 ` Catalin Marinas
2022-07-07  9:57 Stephen Rothwell
2022-07-07 10:28 ` Will Deacon
2022-03-09 11:34 Stephen Rothwell
2022-03-09 12:18 ` Will Deacon
2018-07-23 23:05 Stephen Rothwell
2018-07-24  0:26 ` AKASHI Takahiro
2018-07-24  8:12   ` Arnd Bergmann
2018-07-24  9:30     ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXGSG0KLa0NNnMM-_zh+wEJm94b2zpHtkSeUi1hdxMYa_Q@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).