Diff: http://people.freebsd.org/~will/patches/fix-fasttrap-panic.diff
Commit log:
Fix a panic in userspace dtrace.
The bug here is that the proc lock is already held in the case of
fasttrap_fork(), which then calls proc_ops(), which tries to hold
it again.
Upon inspection, every other consumer of proc_ops() has already
placed a hold and then dropped the proc lock. Change fasttrap_fork()
to match these semantics, which also happen to mirror Solaris.
Change proc_ops() to assert that the proc object is held and unlocked,
rather than executing a hold/rele cycle itself.
Note: fasttrap_fork() is only ever called if an userspace program
being dtrace'd happens to fork(). So this bug doesn't apply if you
are dtrace'ing a userspace process that doesn't fork.
Also, at least for ztest, userspace dtrace is still unusable because
when the child process exits, both dtrace and ztest appear to spin
forever. The dtrace process doesn't appear to do anything; the ztest
process can't be attached via gdb since it's already being ptrace()'d
by dtrace. This will require more investigation to fix.
The commit log is a bit dated; I believe that more recent changes by
gibbs@fixed the latter issues.
Thanks,
--Will.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
