> > Could you describe the problem in more details? I wonder whether we have > the same thing in CRIU... > Sure, basically the issue is that orig_x0 gets recorded at the start of the syscall entry, but is not otherwise part of the ptrace state. It used to be primarily used for resetting the argument back to its original value during syscall restarts, but I see it's been expanded slightly with the user dispatch mechanism (though as far as I can tell not in a way that interacts with ptrace). Basically the problem is that if you change the value of x0 during either the ptrace entry stop or a seccomp stop and then incur a syscall restart, the syscall will restart with the original x0 rather than with the modified x0, which may be unexpected. Of course, relatedly, if you're doing CRIU-like things you can end up in situations where the future behavior will depend on the orig_x0 value, which isn't restore-able at the moment. It's possible to work around all of this by keeping a local copy of orig_x0 and being very careful with the ptrace traps around restarts, but getting the logic right is extremely tricky. My suggestion for what I thought would be reasonable behavior was: 1. Expose orig_x0 to ptrace 2. Set orig_x0 to x0 and set x0 to -ENOSYS at the start of the syscall dispatcher 3. Use orig_x0 for syscall arguments/seccomp/restarts That's basically how rax works on x86_64 and it doesn't seem to cause major problems (though of course I may be biased by having x86_64 already work when I started the aarch64 port). Just the first item would be sufficient of course for getting rid of most of the bookkeeping. I should also say that, for us, the ptrace getregs call can be the throughput limiting operation, so it would be nice if getting the entire basic register set would only require one syscall. I won't insist on it, since we do have a solution in place that kinda works (and only requires the one syscall), but I thought I'd mention it. While we're on this topic, and in case it's helpful to anybody, I should also point out that the order of the ptrace-signal-stop, vs setup for the syscall restart differs between x86 and aarch64 (aarch64 sets up the restart first then delivers the ptrace trap/signal - x86 the other way around). I actually think the aarch64 behavior is saner here, but I figured I'd leave this breadcrumb for anybody who's writing a ptracer and stumbles across this. Keno
