Re: s390 && user_enable_single_step() (Was: odd utrace testing results on s390x)

[Oleg Nesterov <oleg@redhat.com>]

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.