lkml.org 
[lkml]   [2020]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v5 00/21] kprobes: Unify kretprobe trampoline handlers and make kretprobe lockless
    On Wed, Sep 02, 2020 at 10:19:26PM +0900, Masami Hiramatsu wrote:
    > On Wed, 2 Sep 2020 11:36:13 +0200
    > peterz@infradead.org 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.

    \
     
     \ /
      Last update: 2020-09-02 15:50    [W:4.225 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site