init nvram_pstore_info's buf_lock
PATCH 1/1 init nvram_pstore_info's buf_lock
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.
--- arch/powerpc/platforms/pseries/nvram.c | 2 ++ 1 file changed, 2 insertions(+)
arch/powerpc/platforms/pseries/nvram.c +2 -0
@@ -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 "
Michael Ellerman
reviewerQuoted 3 lines · Li Zhong
It seems nvram_pstore_info's
buf_lockis 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
Quoted 8 lines · Michael Ellerman
Quoted 3 lines · Li Zhong
It seems nvram_pstore_info's
buf_lockis 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
Quoted 3 lines
cheers