user malloc from kernel

[Peter Pentchev]

On Mon, Sep 29, 2003 at 05:04:05PM -0700, Brian O'Shea wrote:
> --- Peter Pentchev <roam at ringlet.net> wrote:
[actually, Pawel wrote this:]
> > > Here you got sample kernel module which do this:
> > > 
> > > 	http://garage.freebsd.pl/usmalloc.tgz
> > > 	http://garage.freebsd.pl/usmalloc.README
[and then I replied]
> > 
> > Errrr... but won't this interfere *badly* with userland programs
> > which attempt to allocate memory after making the syscall in question?
> 
> Couldn't the user library interface to this new system call just
> malloc() the memory first in the process, and then pass the pointer
> and size to the kernel via the system call interface?  This would
> ensure that malloc() doesn't touch the desired range of memory until
> it is freed by the user.  You'd just have to be careful not to free
> it until the kernel is done with it.

This would be my preferred solution, too, although it might mean that
when you are not exactly sure of how much memory the kernel will need,
you either overallocate and pass a max-size argument (see most of the
socket calls like accept(2), getsockname(2), getpeername(2), etc), or
you do two syscalls, one for determining the size needed, and another
for actually copying the data (see sysctl(3)).  The second approach is
more robust, but it does have the overhead of an additional syscall and
might also possibly be vulnerable to a race (if the data should change
between the two invocations).  This, of course, could be worked around
by having another couple of syscalls for locking and unlocking the data
- lock, query size, fetch, unlock - but that would open a whole new can
of worms :)

G'luck,
Peter

-- 
Peter Pentchev	roam at ringlet.net    roam at sbnd.net    roam at FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
If wishes were fishes, the antecedent of this conditional would be true.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20030930/3c6d350a/attachment.bin