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 ou
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,
> > c
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
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 e
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
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)
>
> Appar
> 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 in
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.
>
>
>
> > > Single stepping works well for me, after a quick check on
> > > g
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.
> > Single stepping works well for me, after a quick check on
> > gdb. How did you trigger the bug?
>
> Please f
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 08d6
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
> >
> > + 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
On Fri, Dec 18, 2009 at 03:58:09AM +0100, Frederic Weisbecker wrote:
> Yep, that doesn't fix your problem but this patch makes sense
> in that if we were not in user mode while the step occured,
> we shouldn't send the signal.
That wouldn't happen actually, as we clear the STEP flag before.
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 08d6
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 t
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,1
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
--- a/arch/x86/kern
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 08d68323d1f0c34452e614263b212ca556dae47f
To verify, the "patch" below fixes the
18 matches
Mail list logo
