odd utrace testing results on s390x

[Oleg Nesterov]

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		<---- with utrace

AAAAAARGH. I misread the diff you reported, the difference above
has nothing to do with syscall-from-clone! This is the output
form the next test-case, step-from-clone.

I think, everything is (almost) clear now, I'll try to summarize.
Both syscall-from-clone and step-from-clone fail, with or without
utrace. I think they both need the fix, REGISTER_CALLNO and
REGISTER_RETVAL are wrong on s390. (I also tested my trivial
test-case on rhel5 and it prints the same).

Now, the difference above _can_ be explained because utrace
kernel lacks ca633fd006486ed2c2d3b542283067aab61e6dc8 (Cai,
I attached this patch in the first reply), or we have issues
with utrace on s390.

without utrace:

	-unexpected syscall 0x5ee9

	this is in fact grandchild's pid == fork's retval because
	REGISTER_CALLNO is wrong

with utrace:

	+unexpected syscall 0

well, we are reading orig_gpr2 which is wrong anyway, but I am
worried because cat /proc/child/syscall reports

	-1 0x3ffffff21d8 0x200000f1e52

_Perhaps_ this all will be fixed by ca633fd006486ed2c2d3b542283067aab61e6dc8,
but I am not sure. This trap was (I think) generated by
ptrace_report_signal(), it may happen that so s390 doesn't preserve
some registers when we dequeue SIGTRAP after do_notify_resume()->utrace_stop()
and call utrace_stop() again.



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.

Oleg.