Date: Tue, 13 Jun 1995 10:30:04 -0700 From: wpaul@skynet.ctr.columbia.edu To: freebsd-bugs Subject: kern/507: Trying to load if_sl_mod or if_ppp_mod *twice* crashes system Message-ID: <199506131730.KAA22866@freefall.cdrom.com> In-Reply-To: Your message of Tue, 13 Jun 1995 13:20:04 -0400 <199506131720.NAA00962@skynet.ctr.columbia.edu>
index | next in thread | previous in thread | raw e-mail
>Number: 507 >Category: kern >Synopsis: Trying to load if_sl_mod or if_ppp_mod *twice* crashes system >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs (FreeBSD bugs mailing list) >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jun 13 10:30:02 1995 >Originator: Bill Paul >Organization: Center for Telecommunications Research, Columbia University >Release: FreeBSD 2.0.5-RELEASE i386 >Environment: FreeBSD 2.0.5-RELEASE 386sx/16Mhz CPU with 80387 FPU 4 MB RAM (yes, it works :) NEC 765 floppy controller with 2 floppies 2 IDE controllers (wdc0, wdc1) 2 Seagate ST351A/X drives (wd0 and wd2) 1 Maxtor 7345 AT drive (wd1) 3 serial ports (sio0, sio1, sio2) 2 parallel ports original 8-bit mono SoundBlaster card SMC SMC8416C/SMC8416BT plug & play ethernet adapter (ed0) STB PowerGraph ET4000-based SVGA display adapter (1MB RAM) (sc0) external USRobotics Sportster 14.4 moded (with FAX) on /dev/cuaa1 System kernel is compiled with support for all hardware devices, but SLIP, PPP, NFS and procfs support is loaded dynamically at boot time using loadable kernel modules. I have rebuilt the SLIP and PPP modules to support the Berkeley Packet Filter since I have BPF configured into my kernel, however this does not influence the manifestation of the bug: both my rebuilt modules and the stock modules distributed with the 2.0.5R bindist exhibit the same broken behavior. >Description: The 'pseudo-lkms,' such as if_sl, if_ppp (and probably if_tun too though I haven't tested that one yet) appear to get just a little too far into their initialization before checking for the existance of duplicate modules. In my configuration, if_sl_mod.o is loaded by netstart when the system boots. This first instance of the SLIP driver works perfectly by itself (I'm writing this bug report on my home machine from work over the SLIP link now). However, attempting to load the if_sl_mod.o module for a second time causes the system to lock up or panic (the exact outcome depends on the phase of the moon, the direction of the wind and other irreproducible phenomena). You're supposed to get an error and the module should simply fail to load. Instead, you get an error, and then the system self-destructs. There's supposed to be some checking done to prevent the loading of two instances of the same module, but the checks don't seem to work correctly for LM_MISC pseudo_lkms. When the second instance of the module is loaded, you do indeed get an error telling you that there's a duplicate module present, but the checking is done too late; by the time modload gets hit with EEXIST, the module has already been initialized and has irrevocably wired itself into the system. Once the error has been detected, an attempt is them made to unreserve the memory occupied by the duplicate module, which causes the system to either hang or crash a short while later. >How-To-Repeat: # modload -e if_sl_mod -o /tmp/if_sl /lkm/if_sl_mod.o # modload -e if_sl_mod -o /tmp/if_sl /lkm/if_sl_mod.o [modload will complain 'file exists' then the system will die] >Fix: I think this is a case of misplaced sanity checking. Digging through the tangle of macros used to implement the PSEUDO_LKMs has led me to the conclusion that the 'init' function (in this case slattach()) is being called before lkmdispatch(), with the difficulty being that lkmdispatch() (which is in the kernel) is the function that does the duplicate module checking. (Hijinks ensue, and all that.) With the other LKMs (the VFS ones, for instance), the module initialization is left up to specific kernel functions that are called by lkmdispatch(), so in those cases the sanity checks work correctly. But if_sl, if_ppp, etc. are LM_MISC type modules which are largely left to their own devices (no pun intended). One way I can think of to fix this would be to make the LKM_E_LOAD case of the DISPATCH() macro (/usr/include/sys/lkm.h) do more sanity checking before marching off and invoking the module's initialization function. If it's possible to call lkmexists() from there, this would be ideal. >Audit-Trail: >Unformatted:home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506131730.KAA22866>