DragonFlyBSD

Still present on 1.6.2-RELEASE, as I just found out.

md does not have any means to be unloaded. we should either prevent that or add
unload code.

how to reproduce kernel panic on 1.9.0-DEVEL:

cd /dev
sh MAKEDEV md0
disklabel md0

Still happening on 2.0.1
See attached image.

2009/1/22 Antonio Huete Jimenez (via DragonFly issue tracker)
<sinknull@crater.dragonflybsd.org>:

Antonio Huete Jimenez <tuxillo@quantumachine.net> added the comment:

Still happening on 2.0.1
See attached image.

I can reproduce it if and only if md is already compiled in the kernel.

What happens is that when kldloading md, the kernel tries to register
the debug.mddebug sysctl a second time (as md is already in the
kernel). It complains (the "can't re-use a leaf" msg) and stops the
registration but carries on loading the module.

When kldunloading, the kernel tries to unregister the module instance
of debug.mddebug and panics because it was not registered in the first
place.

Is there a way to detect during kldload that the module is already
part of the kernel?

I propose to close this bug as it is caused by incorrect user manipulation.

Well, actually as Simon mentioned earlier, md has not been updated to
work as a module and it leaks memory when unloaded. I'm looking into
it.

Any news about this? If not, disabling the option to unload should be trivial
and would offer a quick fix.

Cheers,
Alex Hornung

Hi,

I think what is happening here is , despite md is already included in the
kernel, the module is not registered and thus modlist_lookup2() doesn't find it,
so kldload() syscall succeeds instead of failing in EEXIST as it should be.

I'm going to try to provide a patch to fix this based on some recommendatiosn
given by Alex.

Cheers,
Antonio Huete

Committed a fix on 89adea1539ab67184124a82cc811031f3334024f