[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
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?

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.


(for commands which require a stopped tracee)

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

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


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