linux-kernel - Re: [PATCH][bugzilla #8679] therm

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: <20070820220328.438e8a4d.akpm@linux-foundation.org>
Date:	Mon, 20 Aug 2007 22:03:28 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Satyam Sharma <satyam@...radead.org>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Randy Dunlap <randy.dunlap@...cle.com>, wbrana@...il.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][bugzilla #8679] therm_throt.c: Fix section mismatch

On Tue, 21 Aug 2007 10:07:31 +0530 (IST) Satyam Sharma <satyam@...radead.org> wrote:

> 
> WARNING: arch/i386/kernel/built-in.o(.data+0x2148): Section mismatch: reference
> to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mtrr_mutex')
> 
> comes because struct notifier_block thermal_throttle_cpu_notifier in
> arch/i386/kernel/cpu/mcheck/therm_throt.c goes in .data section but
> the notifier callback function itself has been marked __cpuinit which
> becomes __init == .init.text when HOTPLUG_CPU=n. The warning is bogus
> because the callback will never be called out if HOTPLUG_CPU=n in the
> first place (as one can see from kernel/cpu.c, the cpu_chain itself
> is __cpuinitdata :-)
> 
> So, let's mark thermal_throttle_cpu_notifier as __cpuinitdata to fix
> the section mismatch warning.
> 
> Signed-off-by: Satyam Sharma <satyam@...radead.org>
> 
> ---
> 
> [The other section mismatch mentioned in bugzilla #8679 is already fixed.]
> 
>  arch/i386/kernel/cpu/mcheck/therm_throt.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/i386/kernel/cpu/mcheck/therm_throt.c b/arch/i386/kernel/cpu/mcheck/therm_throt.c
> index 1203dc5..494d320 100644
> --- a/arch/i386/kernel/cpu/mcheck/therm_throt.c
> +++ b/arch/i386/kernel/cpu/mcheck/therm_throt.c
> @@ -152,7 +152,7 @@ static __cpuinit int thermal_throttle_cpu_callback(struct notifier_block *nfb,
>  	return NOTIFY_OK;
>  }
>  
> -static struct notifier_block thermal_throttle_cpu_notifier =
> +static struct notifier_block thermal_throttle_cpu_notifier __cpuinitdata =
>  {
>  	.notifier_call = thermal_throttle_cpu_callback,
>  };

okay...  However we're not being very consistent here.

register_hotcpu_notifier() is cunning.  If CONFIG_HOTPLUG_CPU=y, we need
the notifier block and the function to which it points to be in .data and
in .text.  If CONFIG_HOTPLUG_CPU=n, we don't need them to be present at all.

So what we can do is to just leave the notifier block in .data and the
function in .text and then the compiler/linker will notice that nothing
references them and they will be omitted at build time.

So basically, the register_hotcpu_notifier() implementation (in league with
the compiler) is taking the place of the manual notations.

Note that because this works at compile time, it is also effective within
modules.  I'm not sure that we discard the unneeded sections from within
modules? (I forget).

So...  what to do?  I guess for consistency one could hunt down all the
register_hotcpu_notifier() sites and remove all the __initfoo tags from all of
them.  But that makes register_hotcpu_notifier() inconsistent from
everything else, so there's an argument that we should make all these
things __cpuinit and __cpuinitdata for consistency rather than relying upon
register_hotcpu_notifier()'s magical properties as a special case.  Dunno.

<looks at blk_cpu_notifier>

There are a few things to clear up here...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/