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
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:
                return devsw_detach(NULL, &dtrace_cdevsw);
+               return EBUSY;
                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    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index