Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jun 1998 12:33:59 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        freebsd-hackers@FreeBSD.ORG
Subject:   lkm MALLOC interactions, new proc field
Message-ID:  <Pine.BSF.3.96.980622121719.7467B-100000@fledge.watson.org>

next 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? :)

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 :).

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.

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 :).

Thanks,

  Robert N Watson 

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/
robert@fledge.watson.org              http://www.watson.org/~robert/


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?Pine.BSF.3.96.980622121719.7467B-100000>