Oleg Nesterov wrote:
On 12/18, Roland McGrath wrote:
Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.
2.6.33-rc1 x86-64 works for me with either -m64 or -m32 version of that test.
(not sure this matters, but I did the testing under kvm)
On 12/21, Jan Kiszka wrote:
Oleg Nesterov wrote:
Hmm. Now I see how wrong I was when I said this code is obviously wrong ;)
Yes, it is easy to blame the code you don't understand.
My apologies to all.
I'll add the debugging printk's and report the output. Sorry for delay,
can't do
Oleg Nesterov wrote:
On 12/21, Jan Kiszka wrote:
Oleg Nesterov wrote:
Hmm. Now I see how wrong I was when I said this code is obviously wrong ;)
Yes, it is easy to blame the code you don't understand.
My apologies to all.
I'll add the debugging printk's and report the output. Sorry for
On 12/19/2009 01:15 AM, Frederic Weisbecker wrote:
Apparently it does. You should hack some printks into do_debug() and see
how kvm is differing from real hardware. (Actually you can probably do
this with a notifier added by a module, not that you are shy about
recompiling!)
Probably kvm's
On 12/18, Frederic Weisbecker wrote:
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
Hi.
do_debug() is obviously wrong wrt PTRACE_SINGLESTEP/TIF_SINGLESTEP, no?
Afaics this was broken by
hw-breakpoints: modifying generic debug exception to use
thread-specific
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
Hi.
do_debug() is obviously wrong wrt PTRACE_SINGLESTEP/TIF_SINGLESTEP, no?
Afaics this was broken by
hw-breakpoints: modifying generic debug exception to use
thread-specific debug registers
commit
On Fri, Dec 18, 2009 at 06:27:47PM +0100, Oleg Nesterov wrote:
On 12/18, Frederic Weisbecker wrote:
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
Hi.
snipped
Single stepping works well for me, after a quick check on
gdb. How did you trigger the bug?
Please find
On 12/18, K.Prasad wrote:
On Fri, Dec 18, 2009 at 06:27:47PM +0100, Oleg Nesterov wrote:
On 12/18, Frederic Weisbecker wrote:
On Fri, Dec 18, 2009 at 01:56:50AM +0100, Oleg Nesterov wrote:
Hi.
snipped
Single stepping works well for me, after a quick check on
gdb. How did you
Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.
2.6.33-rc1 x86-64 works for me with either -m64 or -m32 version of that test.
(not sure this matters, but I did the testing under kvm)
Apparently it does. You should hack some printks into
On 12/18, Roland McGrath wrote:
Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.
2.6.33-rc1 x86-64 works for me with either -m64 or -m32 version of that test.
(not sure this matters, but I did the testing under kvm)
Apparently it
On Fri, Dec 18, 2009 at 12:05:03PM -0800, Roland McGrath wrote:
Please find the trivial test-case below. It hangs, because
PTRACE_SINGLESTEP doesn't trigger the trap.
2.6.33-rc1 x86-64 works for me with either -m64 or -m32 version of that test.
(not sure this matters, but I did the
Comparing to the old (2.6.32) logic, I think it might be this (untested).
I also note this is the sole use of get_si_code, seems like it should
just be rolled in here.
Thanks,
Roland
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 3339917..16a88f5 100644
---
On 12/17, Roland McGrath wrote:
Comparing to the old (2.6.32) logic, I think it might be this (untested).
I also note this is the sole use of get_si_code, seems like it should
just be rolled in here.
Well, it is too late for me to even try to read this patch ;)
but...
@@ -569,14 +568,15 @@
On Fri, Dec 18, 2009 at 03:10:42AM +0100, Oleg Nesterov wrote:
On 12/17, Roland McGrath wrote:
Comparing to the old (2.6.32) logic, I think it might be this (untested).
I also note this is the sole use of get_si_code, seems like it should
just be rolled in here.
Well, it is too late
+ dr6 = tsk-thread.debugreg6;
why? we have tsk-thread.debugreg6 = dr6 above
Yeah, it's a little superfluous. Except that the existing code uses
tsk-thread.debugreg6 and dr6 inconsistently. It only matters either way
if some notifier function might change thread.debugreg6, which I wasn't
15 matches
Mail list logo
