On 11.02.2017 17:18, Christos Zoulas wrote: > In article <897028fd-f18a-9ec4-bd5f-3930f40dcaca%gmx.com@localhost>, > Kamil Rytarowski <n54%gmx.com@localhost> wrote: >> >> 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. > > Write a test and I will take a look. > patch-00028-pt_suspend-pt_resume.txt-resume2 ships with resume2 test triggering this. This test hangs waiting on not correctly unstopped thread. I'm also not fully sure that resume1 is behaving always correctly. When I added more synchronization handshakes I was receiving undetermined results - once thread exited silenly and the other time it was detectable with _lwp_wait(2). >> 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". > > I think this was for backwards compatibility with unthreaded code. If > it bothers you, remove it. It does not matter since the pthread(2) consumers > are few, and since you are changing already a lot in interface... > I will try to dig for historical references. If there were consumers of this behavior, I will leave it as it is. So far new interfaces are mostly backwards-compatible in terms of not breaking existing software (I'm not aware of anything that was broken). >> 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. > > What does that mean exactly? Do you mean kernel lwp's that are dedicated > to kernel tasks, instead of kernel lwp started from userland to be used > as in-process threads? You mean the LW_SYSTEM tests? Look in kern_lwp.c, > there are KASSERTS for that already... > Yes, LW_SYSTEM checks. I will try to dig for it. >> Thank you for the initial review. > > You are always welcome :-) > > christos >
Attachment:
signature.asc
Description: OpenPGP digital signature