Hi, On Wed, Jul 30, 2014 at 12:24:14PM +0100, Will Deacon wrote: > Whilst this sounds like a worrying problem, I've failed to reproduce it > on arm64. Executing a brk instruction with either KGDB_DYN_DGB_BRK_IMM or > KDBG_COMPILED_DBG_BRK_IMM immediates from userspace results in a SIGTRAP being > delivered, assumedly because kgdb_handle_exception simply returns when kgdb > isn't active.
>From what I can tell, the break hooks are registered so long as kgdb is enabled at all - i.e., the kernel was compiled with CONFIG_KGDB=y and, for example, CONFIG_KGDB_SERIAL_CONSOLE=y and kgdboc was passed on the kernel command line. kgdb_handle_exception doesn't seem to check whether the debugger is active. > The following (totally untested) diff is simpler for arm64, but again, I'm > not sure we even have a problem here. This diff also fixes the problem. I don't have a strong preference for either approach, so I can revise the patch with this approach instead if you'd prefer that. > On which systems have you managed to reproduce this and how? I first reproduced this on a Raspberry Pi. The recommended distro, Raspbian, distributes a kernel compiled with CONFIG_KGDB=y, CONFIG_KGDB_KDB=y, and CONFIG_KDB_KEYBOARD=y, so it was sufficient to have a keyboard plugged in. However, I also reproduced it by booting with kgdboc on the command line, as CONFIG_KGDB_SERIAL_CONSOLE was also enabled. Additionally, I reproduced it and then verified that my patch fixed it on self-compiled kernels. I don't currenty have access to a physical ARM64 board, so I did all the testing for this with QEMU (loosely following the instructions here: http://www.bennee.com/~alex/blog/2014/05/09/running-linux-in-qemus-aarch64-system-emulation-mode/). Again, it was sufficient to build with CONFIG_KGDB=y and CONFIG_KGDB_SERIAL_CONSOLE=y and boot with kgdboc enabled, i.e., passing --append "console=ttyAMA0 kgdboc=ttyAMA0,115200" to QEMU. Here's a snippet from that session. # ./brk Entering kdb (current=0xffffffc07df60a80, pid 71) on processor 0 Oops: (null) due to oops @ 0x4000d8 dCPU: 0 PID: 71 Comm: brk Not tainted 3.16.0-rc7ajb #2 dtask: ffffffc07df60a80 ti: ffffffc07d0c0000 task.ti: ffffffc07d0c0000 PC is at 0x4000d8 LR is at 0x0 pc : [<00000000004000d8>] lr : [<0000000000000000>] pstate: 00000000 sp : 0000007fceefcdd0 x29: 0000000000000000 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Let me know if you still have trouble reproducing this. Thanks again! Omar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
