On Thu, 21 Jan 2010 21:51:13 +0100
Oleg Nesterov o...@redhat.com wrote:
On 01/07, Roland McGrath wrote:
I am confused as well. Yes, I thought about regs-psw.mask change too,
but I don't understand why it helps..
[...]
But. Acoording to the testing I did (unless I did something wrong
On 01/07, Roland McGrath wrote:
I am confused as well. Yes, I thought about regs-psw.mask change too,
but I don't understand why it helps..
[...]
But. Acoording to the testing I did (unless I did something wrong
again) this patch doesn't make any difference in this particular
case.
On Thu, 7 Jan 2010 13:46:42 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
Clear the TIF_SINGLE_STEP bit in copy_thread. If the new process is
not auto-attached by the tracer it is wrong to delivere SIGTRAP to
the new process.
The change is right, but this log entry is confusing.
Ok, I changed the wording slightly:
Clear the TIF_SINGLE_STEP bit in copy_thread. The new process did not get
a PER event of its own. It is wrong deliver a SIGTRAP that was meant for
the parent process.
Very good!
Thanks,
Roland
Martin, sorry for delay,
On 01/07, Martin Schwidefsky wrote:
On Wed, 6 Jan 2010 13:13:29 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
However, with or without CONFIG_UTRACE,
6580807da14c423f0d0a708108e6df6ebc8bc83d
is needed on s390 too, otherwise the child gets unnecessary
On 01/07, Martin Schwidefsky wrote:
On Wed, 6 Jan 2010 13:08:12 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
That's what tracehook_signal_handler is for. You're both doing it yourself
in the arch code (by setting TIF_SINGLE_STEP), and then telling the generic
code to do it (by
Right. That means we should leave the status quo of not clearing
TIF_SINGLE_STEP in user_disable_single_step.
Ok, although it seems a bit strange not to do it. Perhaps I should add a
comment about it.
It doesn't seem strange to me, but then I've just been through all this.
user_*_step is
Hmm, command for tracehook_signal_handler say this for stepping:
@stepping: nonzero if debugger single-step or block-step in
use
Are you saying you would like me to clarify that wording somehow? It's
meant to be implicit that the arch code is not doing any special fakery
about
Clear the TIF_SINGLE_STEP bit in copy_thread. If the new process is
not auto-attached by the tracer it is wrong to delivere SIGTRAP to
the new process.
The change is right, but this log entry is confusing. auto-attached has
nothing to do with it, nor does anything about tracing the new
I am confused as well. Yes, I thought about regs-psw.mask change too,
but I don't understand why it helps..
[...]
But. Acoording to the testing I did (unless I did something wrong
again) this patch doesn't make any difference in this particular
case. 6580807da14c423f0d0a708108e6df6ebc8bc83d
On Tue, Jan 05, 2010 at 08:58:18PM +0100, Oleg Nesterov wrote:
I decided to re-test this all with vanilla 2.6.33-rc2. It is really
amazing how long it takes to recompile/install the kernel!
Then either you have a lot of steal time or an old machine (pre z10)?
You could also try to define more
Cai, any chance you can help? Using /usr/bin/console I can't choose
anotherkernel at the 00: Please choose (default will boot in 15 seconds):
stage, how can I do this???
As Heiko mentioned, I did manage to enter,
#cp vi vmsg 2
during the prompt to get to the second kernel to boot...
On 01/06, caiq...@redhat.com wrote:
Cai, any chance you can help? Using /usr/bin/console I can't choose
anotherkernel at the 00: Please choose (default will boot in 15 seconds):
stage, how can I do this???
As Heiko mentioned, I did manage to enter,
#cp vi vmsg 2
if only I new about
On 01/05, Oleg Nesterov wrote:
On 01/05, Oleg Nesterov wrote:
On 01/05, Oleg Nesterov wrote:
I'll add clear_bit(TIF_SINGLE_STEP) into do_fork() path and re-test.
Hmm. This patch
--- kernel/fork.c~ 2009-12-22 10:41:53.188084961 -0500
+++ kernel/fork.c
On 01/05, Martin Schwidefsky wrote:
On Mon, 4 Jan 2010 13:11:47 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
This probably means that copy_process()-user_disable_single_step()
is not enough to clear the this task wants single-stepping copied
from parent.
I would suspect
However, with or without CONFIG_UTRACE,
6580807da14c423f0d0a708108e6df6ebc8bc83d
is needed on s390 too, otherwise the child gets unnecessary traps.
This confuses me. user_disable_single_step on non-current doesn't do
anything not already done by the memset in copy_thread. Ooh, except
On Mon, 4 Jan 2010 19:14:12 +0100
Oleg Nesterov o...@redhat.com wrote:
On 01/04, Martin Schwidefsky wrote:
Subject: [PATCH] fix loading of PER control registers for utrace.
From: Martin Schwidefsky schwidef...@de.ibm.com
If the current task enables / disables PER tracing for itself the
On 01/05, Martin Schwidefsky wrote:
On Mon, 4 Jan 2010 13:11:47 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
This probably means that copy_process()-user_disable_single_step()
is not enough to clear the this task wants single-stepping copied
from parent.
I would suspect
On Tue, 5 Jan 2010 16:36:33 +0100
Oleg Nesterov o...@redhat.com wrote:
On 01/05, Martin Schwidefsky wrote:
On Mon, 4 Jan 2010 13:11:47 -0800 (PST)
Roland McGrath rol...@redhat.com wrote:
This probably means that copy_process()-user_disable_single_step()
is not enough to clear
On 01/05, Oleg Nesterov wrote:
Anyway. I modified the debugging patch a bit:
--- K/arch/s390/kernel/traps.c~ 2009-12-22 10:41:52.909174198 -0500
+++ K/arch/s390/kernel/traps.c2010-01-05 09:49:19.541792379 -0500
@@ -384,6 +384,8 @@ void __kprobes do_single_step(struct pt_
On Tue, 5 Jan 2010 16:47:25 +0100
Oleg Nesterov o...@redhat.com wrote:
On 01/05, Oleg Nesterov wrote:
Anyway. I modified the debugging patch a bit:
--- K/arch/s390/kernel/traps.c~ 2009-12-22 10:41:52.909174198 -0500
+++ K/arch/s390/kernel/traps.c 2010-01-05 09:49:19.541792379
On 01/05, Martin Schwidefsky wrote:
On Tue, 5 Jan 2010 16:36:33 +0100
Oleg Nesterov o...@redhat.com wrote:
For example, why do_signal() sets TIF_SINGLE_STEP? Why can't we do
--- a/arch/s390/kernel/signal.c
+++ b/arch/s390/kernel/signal.c
@@ -500,18 +500,10 @@ void
On Mon, 4 Jan 2010 16:52:25 +0100
Oleg Nesterov o...@redhat.com wrote:
Hi!
We have some strange problems with utrace on s390, and so far this _looks_
like a s390 problem.
Looks like, on any CPU user_enable_single_step() does not work until at
least one thread with per_info.single_step =
On 01/04, Oleg Nesterov wrote:
IOW. I think this problem is minor and probably can be ignored,
Or may be not...
Even if the child is not killed by SIGTRAP, it can get a lot of
unnecessary traps.
To verify, I did another trivial patch (below), and the test
case from
The PER control registers only get reloaded on task switch. Can you test
if this patch fixes your problem?
Long ago when I first worked with David Wilder on s390 arch code,
I remember we made this change. It seems to have been forgotten
in the later rounds of reworking and merging.
Thanks,
This probably means that copy_process()-user_disable_single_step()
is not enough to clear the this task wants single-stepping copied
from parent.
I would suspect s390's TIF_SINGLE_STEP flag here. That flag means a
single-step trap occurred. This is what causes do_single_step to be
called
Could you please re-test with this patch applied?
It turned out that this patch did not make much difference. the step-simple is
still failing with the patch applied. It could be reproduced a few times after
a fresh reboot. The test exited with 1 here,
/* Known bug in 2.6.28-rc7 +
On 12/22, caiq...@redhat.com wrote:
The following are testing results on s390x kernels build from the source,
http://kojipkgs.fedoraproject.org/packages/kernel/2.6.32.2/14.fc13/src/kernel-2.6.32.2-14.fc13.src.rpm
without and with CONFIG_UTRACE using the latest ptrace-utrace git tree.
On 12/22, Oleg Nesterov wrote:
On 12/22, caiq...@redhat.com wrote:
and a different syscall number when syscall-from-clone failed.
This is not clear to me, will take a look.
Should I say I know nothing about s390 and can't read its asm?
First of all, I think syscall-from-clone is wrong on
On 12/22, Oleg Nesterov wrote:
On 12/22, Oleg Nesterov wrote:
and I don't know whether it is OK or not that syscall-from-clone
sees different -orig_gpr2 after return from fork() on s390
-unexpected syscall 0x5ee9 without utrace
+unexpected syscall 0
Damn, my fault. I forgot to cc you when I sent the fix for s390 (attached
below), and I forgot to remind you about this fix when we discussed the
testing on s390.
That change is upstream for 2.6.33 now. I'll cherry-picked it into
the 2.6.32/tracehook branch so it will be in the backport
Oh. I am still trying to parse arch/s390/kernel/entry.S to understand
how can we fix these test-cases. I think I need the help, will continue
tomorrow.
Martin Schwidefsky schwidef...@de.ibm.com is the s390 arch maintainer.
He is friendly and helpful. You can ask him for help both with
32 matches
Mail list logo
