All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Baoquan He <bhe@redhat.com>,
	linux-kernel@vger.kernel.org, bp@alien8.de, x86@kernel.org
Subject: Re: [PATCH v2 1/2] x86/ioremap: introduce helper to implement xxx_is_setup_data()
Date: Wed, 20 Nov 2024 09:25:53 +0100	[thread overview]
Message-ID: <Zz2dEcLrCtXEq4cg@gmail.com> (raw)
In-Reply-To: <7cc5e26c-42fc-a700-ae19-608920cafe44@amd.com>


* Tom Lendacky <thomas.lendacky@amd.com> wrote:

> >  /*
> >   * Examine the physical address to determine if it is boot data by checking
> >   * it against the boot params setup_data chain.
> >   */
> > -static bool memremap_is_setup_data(resource_size_t phys_addr,
> > -				   unsigned long size)
> > +static bool __ref __memremap_is_setup_data(resource_size_t phys_addr,
> 
> Oh, I see why the __ref is needed now, because this calls an __init
> function based on the early bool.
> 
> While this nicely consolidates the checking, I'll let the x86
> maintainers decide whether they like that an __init function is calling
> a non __init function.

So why would it be a problem? Only non-__init calling __init is a bug, 
because __init functions cease to exist after early bootup. Also, 
calling certain kernel subsystems too early, before they are 
initialized, is a bug as well.

But calling non-__init functions that have initialized already is like 
totally normal: printk() for example, but also all locking facilities, 
etc.

Am I missing anything here?

Thanks,

	Ingo

  parent reply	other threads:[~2024-11-20  8:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18  1:08 [PATCH v2 0/2] x86/ioremap: clean up the mess in xxx_is_setup_data Baoquan He
2024-11-18  1:08 ` [PATCH v2 1/2] x86/ioremap: introduce helper to implement xxx_is_setup_data() Baoquan He
2024-11-18 15:19   ` Tom Lendacky
2024-11-19  3:07     ` Baoquan He
2024-11-19 10:55       ` Ingo Molnar
2024-11-20  7:21         ` Baoquan He
2024-11-20  7:56       ` Baoquan He
2024-11-20  8:25     ` Ingo Molnar [this message]
2024-11-20 14:14       ` Tom Lendacky
2024-11-25  9:07         ` Ingo Molnar
2024-11-26  8:15           ` Baoquan He
2024-11-18  1:08 ` [PATCH v2 2/2] x86/mm: clean up unused parameters of functions Baoquan He

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=Zz2dEcLrCtXEq4cg@gmail.com \
    --to=mingo@kernel.org \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@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 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.