Roland McGrath wrote:
Thanks, David. That is exactly the right example of using kernel
synchronization primitives with callbacks to implement blocking behaviors
you want. The wrinkle there is that you use UTRACE_INTERRUPT, which
(potentially) perturbs the behavior of every traced thread.
Roland McGrath [EMAIL PROTECTED] writes:
[...]
What the utrace interface has always said about this is, So don't do
that. [...]
What I overlooked is that not just your data structures, but your
callbacks too might be going away, i.e. unloading the kernel module.
I don't think the
Thinking aloud, utrace_control(UTRACE_STOP) returns -EINPROGRESS for
threads not yet stopped
a. possibly still in userspace, yet to pass through a quiesce safe point
b. blocked in the kernel on a syscall or an exception.
Correct.
Would task_current_syscall() help here? On a -EINPROGRESS
Is there a way to avoid using UTRACE_INTERRUPT? Certainly I'd like to
avoid disturbing the processes we're tracing.
That's what the entire asynchronous detach discussion is about!
Wade on in with me and Ananth. The brain piranhas are biting!
Thanks,
Roland
Thanks for the report. This was a simple, stupid bug, affecting all the
error cases from ptrace_attach (and ptrace_traceme), not just attaching to 1.
New patches are up now.
Thanks,
Roland