lkml.org 
[lkml]   [2019]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ptrace.2: Improve clarity for multi-threaded tracers
From
Date
Hey Dmitry,

On 2019-02-17 23:15, Dmitry V. Levin wrote:
>> 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 was referring to the same command as in other places in the man page, as in the existing sentences

Most ptrace commands [...] require the tracee to be in a ptrace-stop, otherwise they fail with ESRCH.

or

(for commands which require a stopped tracee)

Would thus "ptrace command" be better than "tracing command" here?

>> .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.

Do you mean "calling thread" is more confusing than "caller"?
If yes, what would you suggest instead?

My intent here was to, for anybody who encounters ESRCH and looks it up in an effort to see what's going on, make clear that threads are important here.

Or should I switch to `task_struct` terminology? That wouldn't be userspace terminology though, and the rest of the man page also talks about threads.


Niklas

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-04-21 17:07    [W:0.090 / U:1.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site