Date: Wed, 24 Jun 1998 17:51:16 -0700 From: Mike Smith <mike@smith.net.au> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: lkm MALLOC interactions, new proc field Message-ID: <199806250051.RAA00374@antipodes.cdrom.com> In-Reply-To: Your message of "Mon, 22 Jun 1998 12:33:59 EDT." <Pine.BSF.3.96.980622121719.7467B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > As part of my work relating to the Coda Project, and other code making use > of tickets/tokens/etc for authentication, I am writing a loadable kernel > module providing a syscall and hooking some process events (such as fork, > exit) to maintain in-kernel Process Authentication Groups (PAGs). > However, I have run into a few small problems. > > 1) I make use of MALLOC_DEFINE() to define three new structure types to > track memory use in the lkm. However, when I unload the lkm, vmstat -m > gets quite upset. Is there a way I can "unregister" my types with the > kernel MALLOC routines to prevent this from happening? (the malloc_type > structure is in the lkm's memory space, of course, so this is the source > of the problem anyway). Should I just not be doing this? Is this support > already there, and it is just that I am leaking memory? :) There is no support for removing a malloc type; there needs to be a counterpart to kern/kern_malloc.c:malloc_init() which checks the ks_inuse field and then removes the structure from the list. To do this "right" the list should be updated to use the QUEUE macros. If you instantiate the malloc type in your module, you need to remove it before you allow the module to be removed, as otherwise you break the type chain (as you have noticed). > 2) I am running on a rather old version of -CURRENT on my kernel dev > machine right now (January or something :) -- the snap server was down for > a while so I have not upgraded. Anyhow, in this version of FreeBSD, the > MALLOC(9) man page has an error -- the sample code given reverses the > size and typecast fields for MALLOC are reversed. This may have been > corrected long since, but thought I would let you know as this was > initially puzzling :). This is probably worth opening a PR on. 8) > 3) I have been going through extreme contortions to maintain state > associated with processes without making any modifications to the base > FreeBSD kernel, and keeping everything in the lkm. However, this is > getting more and more troublesome, and interfering with the structures, > etc, I have been using. I don't know if there is interest in moving any > of this code into the base FreeBSD distribution (it is currently heavily > un-optimized and highly xperimental), but it would be helpful to add a > field to the proc structure for use by authentication extensions, perhaps > something like this: > > void *p_authdata; /* extended authentication hook */ > > As well as a global indicating whether an lkm has claimed the right to use > the hook yet. Alternatively, some registration system, and arrays or > something, but that is probably overkill. By default, this field would be > zero'd at proc creation, but at_fork/etc routines could fill it in as > desired. I don't know what the architecture mavens would think about this; it does sound like an excellent candidate for a small hashtable or similar for "assorted process-related data". You'd want at least two sets; one in the "zeroed on creation" and one in the "copied on creation" regions. I'm not sure if we have a generic hashtable manager in the kernel yet, but I have heard at different times from several people that have such an anmial available. Argh; more infrastructure. > 4) ENOENT is described all over the place as file-not-found -- is there an > errno return that is meant to be used as a generic "Object not found" that > could be used? "File Not Found" seems like a strange error from perror > when a Coda token cannot be retrieved by a supporting daemon :). You might want to report the reason that the token can't be obtained, rather than the fact that it can't. The reason might be more useful to the user, as well as (maybe!) fitting the "set of all errors" that we have. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806250051.RAA00374>