On Wed, 25 Feb 2015, Ryota Ozaki wrote:
A quick fix is: diff --git a/external/cddl/osnet/dev/dtrace/dtrace_modevent.c b/external/cddl/osnet/dev/dtrace/dtrace_modevent.c index 9df0cd1..40c8e7f 100644 --- a/external/cddl/osnet/dev/dtrace/dtrace_modevent.c +++ b/external/cddl/osnet/dev/dtrace/dtrace_modevent.c @@ -38,6 +38,8 @@ dtrace_modcmd(modcmd_t cmd, void *data) case MODULE_CMD_FINI: dtrace_unload(); return devsw_detach(NULL, &dtrace_cdevsw); + case MODULE_CMD_AUTOUNLOAD: + return EBUSY; default: return ENOTTY; } It prevents auto-unloading. It should fix the problem....note that unloading dtrace.kmod by modunload with dtrace command running also causes panic. We need to fix dtrace unload procedures somehow :-/
Some sort of ref-count might be needed? Or some way to check and see if any of the trace-points are in use?
You might check to see if a mechanism similar to what is used for other modules that provide sys-calls. Without the module loaded, the syscall entry point is known no-op; when the module tries to unload, all of its syscalls are checked, and if any of them points to somewhere NOT THE NOOP, unload is prevented.
------------------------------------------------------------------------- | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -------------------------------------------------------------------------