From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Scott Wood <scottwood@freescale.com>
Cc: Neil Horman <nhorman@tuxdriver.com>,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
Date: Mon, 15 Jul 2013 18:47:06 +1000 [thread overview]
Message-ID: <1373878026.19894.335.camel@pasglop> (raw)
In-Reply-To: <20130715140450.573aab15@kryten>
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> Module CRCs are implemented as absolute symbols that get resolved by
> a linker script. We build an intermediate .o that contains an
> unresolved symbol for each CRC. genksysms parses this .o, calculates
> the CRCs and writes a linker script that "resolves" the symbols to
> the calc
Scott, can somebody from FSL test that on 32-bit and Ack it ?
Thanks !
Cheers,
Ben.
> Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
> that need relocating and relocates them at boot. Commit d4703aef
> (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
> added a hook to reverse the bogus relocations. Part of this patch
> created a symbol at 0x0:
>
> # head -2 /proc/kallsyms
> 0000000000000000 T reloc_start
> c000000000000000 T .__start
>
> This reloc_start symbol is causing lots of confusion to perf. It
> thinks reloc_start is a massive function that stretches from 0x0 to
> 0xc000000000000000 and we get various cryptic errors out of perf,
> including:
>
> problem incrementing symbol count, skipping event
>
> This patch removes the reloc_start linker script label and instead
> defines it as PHYSICAL_START. We also need to wrap it with
> CONFIG_PPC64 because the ppc32 kernel can set a non zero
> PHYSICAL_START at compile time and we wouldn't want to subtract
> it from the CRCs in that case.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Cc: <stable@kernel.org>
> ---
>
> This bug was originally reported on Fedora 19 (3.9.x), so I've marked
> it for stable.
>
> Index: b/arch/powerpc/include/asm/module.h
> ===================================================================
> --- a/arch/powerpc/include/asm/module.h
> +++ b/arch/powerpc/include/asm/module.h
> @@ -82,10 +82,9 @@ struct exception_table_entry;
> void sort_ex_table(struct exception_table_entry *start,
> struct exception_table_entry *finish);
>
> -#ifdef CONFIG_MODVERSIONS
> +#if defined(CONFIG_MODVERSIONS) && defined(CONFIG_PPC64)
> #define ARCH_RELOCATES_KCRCTAB
> -
> -extern const unsigned long reloc_start[];
> +#define reloc_start PHYSICAL_START
> #endif
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_MODULE_H */
> Index: b/arch/powerpc/kernel/vmlinux.lds.S
> ===================================================================
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -38,9 +38,6 @@ jiffies = jiffies_64 + 4;
> #endif
> SECTIONS
> {
> - . = 0;
> - reloc_start = .;
> -
> . = KERNELBASE;
>
> /*
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Scott Wood <scottwood@freescale.com>
Cc: Paul Mackerras <paulus@samba.org>,
Rusty Russell <rusty@rustcorp.com.au>,
Neil Horman <nhorman@tuxdriver.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Anton Blanchard <anton@samba.org>
Subject: Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
Date: Mon, 15 Jul 2013 18:47:06 +1000 [thread overview]
Message-ID: <1373878026.19894.335.camel@pasglop> (raw)
In-Reply-To: <20130715140450.573aab15@kryten>
On Mon, 2013-07-15 at 14:04 +1000, Anton Blanchard wrote:
> Module CRCs are implemented as absolute symbols that get resolved by
> a linker script. We build an intermediate .o that contains an
> unresolved symbol for each CRC. genksysms parses this .o, calculates
> the CRCs and writes a linker script that "resolves" the symbols to
> the calc
Scott, can somebody from FSL test that on 32-bit and Ack it ?
Thanks !
Cheers,
Ben.
> Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
> that need relocating and relocates them at boot. Commit d4703aef
> (module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
> added a hook to reverse the bogus relocations. Part of this patch
> created a symbol at 0x0:
>
> # head -2 /proc/kallsyms
> 0000000000000000 T reloc_start
> c000000000000000 T .__start
>
> This reloc_start symbol is causing lots of confusion to perf. It
> thinks reloc_start is a massive function that stretches from 0x0 to
> 0xc000000000000000 and we get various cryptic errors out of perf,
> including:
>
> problem incrementing symbol count, skipping event
>
> This patch removes the reloc_start linker script label and instead
> defines it as PHYSICAL_START. We also need to wrap it with
> CONFIG_PPC64 because the ppc32 kernel can set a non zero
> PHYSICAL_START at compile time and we wouldn't want to subtract
> it from the CRCs in that case.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Cc: <stable@kernel.org>
> ---
>
> This bug was originally reported on Fedora 19 (3.9.x), so I've marked
> it for stable.
>
> Index: b/arch/powerpc/include/asm/module.h
> ===================================================================
> --- a/arch/powerpc/include/asm/module.h
> +++ b/arch/powerpc/include/asm/module.h
> @@ -82,10 +82,9 @@ struct exception_table_entry;
> void sort_ex_table(struct exception_table_entry *start,
> struct exception_table_entry *finish);
>
> -#ifdef CONFIG_MODVERSIONS
> +#if defined(CONFIG_MODVERSIONS) && defined(CONFIG_PPC64)
> #define ARCH_RELOCATES_KCRCTAB
> -
> -extern const unsigned long reloc_start[];
> +#define reloc_start PHYSICAL_START
> #endif
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_MODULE_H */
> Index: b/arch/powerpc/kernel/vmlinux.lds.S
> ===================================================================
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -38,9 +38,6 @@ jiffies = jiffies_64 + 4;
> #endif
> SECTIONS
> {
> - . = 0;
> - reloc_start = .;
> -
> . = KERNELBASE;
>
> /*
next prev parent reply other threads:[~2013-07-15 8:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-15 4:04 [PATCH] module: ppc64 module CRC relocation fix causes perf issues Anton Blanchard
2013-07-15 4:39 ` Rusty Russell
2013-07-15 8:47 ` Benjamin Herrenschmidt [this message]
2013-07-15 8:47 ` Benjamin Herrenschmidt
2013-07-16 22:40 ` Scott Wood
2013-07-16 22:40 ` Scott Wood
2013-07-17 0:04 ` Benjamin Herrenschmidt
2013-07-17 0:04 ` Benjamin Herrenschmidt
2013-07-17 0:08 ` Scott Wood
2013-07-17 0:08 ` Scott Wood
2013-07-18 4:00 ` Anton Blanchard
2013-07-18 4:00 ` Anton Blanchard
2013-07-19 22:59 ` Scott Wood
2013-07-19 22:59 ` Scott Wood
2013-07-23 13:30 ` Michael Ellerman
2013-07-23 13:30 ` Michael Ellerman
2013-07-24 19:22 ` Scott Wood
2013-07-24 19:22 ` Scott Wood
2013-07-24 22:34 ` Anton Blanchard
2013-07-24 22:34 ` Anton Blanchard
2013-07-24 23:14 ` Benjamin Herrenschmidt
2013-07-24 23:14 ` Benjamin Herrenschmidt
2013-07-25 13:02 ` Neil Horman
2013-07-25 13:02 ` Neil Horman
2013-07-26 1:19 ` Anton Blanchard
2013-07-26 1:19 ` Anton Blanchard
2013-07-26 13:11 ` Neil Horman
2013-07-26 13:11 ` Neil Horman
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=1373878026.19894.335.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nhorman@tuxdriver.com \
--cc=paulus@samba.org \
--cc=rusty@rustcorp.com.au \
--cc=scottwood@freescale.com \
/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.