On Wed, Sep 02, 2020 at 10:19:26PM +0900, Masami Hiramatsu wrote: > On Wed, 2 Sep 2020 11:36:13 +0200 > peterz@xxxxxxxxxxxxx wrote: > > > On Wed, Sep 02, 2020 at 05:17:55PM +0900, Masami Hiramatsu wrote: > > > > > > Ok, but then lockdep will yell at you if you have that enabled and run > > > > the unoptimized things. > > > > > > Oh, does it warn for all spinlock things in kprobes if it is unoptimized? > > > Hmm, it has to be noted in the documentation. > > > > Lockdep will warn about spinlocks used in NMI context that are also used > > outside NMI context. > > OK, but raw_spin_lock_irqsave() will not involve lockdep, correct? It will. The distinction between spin_lock and raw_spin_lock is only that raw_spin_lock stays a spinlock on PREEMPT_RT, while spin_lock will turn into a (PI) mutex in that case. But both will call into lockdep. Unlike local_irq_disable() and raw_local_irq_disable(), where the latter will not. Yes your prefixes are a mess :/ > > Now, for the kretprobe that kprobe_busy flag prevents the actual > > recursion self-deadlock, but lockdep isn't smart enough to see that. > > > > One way around this might be to use SINGLE_DEPTH_NESTING for locks when > > we use them from INT3 context. That way they'll have a different class > > and lockdep will not see the recursion. > > Hmm, so lockdep warns only when it detects the spinlock in NMI context, > and int3 is now always NMI, thus all spinlock (except raw_spinlock?) > in kprobe handlers should get warned, right? > I have tested this series up to [16/21] with optprobe disabled, but > I haven't see the lockdep warnings. There's a bug, that might make it miss it. I have a patch. I'll send it shortly. > > pre_handler_kretprobe() is always called from INT3, right? > > No, not always, it can be called from optprobe (same as original code > context) or ftrace handler. > But if you set 0 to /proc/sys/debug/kprobe_optimization, and compile > the kernel without function tracer, it should always be called from > INT3. D'oh, ofcourse! Arguably I should make the optprobe context NMI like too.. but that's for another day.
