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.
