Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Revisiting DTrace syscall provider



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  |
-------------------------------------------------------------------------


Home | Main Index | Thread Index | Old Index