Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 17 Apr 2023 13:50:10 +0200
From:   Oleg Nesterov <oleg@redhat.com>
To:     Alejandro Colomar <alx.manpages@gmail.com>
Cc:     Sergei Zhirikov <sfzhi@yahoo.com>, linux-man@vger.kernel.org,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: Checking for support of ptrace(PTRACE_SEIZE,...) on older kernels
Message-ID: <20230417115009.GA906@redhat.com>
References: <997950238.3486335.1681414225118.ref@mail.yahoo.com>
 <997950238.3486335.1681414225118@mail.yahoo.com>
 <0d95a96b-dd49-db45-ab3c-1d9cee51381d@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <0d95a96b-dd49-db45-ab3c-1d9cee51381d@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

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 requ=
est code

On 04/14, Alejandro Colomar wrote:
>
> Hi Sergei,
>=20
> On 4/13/23 21:30, Sergei Zhirikov wrote:
> > Hello,
> >=20
> > 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 t=
hink would be good to have documented.
> >=20
> > I would like to use PTRACE_SEIZE in my project because of the advantage=
s 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 lit=
tle surprise was waiting for me. According to the man page, ptrace will fai=
l with errno=3DEIO 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 r=
esort to reading the kernel source. Apparently, the logic in the kernel (=
=A0https://elixir.bootlin.com/linux/v3.0.101/source/kernel/ptrace.c#L944=A0=
) seems to assume that any request other than PTRACE_ATTACH must come for a=
n already existing tracee. So it proceeds to look for such a tracee (by cal=
ling ptrace_check_attach) before trying to interpret the request code. Obvi=
ously, in case of PTRACE_SEIZE, the target process/thread is not being trac=
ed 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 nobod=
y 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 i=
n the man page.
>=20
> I've added some CCs.  Feel free to send a patch.
>=20
> Cheers,
> Alex
>=20
> >=20
> > Thanks and regards,
> > Sergei.
>=20
> --=20
> <http://www.alejandro-colomar.es/>
> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5