linux-kernel - Re: [PATCH v2 1/2] x86/ioremap: introduce helper to implement xxx_is_setup

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: <Zz2dEcLrCtXEq4cg@gmail.com>
Date: Wed, 20 Nov 2024 09:25:53 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: Baoquan He <bhe@...hat.com>, linux-kernel@...r.kernel.org, bp@...en8.de,
	x86@...nel.org
Subject: Re: [PATCH v2 1/2] x86/ioremap: introduce helper to implement
 xxx_is_setup_data()


* Tom Lendacky <thomas.lendacky@....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