Date: Sun, 23 Aug 1998 02:55:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: bright@www.hotjobs.com (Alfred Perlstein) Cc: current@FreeBSD.ORG Subject: Re: PEBCAK with modunload. Message-ID: <199808230255.TAA20534@usr04.primenet.com> In-Reply-To: <Pine.BSF.3.96.980821115106.305N-100000@bright.fx.genx.net> from "Alfred Perlstein" at Aug 21, 98 12:00:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> this might be fixed but i don't want to test it for obvious reasons. > > if you unload the linux emulator while linux programs are running you will > crash your box. (forgot i had x11amp running) Return non-zero from the LKM unload code in the module to veto unloading. > ~ % modunload -i 3 > Error: you have linux programs running. Specify -f to force. > (list of pids/commands passed back somehow from the lkm) Already possible to veto unload. The message is problematic, but can be implemented using a console message (kernel printf) for minimal function. > ~ % modunload -f -i 3 > Killing all linux programs running. > (list of pids follow, then the lkm is unloaded) Also possible, from within the kernel module, if you are willing to potentially hang the modunload in an ioctl on /dev/lkm (ie: a blocking device driver control to the lkm pseudo-device). This should not be a big problem, but it's a potential one. > the reason this would be nice is that you can get "inuse" errors and other > lkms can then refuse to unload unless told to forcfully do so. They could > then revoke access to files/devices they control for other lkms such as > filesystem lkms and device lkms. All LKM's are permitted to refuse unload. Whether or not they actually do so is implementation defined. The ability to crash the system is one of the reasons LKM twiddilng is limited to root credentialed processes. Busy system calls and filesystems are relatively trivial; the close being called only on last close of a device is problematic for resource tracking purposes, but if all you need is an "is everyone out of the pool?" mechanism, that's pretty trivial as well. I believe my sample LKM for system calls tracked usage an vetoed unload. To implement "drain", you need merely to disable the entry point, per the normal unload process, but not unload until the reference count goes to zero. This will require that you implement using a "generic" rather than a type-specific LKM type, to allow you to catch the vetoed unload request and actually prohibit future access to the device, system call, etc.. The normal semantics of a refusal to unload assume that the user space program wanting the unload will retry again later, and that subsequent reentry is not a problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808230255.TAA20534>