From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: "Niklas Hambüchen" <mail@nh2.me>
Cc: "Dmitry V. Levin" <ldv@altlinux.org>,
lkml <linux-kernel@vger.kernel.org>,
cleverca22@gmail.com, linux-man <linux-man@vger.kernel.org>
Subject: Re: [PATCH] ptrace.2: Improve clarity for multi-threaded tracers
Date: Mon, 25 Feb 2019 16:51:10 +0100 [thread overview]
Message-ID: <CAKgNAkhNCE24+QEYpQjcAjN2ktQe_JdAd7sP9rHR90iA228-yw@mail.gmail.com> (raw)
In-Reply-To: <20190217221523.GA9233@altlinux.org>
Hi Niklas,
Do you plan to revise this patch in the light of Dmitry's comments?
Thanks,
Michael
On Sun, 17 Feb 2019 at 23:15, Dmitry V. Levin <ldv@altlinux.org> wrote:
>
> Hi,
>
> On Sun, Feb 17, 2019 at 05:34:46PM +0100, Niklas Hambüchen wrote:
> > Until now, the man page said:
> >
> > Attachment and subsequent commands are per thread:
> > in a multi‐ threaded process, 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", never "a (possibly
> > multithreaded) process".
> >
> > While the first sentence "Attachment ... [is] per thread" might be interpreted
> > as holding for both tracer and tracee, the rest talks only about the
> > multi-threadedness of the *tracee*, leaving some uncertainty in the reader on
> > whether the tracer may issue `ptrace()` from different threads.
> >
> > 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:
> >
> > * LKML thread https://marc.info/?l=linux-kernel&m=155036848808748&w=2
> > "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-process/
> > where the previous ambiguity of the man page confused some users, and where
> > and example program is given that confirms the behaviour I mention in this
> > 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=96d4f267e40f9509e8a66e2b39e8b95655617693#n207
> > where the comment on `ptrace_check_attach()` talks about `%current`, which
> > is a thread
> >
> > Signed-off-by: Niklas Hambüchen <mail@nh2.me>
> > ---
> > man2/ptrace.2 | 14 ++++++++++----
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > 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 debugging 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 given
> > +.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.
>
>
> --
> ldv
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
next prev parent reply other threads:[~2019-02-25 15:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <48bb7c89-abb9-1e88-fee3-fb42d4032d12@nh2.me>
2019-02-17 16:34 ` [PATCH] ptrace.2: Improve clarity for multi-threaded tracers Niklas Hambüchen
2019-02-17 22:15 ` Dmitry V. Levin
2019-02-25 15:51 ` Michael Kerrisk (man-pages) [this message]
2019-04-21 14:58 ` Niklas Hambüchen
2019-04-21 14:57 ` Niklas Hambüchen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKgNAkhNCE24+QEYpQjcAjN2ktQe_JdAd7sP9rHR90iA228-yw@mail.gmail.com \
--to=mtk.manpages@gmail.com \
--cc=cleverca22@gmail.com \
--cc=ldv@altlinux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mail@nh2.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).