* Re: BUG: spinlock bad magic on CPU#0 on BeagleBone
[not found] ` <alpine.DEB.2.00.1212191650430.16873@utopia.booyaka.com>
@ 2012-12-19 20:23 ` Stephen Boyd
2012-12-20 4:48 ` Bedia, Vaibhav
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Boyd @ 2012-12-19 20:23 UTC (permalink / raw)
To: Paul Walmsley
Cc: Bedia, Vaibhav, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List
On 12/19/12 08:53, Paul Walmsley wrote:
> On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
>
>> Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes
>> is triggering a BUG()
> ...
>
>> [ 0.109688] Security Framework initialized
>> [ 0.109889] Mount-cache hash table entries: 512
>> [ 0.112674] BUG: spinlock bad magic on CPU#0, swapper/0/0
>> [ 0.112724] lock: atomic64_lock+0x240/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>> [ 0.112782] [<c001af64>] (unwind_backtrace+0x0/0xf0) from [<c02c2010>] (do_raw_spin_lock+0x158/0x198)
>> [ 0.112813] [<c02c2010>] (do_raw_spin_lock+0x158/0x198) from [<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58)
>> [ 0.112844] [<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c02cabf0>] (atomic64_add_return+0x30/0x5c)
>> [ 0.112886] [<c02cabf0>] (atomic64_add_return+0x30/0x5c) from [<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac)
>> [ 0.112914] [<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac) from [<c0124f4c>] (create_mnt_ns+0xc/0x54)
>> [ 0.112951] [<c0124f4c>] (create_mnt_ns+0xc/0x54) from [<c06f31a4>] (mnt_init+0x120/0x1d4)
>> [ 0.112978] [<c06f31a4>] (mnt_init+0x120/0x1d4) from [<c06f2d50>] (vfs_caches_init+0xe0/0x10c)
>> [ 0.113005] [<c06f2d50>] (vfs_caches_init+0xe0/0x10c) from [<c06d4798>] (start_kernel+0x29c/0x300)
>> [ 0.113029] [<c06d4798>] (start_kernel+0x29c/0x300) from [<80008078>] (0x80008078)
>> [ 0.118290] CPU: Testing write buffer coherency: ok
>> [ 0.118968] CPU0: thread -1, cpu 0, socket -1, mpidr 0
>> [ 0.119053] Setting up static identity map for 0x804de2c8 - 0x804de338
>> [ 0.120698] Brought up 1 CPUs
> This is probably a memory corruption bug, there's probably some code
> executing early that's writing outside its own data and trashing some
> previously-allocated memory.
I'm not so sure. It looks like atomic64s use spinlocks on processors
that don't have 64-bit atomic instructions (see lib/atomic64.c). And
those spinlocks are not initialized until a pure initcall runs,
init_atomic64_lock(). Pure initcalls don't run until after
vfs_caches_init() and so you get this BUG() warning that the spinlock is
not initialized.
How about we initialize the locks statically? Does that fix your problem?
---->8-----
diff --git a/lib/atomic64.c b/lib/atomic64.c
index 9785378..08a4f06 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -31,7 +31,11 @@
static union {
raw_spinlock_t lock;
char pad[L1_CACHE_BYTES];
-} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
+ [0 ... (NR_LOCKS - 1)] = {
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
+ },
+};
static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
{
@@ -173,14 +177,3 @@ int atomic64_add_unless(atomic64_t *v, long long a, long long u)
return ret;
}
EXPORT_SYMBOL(atomic64_add_unless);
-
-static int init_atomic64_lock(void)
-{
- int i;
-
- for (i = 0; i < NR_LOCKS; ++i)
- raw_spin_lock_init(&atomic64_lock[i].lock);
- return 0;
-}
-
-pure_initcall(init_atomic64_lock);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 7+ messages in thread
* RE: BUG: spinlock bad magic on CPU#0 on BeagleBone
2012-12-19 20:23 ` BUG: spinlock bad magic on CPU#0 on BeagleBone Stephen Boyd
@ 2012-12-20 4:48 ` Bedia, Vaibhav
2012-12-20 6:25 ` Stephen Boyd
0 siblings, 1 reply; 7+ messages in thread
From: Bedia, Vaibhav @ 2012-12-20 4:48 UTC (permalink / raw)
To: Stephen Boyd, Paul Walmsley
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Linux Kernel Mailing List
On Thu, Dec 20, 2012 at 01:53:42, Stephen Boyd wrote:
> On 12/19/12 08:53, Paul Walmsley wrote:
> > On Wed, 19 Dec 2012, Bedia, Vaibhav wrote:
> >
> >> Current mainline on Beaglebone using the omap2plus_defconfig + 3 build fixes
> >> is triggering a BUG()
> > ...
> >
> >> [ 0.109688] Security Framework initialized
> >> [ 0.109889] Mount-cache hash table entries: 512
> >> [ 0.112674] BUG: spinlock bad magic on CPU#0, swapper/0/0
> >> [ 0.112724] lock: atomic64_lock+0x240/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> >> [ 0.112782] [<c001af64>] (unwind_backtrace+0x0/0xf0) from [<c02c2010>] (do_raw_spin_lock+0x158/0x198)
> >> [ 0.112813] [<c02c2010>] (do_raw_spin_lock+0x158/0x198) from [<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58)
> >> [ 0.112844] [<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c02cabf0>] (atomic64_add_return+0x30/0x5c)
> >> [ 0.112886] [<c02cabf0>] (atomic64_add_return+0x30/0x5c) from [<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac)
> >> [ 0.112914] [<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac) from [<c0124f4c>] (create_mnt_ns+0xc/0x54)
> >> [ 0.112951] [<c0124f4c>] (create_mnt_ns+0xc/0x54) from [<c06f31a4>] (mnt_init+0x120/0x1d4)
> >> [ 0.112978] [<c06f31a4>] (mnt_init+0x120/0x1d4) from [<c06f2d50>] (vfs_caches_init+0xe0/0x10c)
> >> [ 0.113005] [<c06f2d50>] (vfs_caches_init+0xe0/0x10c) from [<c06d4798>] (start_kernel+0x29c/0x300)
> >> [ 0.113029] [<c06d4798>] (start_kernel+0x29c/0x300) from [<80008078>] (0x80008078)
> >> [ 0.118290] CPU: Testing write buffer coherency: ok
> >> [ 0.118968] CPU0: thread -1, cpu 0, socket -1, mpidr 0
> >> [ 0.119053] Setting up static identity map for 0x804de2c8 - 0x804de338
> >> [ 0.120698] Brought up 1 CPUs
> > This is probably a memory corruption bug, there's probably some code
> > executing early that's writing outside its own data and trashing some
> > previously-allocated memory.
>
> I'm not so sure. It looks like atomic64s use spinlocks on processors
> that don't have 64-bit atomic instructions (see lib/atomic64.c). And
> those spinlocks are not initialized until a pure initcall runs,
> init_atomic64_lock(). Pure initcalls don't run until after
> vfs_caches_init() and so you get this BUG() warning that the spinlock is
> not initialized.
>
> How about we initialize the locks statically? Does that fix your problem?
>
> ---->8-----
>
> diff --git a/lib/atomic64.c b/lib/atomic64.c
> index 9785378..08a4f06 100644
> --- a/lib/atomic64.c
> +++ b/lib/atomic64.c
> @@ -31,7 +31,11 @@
> static union {
> raw_spinlock_t lock;
> char pad[L1_CACHE_BYTES];
> -} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
> +} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
> + [0 ... (NR_LOCKS - 1)] = {
> + .lock = __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
> + },
> +};
>
> static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
> {
> @@ -173,14 +177,3 @@ int atomic64_add_unless(atomic64_t *v, long long a, long long u)
> return ret;
> }
> EXPORT_SYMBOL(atomic64_add_unless);
> -
> -static int init_atomic64_lock(void)
> -{
> - int i;
> -
> - for (i = 0; i < NR_LOCKS; ++i)
> - raw_spin_lock_init(&atomic64_lock[i].lock);
> - return 0;
> -}
> -
> -pure_initcall(init_atomic64_lock);
>
I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have DDR2
and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point.
With Stephen's change I don't see this on any of the board variants :)
New bootlog below.
Thanks,
Vaibhav
---
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.7.0-01415-g55bc169-dirty (a0393953@psplinux063) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #4 SMP Thu Dec 20 09:59:12 IST 2012
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f1a000 s12992 r8192 d15680 u36864
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768
[ 0.000000] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536 earlyprintk=serial
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Memory: 255MB = 255MB total
[ 0.000000] Memory: 229012k/229012k available, 33132k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc06d3f34 (6960 kB)
[ 0.000000] .init : 0xc06d4000 - 0xc07252c0 ( 325 kB)
[ 0.000000] .data : 0xc0726000 - 0xc07b6068 ( 577 kB)
[ 0.000000] .bss : 0xc07b608c - 0xc0d10af0 (5483 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768
[ 0.000000] ... CHAINHASH_SIZE: 16384
[ 0.000000] memory used by lock dependency info: 3695 kB
[ 0.000000] per task-struct memory footprint: 1152 bytes
[ 0.001226] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)
[ 0.109077] pid_max: default: 32768 minimum: 301
[ 0.109684] Security Framework initialized
[ 0.109889] Mount-cache hash table entries: 512
[ 0.122121] CPU: Testing write buffer coherency: ok
[ 0.123909] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.124001] Setting up static identity map for 0x804de288 - 0x804de2f8
[ 0.127162] Brought up 1 CPUs
[ 0.127192] SMP: Total of 1 processors activated (364.48 BogoMIPS).
[ 0.206604] pinctrl core: initialized pinctrl subsystem
[...]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BUG: spinlock bad magic on CPU#0 on BeagleBone
2012-12-20 4:48 ` Bedia, Vaibhav
@ 2012-12-20 6:25 ` Stephen Boyd
2012-12-20 6:44 ` Bedia, Vaibhav
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Boyd @ 2012-12-20 6:25 UTC (permalink / raw)
To: Bedia, Vaibhav
Cc: Paul Walmsley, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List
On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote:
> I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have DDR2
> and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point.
>
> With Stephen's change I don't see this on any of the board variants :)
> New bootlog below.
Great! Can I have your Tested-by then? I'll wrap it up into a patch. Is
this is a new regression? From a glance at the code it looks to have
existed for quite a while now.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: BUG: spinlock bad magic on CPU#0 on BeagleBone
2012-12-20 6:25 ` Stephen Boyd
@ 2012-12-20 6:44 ` Bedia, Vaibhav
2012-12-20 7:07 ` Stephen Boyd
0 siblings, 1 reply; 7+ messages in thread
From: Bedia, Vaibhav @ 2012-12-20 6:44 UTC (permalink / raw)
To: Stephen Boyd
Cc: Paul Walmsley, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List
On Thu, Dec 20, 2012 at 11:55:24, Stephen Boyd wrote:
> On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote:
> > I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have DDR2
> > and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point.
> >
> > With Stephen's change I don't see this on any of the board variants :)
> > New bootlog below.
>
> Great! Can I have your Tested-by then? I'll wrap it up into a patch. Is
> this is a new regression? From a glance at the code it looks to have
> existed for quite a while now.
I went back to a branch based off 3.7-rc4 and don't see the issue there. Not sure
what is triggering this now.
Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: BUG: spinlock bad magic on CPU#0 on BeagleBone
2012-12-20 6:44 ` Bedia, Vaibhav
@ 2012-12-20 7:07 ` Stephen Boyd
2012-12-20 7:39 ` [PATCH] lib: atomic64: Initialize locks statically to fix early users Stephen Boyd
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Boyd @ 2012-12-20 7:07 UTC (permalink / raw)
To: Bedia, Vaibhav
Cc: Paul Walmsley, linux-omap@vger.kernel.org,
Linux Kernel Mailing List, linux-arm-kernel@lists.infradead.org,
Eric W. Biederman
On 12/19/2012 10:44 PM, Bedia, Vaibhav wrote:
> On Thu, Dec 20, 2012 at 11:55:24, Stephen Boyd wrote:
>> On 12/19/2012 8:48 PM, Bedia, Vaibhav wrote:
>>> I tried out 3 variants of AM335x boards - 2 of these (BeagleBone and EVM) have DDR2
>>> and 1 has DDR3 (EVM-SK). The BUG is triggered on all of these at the same point.
>>>
>>> With Stephen's change I don't see this on any of the board variants :)
>>> New bootlog below.
>> Great! Can I have your Tested-by then? I'll wrap it up into a patch. Is
>> this is a new regression? From a glance at the code it looks to have
>> existed for quite a while now.
> I went back to a branch based off 3.7-rc4 and don't see the issue there. Not sure
> what is triggering this now.
>
> Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Thanks. I was thrown off by the author date of this patch which
introduced your problem
commit 8823c079ba7136dc1948d6f6dcb5f8022bde438e
Author: Eric W. Biederman <ebiederm@xmission.com>
AuthorDate: Sun Mar 7 18:49:36 2010 -0800
Commit: Eric W. Biederman <ebiederm@xmission.com>
CommitDate: Mon Nov 19 05:59:18 2012 -0800
vfs: Add setns support for the mount namespace
It seems to have a 2 year gap between commit date and author date.
Either way, it looks to be isolated to the 3.8 merge window but affects
quite a few architectures. Patch to follow shortly.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] lib: atomic64: Initialize locks statically to fix early users
2012-12-20 7:07 ` Stephen Boyd
@ 2012-12-20 7:39 ` Stephen Boyd
2012-12-20 19:06 ` Tony Lindgren
0 siblings, 1 reply; 7+ messages in thread
From: Stephen Boyd @ 2012-12-20 7:39 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-arm-msm, linux-arm-kernel, linux-omap, paul,
vaibhav.bedia, Eric W. Biederman
The atomic64 library uses a handful of static spin locks to
implement atomic 64-bit operations on architectures without
support for atomic 64-bit instructions. Unfortunately, the
spinlocks are initialized in a pure initcall and that is too late
for the vfs namespace code which wants to use atomic64 operations
before the initcall is run (introduced by 8823c07 "vfs: Add setns
support for the mount namespace").
This leads to BUG messages such as:
BUG: spinlock bad magic on CPU#0, swapper/0/0
lock: atomic64_lock+0x240/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[<c001af64>] (unwind_backtrace+0x0/0xf0) from [<c02c2010>] (do_raw_spin_lock+0x158/0x198)
[<c02c2010>] (do_raw_spin_lock+0x158/0x198) from [<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58)
[<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c02cabf0>] (atomic64_add_return+0x30/0x5c)
[<c02cabf0>] (atomic64_add_return+0x30/0x5c) from [<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac)
[<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac) from [<c0124f4c>] (create_mnt_ns+0xc/0x54)
[<c0124f4c>] (create_mnt_ns+0xc/0x54) from [<c06f31a4>] (mnt_init+0x120/0x1d4)
[<c06f31a4>] (mnt_init+0x120/0x1d4) from [<c06f2d50>] (vfs_caches_init+0xe0/0x10c)
[<c06f2d50>] (vfs_caches_init+0xe0/0x10c) from [<c06d4798>] (start_kernel+0x29c/0x300)
[<c06d4798>] (start_kernel+0x29c/0x300) from [<80008078>] (0x80008078)
coming out early on during boot when spinlock debugging is enabled.
Fix this problem by initializing the spinlocks statically at
compile time.
Reported-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Sorry Andrew, I couldn't find a maintainer of this file so I
am picking on you.
lib/atomic64.c | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/lib/atomic64.c b/lib/atomic64.c
index 9785378..08a4f06 100644
--- a/lib/atomic64.c
+++ b/lib/atomic64.c
@@ -31,7 +31,11 @@
static union {
raw_spinlock_t lock;
char pad[L1_CACHE_BYTES];
-} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
+ [0 ... (NR_LOCKS - 1)] = {
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
+ },
+};
static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
{
@@ -173,14 +177,3 @@ int atomic64_add_unless(atomic64_t *v, long long a, long long u)
return ret;
}
EXPORT_SYMBOL(atomic64_add_unless);
-
-static int init_atomic64_lock(void)
-{
- int i;
-
- for (i = 0; i < NR_LOCKS; ++i)
- raw_spin_lock_init(&atomic64_lock[i].lock);
- return 0;
-}
-
-pure_initcall(init_atomic64_lock);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] lib: atomic64: Initialize locks statically to fix early users
2012-12-20 7:39 ` [PATCH] lib: atomic64: Initialize locks statically to fix early users Stephen Boyd
@ 2012-12-20 19:06 ` Tony Lindgren
0 siblings, 0 replies; 7+ messages in thread
From: Tony Lindgren @ 2012-12-20 19:06 UTC (permalink / raw)
To: Stephen Boyd
Cc: Andrew Morton, linux-kernel, linux-arm-msm, linux-arm-kernel,
linux-omap, paul, vaibhav.bedia, Eric W. Biederman,
Linus Torvalds, Benjamin Herrenschmidt, David Miller
* Stephen Boyd <sboyd@codeaurora.org> [121219 23:42]:
> The atomic64 library uses a handful of static spin locks to
> implement atomic 64-bit operations on architectures without
> support for atomic 64-bit instructions. Unfortunately, the
> spinlocks are initialized in a pure initcall and that is too late
> for the vfs namespace code which wants to use atomic64 operations
> before the initcall is run (introduced by 8823c07 "vfs: Add setns
> support for the mount namespace").
>
> This leads to BUG messages such as:
>
> BUG: spinlock bad magic on CPU#0, swapper/0/0
> lock: atomic64_lock+0x240/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> [<c001af64>] (unwind_backtrace+0x0/0xf0) from [<c02c2010>] (do_raw_spin_lock+0x158/0x198)
> [<c02c2010>] (do_raw_spin_lock+0x158/0x198) from [<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58)
> [<c04d89ec>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c02cabf0>] (atomic64_add_return+0x30/0x5c)
> [<c02cabf0>] (atomic64_add_return+0x30/0x5c) from [<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac)
> [<c0124564>] (alloc_mnt_ns.clone.14+0x44/0xac) from [<c0124f4c>] (create_mnt_ns+0xc/0x54)
> [<c0124f4c>] (create_mnt_ns+0xc/0x54) from [<c06f31a4>] (mnt_init+0x120/0x1d4)
> [<c06f31a4>] (mnt_init+0x120/0x1d4) from [<c06f2d50>] (vfs_caches_init+0xe0/0x10c)
> [<c06f2d50>] (vfs_caches_init+0xe0/0x10c) from [<c06d4798>] (start_kernel+0x29c/0x300)
> [<c06d4798>] (start_kernel+0x29c/0x300) from [<80008078>] (0x80008078)
>
> coming out early on during boot when spinlock debugging is enabled.
>
> Fix this problem by initializing the spinlocks statically at
> compile time.
>
> Reported-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> Tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> Sorry Andrew, I couldn't find a maintainer of this file so I
> am picking on you.
Works for me:
Tested-by: Tony Lindgren <tony@atomide.com>
Added Linus, Benjamin and David to Cc as this came up on the ARM list.
> lib/atomic64.c | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/lib/atomic64.c b/lib/atomic64.c
> index 9785378..08a4f06 100644
> --- a/lib/atomic64.c
> +++ b/lib/atomic64.c
> @@ -31,7 +31,11 @@
> static union {
> raw_spinlock_t lock;
> char pad[L1_CACHE_BYTES];
> -} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
> +} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp = {
> + [0 ... (NR_LOCKS - 1)] = {
> + .lock = __RAW_SPIN_LOCK_UNLOCKED(atomic64_lock.lock),
> + },
> +};
>
> static inline raw_spinlock_t *lock_addr(const atomic64_t *v)
> {
> @@ -173,14 +177,3 @@ int atomic64_add_unless(atomic64_t *v, long long a, long long u)
> return ret;
> }
> EXPORT_SYMBOL(atomic64_add_unless);
> -
> -static int init_atomic64_lock(void)
> -{
> - int i;
> -
> - for (i = 0; i < NR_LOCKS; ++i)
> - raw_spin_lock_init(&atomic64_lock[i].lock);
> - return 0;
> -}
> -
> -pure_initcall(init_atomic64_lock);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-12-20 19:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <B5906170F1614E41A8A28DE3B8D121433EC9A69C@DBDE01.ent.ti.com>
[not found] ` <alpine.DEB.2.00.1212191650430.16873@utopia.booyaka.com>
2012-12-19 20:23 ` BUG: spinlock bad magic on CPU#0 on BeagleBone Stephen Boyd
2012-12-20 4:48 ` Bedia, Vaibhav
2012-12-20 6:25 ` Stephen Boyd
2012-12-20 6:44 ` Bedia, Vaibhav
2012-12-20 7:07 ` Stephen Boyd
2012-12-20 7:39 ` [PATCH] lib: atomic64: Initialize locks statically to fix early users Stephen Boyd
2012-12-20 19:06 ` Tony Lindgren
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).