user malloc from kernel

[Terry Lambert]

Pawel Jakub Dawidek wrote:
> On Mon, Sep 29, 2003 at 06:56:13PM +0300, Peter Pentchev wrote:
> +> I mean, won't the application's memory manager attempt to allocate the
> +> next chunk of memory right over the region that you have stolen with
> +> this brk(2) invocation?  Thus, when the application tries to write into
> +> its newly-allocated memory, it will overwrite the data that the kernel
> +> has placed there, and any attempt to access the kernel's data later will
> +> fail in wonderfully unpredictable ways :)
> 
> I'm not sure if newly allocated memory will overwrite memory allocated
> in kernel, but for sure process is able to write to this memory.
> 
> Sometime ago I proposed model which will allow to remove all copyin(9)
> calls and many copyout(9), but I'm not so skilled in VM to implement it.

You probably need two pages; one R/O in user space and R/W in
kernel space, and one R/W in both user and kernel space.  The
copyin() elimination would use the R/W page.  Frankly, I have
to say that you aren't saving much by eliminating copyin() this
way, and most of your overhead is going to be data copies with
pointers, and it doesn't really matter where you get the pointers
into the kernel, the bummer is going to be copying around the
data pointed to by the pointers.

For the copyout, you'd probably get a rather larger benefit if
you could implement getpid(), getuid(), getgid(), getppid(), and
so on, in user space entirely, just by referencing the common
read-only page.

You could probably also benefit significantly by deobfuscating
the timer code and using a flip-flop timer and externalizing
the calibration information in a single globally read-only
page (PG_G, PG_U, R/O mapping one place, kernel-only R/W mapping
another), and then using it to implement a zero system call
gettimeofday() operation (there's really no need to have a huge
list of timers, if updates are effectively atomic at the clock
interrupt, and you use a flip-flop pointer to only two contexts
instead of a huge number of them).

Specifically, you could find yourself with a huge performance
improvement in anything that has to log in the Apache/SQUID
styles, which require a *lot* of logging, which would mean a
*lot* of system calls.

You could also use a knote for this, which is only returned
when other knote's are returned, and not otherwise, but that
would be a lot less friendly to third party source code that
was not specifically adulterated for FreeBSD.

-- Terry