• J
    [PATCH] x86_64: Report hardware breakpoints in user space when triggered by the kernel · 01b8faae
    John Blackwood 提交于
    I would like to throw out a suggestion for a possible change in the way that
    the debug register traps are handled in do_debug() when the trap occurs
    in kernel-mode.
    
    In the x86_64 version of do_debug(), the code will skip around sending
    a SIGTRAP to the current task if the trap occurred while in kernel mode.
    
    On the i386-side of things, if the access happens to occur in kernel mode
    (say during a read(2) of user's buffer that matches the address of a
    debug register trap), then the do_debug() routine for i386 will go ahead
    and call send_sigtrap() and send the SIGTRAP signal.  The send_sigtrap()
    code will also set the info.si_addr to NULL in this case (even though I
    don't understand why, since the SIGTRAP siginfo processing doesn't use
    the si_addr field...).
    
    So I would like to suggest that the x86_64 do_debug() routine also
    follow this type of behavior and have it go ahead and send the
    SIGTRAP signal to the current task, even if the debug register trap
    happens to have occurred in kernel mode.  I have taken a stab at
    a patch for this change below.  (It includes the i386-ish change
    for setting si_addr to NULL when the trap occurred in kernel mode.)
    
    It seems like a useful feature to be able to 'watch' a user location that
    might also be modified in the kernel via a system service call, and have the
    debugger report that information back to the user, rather than to just
    silently ignore the trap.
    
    Additionally, I realize that users that pull in a kernel debugger such as
    KGDB into their kernel might want to remove this change below when they add
    in KGDB support.  However, they could alternatively look at the current
    task's thread.debugreg[] values to see if the trap occurred due to KGDB
    or instead because of a user-space debugger trap, and still honor the
    user SIGTRAP processing (instead of the KGDB breakpoint processing)
    if the trap matches up with the thread.debugreg[] registers.
    Signed-off-by: NAndi Kleen <ak@suse.de>
    Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
    01b8faae
traps.c 24.2 KB