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/msg00006.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/msg00006.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. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html