All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: Nathan Chancellor <nathan@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: jpoimboe@kernel.org, peterz@infradead.org,
	linux-mips@vger.kernel.org,  linux-kernel@vger.kernel.org,
	llvm@lists.linux.dev, patches@lists.linux.dev
Subject: Re: [PATCH] MIPS: Mark check_bugs{,_early}() as __init
Date: Wed, 19 Apr 2023 15:03:31 -0700	[thread overview]
Message-ID: <CAKwvOdmuQBnZR_pB5bUdsF+OoB_4pxBT9TNFF83fZhzwZ1gbxw@mail.gmail.com> (raw)
In-Reply-To: <20230419-mips-check_bugs-init-attribute-v1-1-91e6eed55b89@kernel.org>

On Wed, Apr 19, 2023 at 11:43 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> After commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
> forcibly"), a compiler may choose not to inline a function marked with
> just 'inline'. If check_bugs() is not inlined into start_kernel(), which
> occurs when building with clang after commit 9ea7e6b62c2b ("init: Mark
> [arch_call_]rest_init() __noreturn"), modpost complains with:
>
>   WARNING: modpost: vmlinux.o: section mismatch in reference: check_bugs (section: .text) -> check_bugs32 (section: .init.text)
>
> check_bugs() is only called from start_kernel(), which itself is marked
> __init, so mark check_bugs() as __init as well to clear up the warning
> and make everything work properly.
>
> While there is currently no warning about check_bugs_early(), it could
> have the same problem, as it is called from arch_setup() and calls
> check_bugs64_early(), both marked __init. Mark it as __init for the same
> reason as above.
>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> NOTE: This is based on v6.3-rc7, as the issue shows up due to a patch in
> the tip tree, but this appears to be an ancient issue that could have
> showed up at any point (hence why no explicit Fixes tag), so I chose a
> base that should allow either the MIPS or tip folks to apply this patch.

Probably for the MIPS tree.

>
> Additionally, I was tempted to remove the explicit 'inline' since the
> compiler is free to do whatever it wants anyways but this is a static
> function in a header so we would need to add '__maybe_unused', which is
> already added with 'inline' in a normal build so I just left it alone.
> ---
>  arch/mips/include/asm/bugs.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/mips/include/asm/bugs.h b/arch/mips/include/asm/bugs.h
> index d72dc6e1cf3c..9b9bf9bc7d24 100644
> --- a/arch/mips/include/asm/bugs.h
> +++ b/arch/mips/include/asm/bugs.h
> @@ -24,13 +24,13 @@ extern void check_bugs64_early(void);
>  extern void check_bugs32(void);
>  extern void check_bugs64(void);
>
> -static inline void check_bugs_early(void)
> +static inline void __init check_bugs_early(void)
>  {
>         if (IS_ENABLED(CONFIG_CPU_R4X00_BUGS64))
>                 check_bugs64_early();
>  }

If the only call site is in arch/mips/kernel/setup.c, then perhaps we
can move the definition of check_bugs_early there and mark it static
__init and drop inline?

Unless we foresee other callers potentially in the future?  Patch
otherwise LGTM.  Thanks for the patch!

>
> -static inline void check_bugs(void)
> +static inline void __init check_bugs(void)
>  {
>         unsigned int cpu = smp_processor_id();
>
>
> ---
> base-commit: 6a8f57ae2eb07ab39a6f0ccad60c760743051026
> change-id: 20230419-mips-check_bugs-init-attribute-026103bdb255
>
> Best regards,
> --
> Nathan Chancellor <nathan@kernel.org>
>


-- 
Thanks,
~Nick Desaulniers

  reply	other threads:[~2023-04-19 22:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19 18:42 [PATCH] MIPS: Mark check_bugs{,_early}() as __init Nathan Chancellor
2023-04-19 22:03 ` Nick Desaulniers [this message]
2023-04-19 23:37   ` Nathan Chancellor
2023-04-21  7:27     ` Thomas Bogendoerfer

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=CAKwvOdmuQBnZR_pB5bUdsF+OoB_4pxBT9TNFF83fZhzwZ1gbxw@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=peterz@infradead.org \
    --cc=tsbogend@alpha.franken.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.