linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] powerpc: Set paca->data_offset = 0 for boot cpu
@ 2012-09-21  8:07 Michael Ellerman
  2012-09-21  8:37 ` Aneesh Kumar K.V
  0 siblings, 1 reply; 2+ messages in thread
From: Michael Ellerman @ 2012-09-21  8:07 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: aneesh.kumar

In commit 407821a we assigned a poison value to the paca->data_offset.

Unfortunately with CONFIG_LOCK_STAT=y lockdep will read & write to percpu
data very early in boot, prior to us initialising the percpu areas,
leading to a crash.

We have been getting away with this because the data_offset was previously
set to zero. This causes lockdep to read & write to the initial copy of
the percpu variables, which are discarded later in boot.

Although that is "fishy", it does work, and for lock statistics it is no
big deal to discard the counts from early boot.

So set the paca->data_offset = 0 for the boot cpu paca only.

Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
 arch/powerpc/kernel/setup_64.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 389bd4f..efb6a41 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -208,6 +208,8 @@ void __init early_setup(unsigned long dt_ptr)
 
 	/* Fix up paca fields required for the boot cpu */
 	get_paca()->cpu_start = 1;
+	/* Allow percpu accesses to "work" until we setup percpu data */
+	get_paca()->data_offset = 0;
 
 	/* Probe the machine type */
 	probe_machine();
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] powerpc: Set paca->data_offset = 0 for boot cpu
  2012-09-21  8:07 [PATCH] powerpc: Set paca->data_offset = 0 for boot cpu Michael Ellerman
@ 2012-09-21  8:37 ` Aneesh Kumar K.V
  0 siblings, 0 replies; 2+ messages in thread
From: Aneesh Kumar K.V @ 2012-09-21  8:37 UTC (permalink / raw)
  To: Michael Ellerman, linuxppc-dev

Michael Ellerman <michael@ellerman.id.au> writes:

> In commit 407821a we assigned a poison value to the paca->data_offset.
>
> Unfortunately with CONFIG_LOCK_STAT=y lockdep will read & write to percpu
> data very early in boot, prior to us initialising the percpu areas,
> leading to a crash.
>
> We have been getting away with this because the data_offset was previously
> set to zero. This causes lockdep to read & write to the initial copy of
> the percpu variables, which are discarded later in boot.
>
> Although that is "fishy", it does work, and for lock statistics it is no
> big deal to discard the counts from early boot.
>
> So set the paca->data_offset = 0 for the boot cpu paca only.
>
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>

Tested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

> ---
>  arch/powerpc/kernel/setup_64.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 389bd4f..efb6a41 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -208,6 +208,8 @@ void __init early_setup(unsigned long dt_ptr)
>
>  	/* Fix up paca fields required for the boot cpu */
>  	get_paca()->cpu_start = 1;
> +	/* Allow percpu accesses to "work" until we setup percpu data */
> +	get_paca()->data_offset = 0;
>
>  	/* Probe the machine type */
>  	probe_machine();
> -- 
> 1.7.9.5

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-09-21  8:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-21  8:07 [PATCH] powerpc: Set paca->data_offset = 0 for boot cpu Michael Ellerman
2012-09-21  8:37 ` Aneesh Kumar K.V

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).