Messages in this thread | | | Subject | Re: [PATCH] ptrace: Allow other threads to access tracee | From | Jim Newsome <> | Date | Thu, 11 Mar 2021 10:49:19 -0600 |
| |
On 3/11/21 09:21, Oleg Nesterov wrote: > Cough... it is not that simple. Yes, I was afraid of that :) > Just suppose that 2 threads call ptrace(tracee) at the same time. Say, the 1st > thread does PTRACE_CONT while the 2nd thread tries to change the registers.
Is it acceptable for the new register-values to be lost, or even corrupted, in this case? From my perspective it is, if the tracer failed to synchronize itself, but maybe there's an overarching philosophy that syscalls should be "atomic"?
I suppose even if the corruption of the register-values-themselves is acceptable, some synchronization may be needed to avoid the possibility of corrupting the kernel's data structures?
Is it "just" a matter of adding some locking? Would a relatively coarse lock on the target task over the duration of the ptrace call (which I believe is always non-blocking?) be acceptable, or would we need finer grained locking in places where we actually touch the target task? And do you have a feel for whether you'd be inclined to accept such a patch once that (or whatever actually is needed) is added?
Thanks!
-Jim
| |