Re: s390 user_enable_single_step() (Was: odd utrace testing results on s390x)
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 cpus if you have a virtual machine: #cp define cpu from-to ...that is if your admin gave you permissions to do that. I spent the rest of this day fighting with this rhts machine. Result - it doesn't boot: 00: zIPL v1.8.2-5.el6 interactive boot menu 00: 00: 0. default (2.6.33-rc2) 00: 00: 1. 2.6.33-rc2 00: 2. 2.6.32.2-14.s390x.el6.s390x 00: 3. 2.6.32.2-14.el6.s390x 00: 4. linux 00: 00: Note: VM users please use '#cp vi vmsg input' 00: 00: Please choose (default will boot in 15 seconds): 00: Booting default (2.6.33-rc2)... Ý0011c4fc¨ sysc_return+0x0/0x8 Ý003cc0c6¨ selinux_sb_copy_data+0x17e/0x238 (Ý003cbf94¨ selinux_sb_copy_data+0x4c/0x238) Ý003b62a6¨ security_sb_copy_data+0x4e/0x60 Ý00280338¨ vfs_kern_mount+0x19c/0x1f4 Ý002803de¨ kern_mount_data+0x4e/0x5c Ý00ae1908¨ devtmpfs_init+0x60/0xbc Ý00ae1818¨ driver_init+0x28/0x6c Ý00abe582¨ kernel_init+0x32a/0x3d8 Ý0010b8c2¨ kernel_thread_starter+0x6/0xc Ý0010b8bc¨ kernel_thread_starter+0x0/0xc INFO: lockdep is turned off. 00: HCPGIR450W CP entered; disabled wait PSW 00020001 8000 00114BD4 Cai, any chance you can help? Using /usr/bin/console I can't choose another kernel at the 00: Please choose (default will boot in 15 seconds): stage, how can I do this??? You did enter something like #cp vi vmsg 2 and not just '2'?
Re: s390 user_enable_single_step() (Was: odd utrace testing results on s390x)
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... Thanks, CAI Qian
Re: s390 user_enable_single_step() (Was: odd utrace testing results on s390x)
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 this magic ;) Thanks Cai and Heiko! Oleg.
Re: s390 user_enable_single_step() (Was: odd utrace testing results on s390x)
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 2010-01-05 11:42:58.370636323 -0500 @@ -1206,6 +1206,8 @@ static struct task_struct *copy_process( * of CLONE_PTRACE. */ clear_tsk_thread_flag(p, TIF_SYSCALL_TRACE); + clear_tsk_thread_flag(p, TIF_SINGLE_STEP); + user_disable_single_step(p); #ifdef TIF_SYSCALL_EMU clear_tsk_thread_flag(p, TIF_SYSCALL_EMU); #endif doesn't help, I still see the same XXX's in dmesg... Oh, now I am totally confused. I reverted your fix from https://www.redhat.com/archives/utrace-devel/2010-January/msg6.html and now there is nothing in dmesg. I take this back. I re-tested this all under 2.6.32.2 + utrace, and I see nothing in dmesg. I don't know what I did wrong, most probably I forgot to do zipl or something like this... I'll try to summarize. Martin's patch from https://www.redhat.com/archives/utrace-devel/2010-January/msg6.html fixes the problems with utrace. However, with or without CONFIG_UTRACE, 6580807da14c423f0d0a708108e6df6ebc8bc83d is needed on s390 too, otherwise the child gets unnecessary traps. Oleg.
Re: s390 user_enable_single_step() (Was: odd utrace testing results on s390x)
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 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 before returning to user mode, rather than the machine trap doing it
directly as is done in the other arch implementations.
Just my thinking as well.
If I'm right, then this task wants single-stepping is not the problem,
and that really is fully cleared. In fact, looking at s390's copy_thread
(arch/s390/kernel/process.c) it clears out all the state that is actually
touched by user_enable_single_step and user_disable_single_step. So for
s390 the new fork.c call is actually superfluous AFAICT.
/* Don't copy debug registers */
memset(p-thread.per_info, 0, sizeof(p-thread.per_info));
Yep, the call from fork.c is indeed superfluous.
I can't explain this, but if I remove copy_process()-user_disable_single_step()
the test-case below triggers XXX printk's from do_single_step() with or
without CONFIG_UTRACE. the patch is
--- arch/s390/kernel/traps.c~ 2009-12-22 10:41:52.909174198 -0500
+++ arch/s390/kernel/traps.c2010-01-05 11:03:55.006487697 -0500
@@ -384,6 +384,9 @@ void __kprobes do_single_step(struct pt_
}
if (tracehook_consider_fatal_signal(current, SIGTRAP))
force_sig(SIGTRAP, current);
+ else
+ printk(XXX: %s/%d %d\n, current-comm, current-pid,
+ test_thread_flag(TIF_SINGLE_STEP));
}
static void default_trap_handler(struct pt_regs * regs, long
interruption_code)
Oleg.
#include stdio.h
#include unistd.h
#include signal.h
#include sys/ptrace.h
#include sys/wait.h
#include assert.h
int main(void)
{
int pid, status;
if (!(pid = fork())) {
assert(ptrace(PTRACE_TRACEME) == 0);
kill(getpid(), SIGSTOP);
if (!fork())
return 43;
wait(status);
return WEXITSTATUS(status);
}
for (;;) {
assert(pid == wait(status));
if (WIFEXITED(status))
break;
assert(ptrace(PTRACE_SINGLESTEP, pid, 0,0) == 0);
}
assert(WEXITSTATUS(status) == 43);
return 0;
}
Re: s390 user_enable_single_step() (Was: odd utrace testing results on s390x)
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 perhaps it does not clear PSW_MASK_PER. Maybe that matters. That's the only thing I can think of. Maybe Martin can make sense of it. Thanks, Roland
