3 ms·
Oh, already? I got a patch in to fix PTRACE_SYSEMU on aarch64, but I still have a few patches queued up to fix a few more issues there. I had hoped to get them
by KenoFischer 6y ago
Oh, already? I got a patch in to fix PTRACE_SYSEMU on aarch64, but I still have a few patches queued up to fix a few more issues there. I had hoped to get them all into the same release so there is only broken and not broken releases, rather than broken, semi-broken and non-broken releases. Oh well, ptrace on aarch64 has a few other big issues anyway that wouldn't have been mergeable during the RC window, so I suppose I should just try to get that in for 5.8.
- _-___________-_ 6y agoI hate to break it to you, but there are only semi-broken releases ;)
- KenoFischer 6y agoWell aware, but I was hoping to say to people "Just use 5.7 and it'll be fine". At the moment I have to say "Don't use anything prior to 5.7, unless you have a recent stable backpoint. In either case, some things are fine others aren't - I'll hope to have it fixed by 5.8". Which is fine, but more complicated ;).
- pabs3 6y agoJust CC stable@ and get them into the next point release?
- exikyut 6y agoWas curious; quoting https://www.man7.org/linux/man-pages/man2/ptrace.2.html https://www.man7.org/linux/man-pages/man2/ptrace.2.html: > PTRACE_SYSEMU, PTRACE_SYSEMU_SINGLESTEP (since Linux 2.6.14) > For PTRACE_SYSEMU, continue and stop on entry to the next system call, which will not be executed. See the documentation on syscall-stops below. For PTRACE_SYSEMU_SINGLESTEP, do the same but also singlestep if not a system call. This call is used by programs like User Mode Linux that want to emulate all the tracee's system calls. The data argument is treated as for PTRACE_CONT. The addr argument is ignored. These requests are currently supported only on x86. That sounds like a fun pile of dragons. Good luck backspacing the last bit out soon ;)