Messages in this thread | | | From | Atish Patra <> | Date | Tue, 29 Sep 2020 15:12:33 -0700 | Subject | Re: [PATCH V2 2/3] riscv: Fixup lockdep_assert_held with wrong param cpu_running |
| |
On Sat, Jun 27, 2020 at 6:58 AM <guoren@kernel.org> wrote: > > From: Zong Li <zong.li@sifive.com> > > The cpu_running is not a lock-class, it lacks the dep_map member in > completion. It causes the error as follow: > > arch/riscv/kernel/smpboot.c: In function '__cpu_up': > ./include/linux/lockdep.h:364:52: error: 'struct completion' has no member named 'dep_map' > 364 | #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) > | ^~ > ./include/asm-generic/bug.h:113:25: note: in definition of macro 'WARN_ON' > 113 | int __ret_warn_on = !!(condition); \ > | ^~~~~~~~~ > ./include/linux/lockdep.h:390:27: note: in expansion of macro 'lockdep_is_held' > 390 | WARN_ON(debug_locks && !lockdep_is_held(l)); \ > | ^~~~~~~~~~~~~~~ > arch/riscv/kernel/smpboot.c:118:2: note: in expansion of macro 'lockdep_assert_held' > 118 | lockdep_assert_held(&cpu_running); > > There are a lot of archs which use cpu_running in smpboot.c (arm, > arm64, openrisc, xtensa, s390, x86, mips), but none of them try > lockdep_assert_held(&cpu_running.wait.lock). So Just remove it. > > Signed-off-by: Zong Li <zong.li@sifive.com> > Signed-off-by: Guo Ren <guoren@linux.alibaba.com> > --- > arch/riscv/kernel/smpboot.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c > index 4e99227..defc4e1 100644 > --- a/arch/riscv/kernel/smpboot.c > +++ b/arch/riscv/kernel/smpboot.c > @@ -121,7 +121,6 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle) > > ret = start_secondary_cpu(cpu, tidle); > if (!ret) { > - lockdep_assert_held(&cpu_running); > wait_for_completion_timeout(&cpu_running, > msecs_to_jiffies(1000)); > > -- > 2.7.4 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Thanks for catching this.
Reviewed-by: Atish Patra <atish.patra@wdc.com>
-- Regards, Atish
| |