lkml.org 
[lkml]   [2011]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Subject[BUG] kprobes crashing because of preempt count
    From
    Date
    Hi Masami,

    While testing some changes in -rt against kprobes, I hit a crash that
    exists in mainline. If we stick a probe in a location that reads
    preempt_count, we corrupt the kernel itself.

    Reason is that the kprobe single step handler disables preemption, sets
    up the single step, returns to the code to execute that single step,
    takes the trap, enables preemption, and continues.

    The issue, is because we disabled preemption in the trap, returned, then
    enabled it again in another trap, we just changed what the code sees
    that does that single step.

    If we add a kprobe on a inc_preempt_count() call:

    [ preempt_count = 0 ]

    ld preempt_count, %eax <<--- trap

    <trap>
    preempt_disable();
    [ preempt_count = 1]
    setup_singlestep();
    <trap return>

    [ preempt_count = 1 ]

    ld preempt_count, %eax

    [ %eax = 1 ]

    <trap>
    post_kprobe_handler()
    preempt_enable_no_resched();
    [ preempt_count = 0 ]
    <trap return>

    [ %eax = 1 ]

    add %eax,1

    [ %eax = 2 ]

    st %eax, preempt_count

    [ preempt_count = 2 ]


    We just caused preempt count to increment twice when it should have only
    incremented once, and this screws everything else up.

    Do we really need to have preemption disabled throughout this? Is it
    because we don't want to migrate or call schedule? Not sure what the
    best way to fix this is. Perhaps we add a kprobe_preempt_disable() that
    is checked as well?

    -- Steve




    \
     
     \ /
      Last update: 2011-06-30 15:25    [W:4.114 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site