Well, from https://man7.org/linux/man-pages/man2/ptrace.2.html ESRCH The specified process does not exist, or is not currently being traced by the caller, or is not stopped (for requests that require a stopped tracee). so if the kernel doesn't support PTRACE_SEIZE then ptrace(PTRACE_SEIZE) should fail with -ESRCH as documented. Perhaps this part EIO request is invalid, or ... can be improvef a bit to explain that this happens if the target is already traced by us and stopped. Oleg. so in this case ptrace will fail with -ESRCH if called with an invalid request code On 04/14, Alejandro Colomar wrote: > > Hi Sergei, > > On 4/13/23 21:30, Sergei Zhirikov wrote: > > Hello, > > > > I've been studying the ptrace(2) man page and experimenting with ptrace() recently and came across this unexpected aspect of its behavior that I think would be good to have documented. > > > > I would like to use PTRACE_SEIZE in my project because of the advantages it offers, but I would also like to support kernels older than 3.4 (where it was fully introduced). My thinking was that I would call ptrace(PTRACE_SEIZE, ...) and if it fails with the appropriate error code indicating that it's not supported I would fall back to PTRACE_ATTACH. That is where a little surprise was waiting for me. According to the man page, ptrace will fail with errno=EIO if called with an invalid request code. Logically, that was the error code I expected to get when PTRACE_SEIZE is not supported. In reality I got ESRCH instead. In my attempts to make sense of it I had to resort to reading the kernel source. Apparently, the logic in the kernel ( https://elixir.bootlin.com/linux/v3.0.101/source/kernel/ptrace.c#L944 ;) seems to assume that any request other than PTRACE_ATTACH must come for an already existing tracee. So it proceeds to look for such a tracee (by calling ptrace_check_attach) before trying to interpret the request code. Obviously, in case of PTRACE_SEIZE, the target process/thread is not being traced yet, so ESRCH is returned. As far as I can tell by looking at the source code, that will happen for any request code (with a couple of exceptions), valid or otherwise. The relevant piece of logic seems to remain unchanged to this day, so this isn't just a problem with an ancient kernel that nobody cares about. I am not sure whether this behavior is intentional (I would guess it's not), but in any case it's probably good to have it documented in the man page. > > I've added some CCs. Feel free to send a patch. > > Cheers, > Alex > > > > > Thanks and regards, > > Sergei. > > -- > <http://www.alejandro-colomar.es/> > GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
