[PATCH powerpc] init nvram_pstore_info's buf_lock

Subsystems: linux for powerpc (32-bit and 64-bit), the rest

STALE4350d

3 messages, 2 authors, 2014-11-18 · open the first message on its own page

[PATCH powerpc] init nvram_pstore_info's buf_lock

From: Li Zhong <hidden>
Date: 2014-11-17 02:53:33

It seems nvram_pstore_info's buf_lock is not initialized before
registering, which causes some strange behavior when trying to obtain
the lock during kdump process.

Signed-off-by: Li Zhong <redacted>
---
 arch/powerpc/platforms/pseries/nvram.c | 2 ++
 1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c
index 11a3b61..054a0ed 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -715,6 +715,8 @@ static int nvram_pstore_init(void)
 	nvram_pstore_info.buf = oops_data;
 	nvram_pstore_info.bufsize = oops_data_sz;
 
+	spin_lock_init(&nvram_pstore_info.buf_lock);
+
 	rc = pstore_register(&nvram_pstore_info);
 	if (rc != 0)
 		pr_err("nvram: pstore_register() failed, defaults to "

Re: [powerpc] init nvram_pstore_info's buf_lock

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2014-11-18 04:33:14

On Mon, 2014-17-11 at 02:52:30 UTC, Li Zhong wrote:
It seems nvram_pstore_info's buf_lock is not initialized before
registering, which causes some strange behavior when trying to obtain
the lock during kdump process.
What kind of strange behaviour? Does it still work and just print a warning?

It's static, so I'd expect it to be unlocked by default.

cheers

Re: [powerpc] init nvram_pstore_info's buf_lock

From: Li Zhong <hidden>
Date: 2014-11-18 06:17:23

On 二, 2014-11-18 at 15:33 +1100, Michael Ellerman wrote:
On Mon, 2014-17-11 at 02:52:30 UTC, Li Zhong wrote:
quoted
It seems nvram_pstore_info's buf_lock is not initialized before
registering, which causes some strange behavior when trying to obtain
the lock during kdump process.
What kind of strange behaviour? Does it still work and just print a warning?

It's static, so I'd expect it to be unlocked by default.
Yes, you are right. It still works. 

I saw it on a UP configuration, noticed the console stopped for a couple
of seconds, then "lockup suspected" warning printed out, but then it
continued to run. 

After some further checking, it seems working as designed for the UP
spinlock debug, from the comments in spinlock_up.h

 * In the debug case, 1 means unlocked, 0 means locked. (the values
 * are inverted, to catch initialization bugs)

So try lock fails, and lockup reported, but then arch_spin_lock()
passes. 

Thanks, Zhong
cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help