From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dmitry V. Levin" Subject: Re: [PATCH] ptrace.2: Improve clarity for multi-threaded tracers Date: Mon, 18 Feb 2019 01:15:24 +0300 Message-ID: <20190217221523.GA9233@altlinux.org> References: <48bb7c89-abb9-1e88-fee3-fb42d4032d12@nh2.me> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Niklas =?utf-8?Q?Hamb=C3=BCchen?= Cc: mtk.manpages@gmail.com, linux-kernel@vger.kernel.org, cleverca22@gmail.com, linux-man@vger.kernel.org List-Id: linux-man@vger.kernel.org --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Feb 17, 2019 at 05:34:46PM +0100, Niklas Hamb=C3=BCchen wrote: > Until now, the man page said: >=20 > Attachment and subsequent commands are per thread: > in a multi=E2=80=90 threaded process, every thread can be individuall= y attached to a > (potentially different) tracer, or left not attached and thus not deb= ugged. > Therefore, "tracee" always means "(one) thread", never "a (possibly > multithreaded) process". >=20 > While the first sentence "Attachment ... [is] per thread" might be interp= reted > as holding for both tracer and tracee, the rest talks only about the > multi-threadedness of the *tracee*, leaving some uncertainty in the reade= r on > whether the tracer may issue `ptrace()` from different threads. >=20 > This patch adds more explicitness, removing any doubt. Thanks for making an attempt to remove any doubt. Yes, ptrace'ing is per task_struct on both sides. > Relevant resources: >=20 > * LKML thread https://marc.info/?l=3Dlinux-kernel&m=3D155036848808748&w= =3D2 > "ptrace() with multithreaded tracer" > where I asked about this behaviour, in case anybody disagrees with my > understanding > * https://stackoverflow.com/questions/18737866/can-a-thread-trace-a-proce= ss/ > where the previous ambiguity of the man page confused some users, and w= here > and example program is given that confirms the behaviour I mention in t= his > patch > * A program of mine, in which I have independently confirmed that using > `ptrace()` from a thread that's not the tracer thread (a sibling thread= in > the process is the tracer instead) results in `ESRCH` > * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree= /kernel/ptrace.c?id=3D96d4f267e40f9509e8a66e2b39e8b95655617693#n207 > where the comment on `ptrace_check_attach()` talks about `%current`, wh= ich > is a thread >=20 > Signed-off-by: Niklas Hamb=C3=BCchen > --- > man2/ptrace.2 | 14 ++++++++++---- > 1 file changed, 10 insertions(+), 4 deletions(-) >=20 > diff --git a/man2/ptrace.2 b/man2/ptrace.2 > index 3b6b6ea84..4058abe94 100644 > --- a/man2/ptrace.2 > +++ b/man2/ptrace.2 > @@ -122,12 +122,18 @@ It is primarily used to implement breakpoint debugg= ing and system > call tracing. > .PP > A tracee first needs to be attached to the tracer. > -Attachment and subsequent commands are per thread: > -in a multithreaded process, > +Attachment and subsequent commands are per thread, > +on both the tracer and tracee side. > +Issuing a tracing command from a thread that is not the tracer of the gi= ven > +.I pid > +will result in an > +.B ESRCH > +error. This is confusing. What do you mean by a tracing command? Is PTRACE_TRACEME a tracing command? PTRACE_ATTACH? PTRACE_SEIZE? I suggest leaving the explanation of ptrace return code to "ERRORS" section. > +In a multithreaded process to be traced, > every thread can be individually attached to a > (potentially different) tracer, > or left not attached and thus not debugged. > -Therefore, "tracee" always means "(one) thread", > +Therefore, "tracer" or "tracee" always mean "(one) thread", > never "a (possibly multithreaded) process". > Ptrace commands are always sent to > a specific tracee using a call of the form > @@ -2259,7 +2265,7 @@ or (on kernels before 2.6.26) be > .TP > .B ESRCH > The specified process does not exist, or is not currently being traced > -by the caller, or is not stopped > +by the calling thread, or is not stopped > (for requests that require a stopped tracee). > .SH CONFORMING TO > SVr4, 4.3BSD. I agree the current text can be made more clear on the subject, but, unfortunately, proposed change makes the description more confusing. --=20 ldv --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJcadz7AAoJEAVFT+BVnCUIDrcP/3dgjqHOr3EgIUXMV6AiC12n Gp7OtjbDO4DDsTJC4GR/4GZEx9NZQFr712XZIGgxmOIphikJ3wzvGilnzUyg1TDe sE0zN1hgFHMbHDwzpPGFT/ysB1hEr2fJtK+QwbNjLjqaUljEjSzaBihz1lFN0zDj f0SJdHqW/R+SjUF1uixR9j19IUzyL6TxL6AqkPjBKndIr8bVXrdSn1XMROxJIejv 0rdsnW9474N2Ki4mKiZ6eqOjSFLrIuL1IgGdOf35scQUm85UcOmO9AcChWXGaRcE tQuQ6yEAYYn1Q7DcGfiBunoD7/+J87stywlkmdEgTvYMsnJ3Cm5GutSEfK9GLrUT Puk60YfqeZH6Pfr+pA6/fcZo3nUFwzemfHUsTXcG7m2l9M8H12tAmgGuf62Kobrg wqs2yiVkL2I2iWir00b/pJ6ebpHyZ/dKPKhVV0dd7W3EIdSL20FM93mQAnvM7/z7 FW0RpOn1fDTX9AqMW4gyK6DwTPw6lJ9bCkFilbqocGJTiiVyT3rZIRHqFuVDS22B 2XI2YnGpUrEVr6+8eGk44wIMSG9tFcJeL7NIqGcLbL0XZTxoesHPRl+Ij4KE09Yq WDhyqaVVheU7fRiZ0vbuZejY3AHjf1jFaTOHqevkZZTZ7JJLpu6yQiNUF5L+eqF/ wai+x8lr3iGgjtXfxMhw =5uSA -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY--