> From: Zhang, Qiang1 <qiang1.zhang@xxxxxxxxx>
> Sent: Thursday, February 23, 2023 4:43 PM
> To: Zhuo, Qiuxu <qiuxu.zhuo@xxxxxxxxx>; paulmck@xxxxxxxxxx;
> frederic@xxxxxxxxxx; quic_neeraju@xxxxxxxxxxx; joel@xxxxxxxxxxxxxxxxx
> Cc: rcu@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> Subject: RE: [PATCH] rcu-tasks: Directly invoke rcuwait_wake_up() in
> call_rcu_tasks_generic()
>
> > From: Zqiang <qiang1.zhang@xxxxxxxxx>
> > Sent: Thursday, February 23, 2023 2:30 PM
> > To: paulmck@xxxxxxxxxx; frederic@xxxxxxxxxx; quic_neeraju@xxxxxxxxxxx;
> > joel@xxxxxxxxxxxxxxxxx
> > Cc: rcu@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> > Subject: [PATCH] rcu-tasks: Directly invoke rcuwait_wake_up() in
> > call_rcu_tasks_generic()
> >
> > According to commit '3063b33a347c ("Avoid raw-spinlocked wakeups from
> > call_rcu_tasks_generic()")', the grace-period kthread is delayed to
> > wakeup using irq_work_queue() is because if the caller of
> > call_rcu_tasks_generic() holds a raw spinlock, when the kernel is
> > built with CONFIG_PROVE_RAW_LOCK_NESTING=y, due to a spinlock will
> be
> > hold in wake_up(), so the lockdep splats will happen. but now using
> > rcuwait_wake_up() to wakeup grace-period kthread instead of wake_up(),
> > in
> > rcuwait_wake_up() no spinlock will be acquired, so this commit remove
> > using
> >
> >There are still spinlock-acquisition and spinlock-release invocations within
> the call path from rcuwait_wake_up().
> >
> >rcuwait_wake_up() -> wake_up_process() -> try_to_wake_up(), then:
> >
> > raw_spin_lock_irqsave()
> > ...
> > raw_spin_unlock_irqrestore
>
> Yes, but this is raw_spinlock acquisition and release(note: spinlock will
> convert to sleepable lock in Preempt-RT kernel, but raw spinlock is not
> change).
Hi Qiang,
Yes, you're correct. Thanks for correcting me.
-Qiuxu
> acquire raw_spinlock -> acquire spinlock will trigger lockdep warning.
>
> Thanks
> Zqiang
