tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: LWP resume and suspend ptrace(2) API




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



Home | Main Index | Thread Index | Old Index