On 11.02.2017 04:15, Christos Zoulas wrote: > On Feb 11, 12:49am, krytarowski%gmail.com@localhost (Kamil Rytarowski) wrote: > -- Subject: LWP resume and suspend ptrace(2) API > > | I'm proposing an API to restore the functionality to resume or suspend a > | specified thread from execution. > | > | This interface was implemented in the past in user-space inside > | pthread(3) with the M:N thread model (with help from removed pthread_dbg). > | > | http://netbsd.org/~kamil/patch-00028-pt_suspend-pt_resume.txt > > - The second _lwp_continue should be _lwp_suspend in the man page. > - I don't like the phrasing "Lock" and "Unlock". What are you locking here? > Why not suspend/resume execution; or prevent/allow executiom. > I will apply these notes. > | This code is close to FreeBSD and shares the same request names > | (PT_RESUME and PT_SUSPEND), however on NetBSD we pass the full pair of > | tracee's pid_t and thread's lwpid_t. FreeBSD specifies just thread ID, > | which is insufficient on NetBSD, as a single tracer can control multiple > | tracees and face duplicated lwpid_t. > | > | I've added an interface to detect if a specific LWP has been suspended > | (or not) with extending the PT_LWPINFO interface with a new pl_event > | value PL_EVENT_SUSPENDED (next to PL_EVENT_NONE and PL_EVENT_SIGNAL). > | > | There is a new check preventing deadlocks and ptrace(2) can set with > | this patch new errno EDEADLK. I haven't checked the existing code but it > | appears that we can deadlock tracee with current PT_CONTINUE and friends. > > Otherwise nicely done :-) > There is one nit... this code (at least to my tests) cannot unstop a thread that was created by a tracee with LWP_SUSPENDED. http://netbsd.org/~kamil/patch-00028-pt_suspend-pt_resume.txt-resume2 (man pages will be applied in next patch) Are there needed more actions to be performed? I had some trouble to call lwp_continue from ptrace(2) and not managed to make it work. There is undocumented behavior that passing LWP ID when a process has single thread results in ignoring the passed value and detecting the proper one. For example this code will always return proper value for a single-threaded process, no matter what the LWP ID is. ptrace(PT_GETREGS, child, &r, 123) Can I streamline it and remove fallback to an existing LWP? I don't see a "feature" in this "bug". Can a user-space process contain in-kernel threads? Is this used for compat with old userland? I was thinking about switching branch for in-kernel-thread to KASSERT(). It would make the code cleaner. Thank you for the initial review.
Attachment:
signature.asc
Description: OpenPGP digital signature