Date: Thu, 28 Mar 2013 11:36:10 -0600 From: Will Andrews <will@firepipe.net> To: hackers@freebsd.org Cc: George Neville-Neil <gnn@neville-neil.com>, "Justin T. Gibbs" <gibbs@freebsd.org> Subject: CFR: Fix a panic in userspace dtrace Message-ID: <CADBaqmiminskLPGTh7AcR9svKn3dG=5Uhumt47oM56kFEzrweg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADBaqmiminskLPGTh7AcR9svKn3dG=5Uhumt47oM56kFEzrweg>