Re: rump core on module load

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Sat, May 06, 2017 at 06:01:36AM +0800, Paul Goyette wrote:
> On Fri, 5 May 2017, Patrick Welche wrote:
> 
> > Toying with a kernel module,
> > 
> > export RUMP_SERVER=unix:///tmp/sock
> > rump_allserver -svm /usr/src/sys/modules/abt/obj.amd64/abt.kmod ${RUMP_SERVER}
> > 
> > dumps core. The odd thing is that modload is happy!
> > 
> > #0  0x00000000e5405e57 in ?? ()
> > #1  0x00007f7fe48b0efb in module_do_load (name=0x7f7ff7bccc00 "/module.mod",
> >    isdep=false, flags=0, props=0x0, modp=0x0, modclass=MODULE_CLASS_ANY,
> >    autoload=false)
> >    at /usr/src/lib/librump/../../sys/rump/../kern/kern_module.c:1127
> > #2  0x00007f7fe48afd0b in module_load (filename=0x7f7ff7bccc00 "/module.mod",
> >    flags=0, props=0x0, modclass=MODULE_CLASS_ANY)
> >    at /usr/src/lib/librump/../../sys/rump/../kern/kern_module.c:593
> > #3  0x00007f7fe484e78c in handle_modctl_load (
> >    ml_filename=0x204297 "/module.mod", ml_flags=0, ml_props=0x0,
> >    ml_propslen=0)
> >    at /usr/src/lib/librump/../../sys/rump/../kern/sys_module.c:103
> 
> The address in traceback #1 appears to be the retrun from calling the
> module's xxx_modcmd(MODULE_CMD_INIT, ...) so I would add some printf()s into
> the module to see why it is dying.

Agreed that my lashed together module is probably to blame, but
why would modload be happy, but not rump? What is the difference?
(I would expect both to break.) ((Re #1, /module.mod is ETFSKEY
and not mine))

Cheers,

Patrick