Re: bug in task server startup code

[Bas Wijnen]

Marcus Brinkmann wrote:
> > > Mapping memory is to be considered a restricted operation.  We can
> > > enforce that by using redirectors.
> >
> > Eh, I don't see the problem.  What's wrong with threads mapping their 
> > memory to other threads?
>
>
> It consumes kernel memory.
...
> (The Hurd design doesn't even use recursive mappings - all mappings
> are done flat by physmem.)

I tend to agree with Neal that using redirectors for all IPC operations 
is too much overhead, however, it would be neccesary if this problem 
cannot be solved.  However, I think it can, there are two ways that I 
can think of (both of which involve changing the kernel, which is not 
nice, but IMO much better than redirecting all IPCs.)

- One solution is to make IPC of map items a priviledged action, which 
can only be done by threads in the root server's address space (like 
priviledged system calls.)  This is probably a small patch for the 
kernel, and the L4 people may even want to include it in their official 
version if it can be switched on and off at compile time.  Then mapping 
memory is done by wortel through physmem, like creating threads is done 
by wortel through task.

- The other solution is to put the page tables in user space, like the 
UTCB area.  In that case, an address space will have a maximum number of 
mappings.  This seems like a theoretically nice solution, however I 
don't know if it fits at all into the current design of the kernel, and 
I expect it to be a huge change.  I also don't know the performance 
implications.  I'm guessing the L4 people thought of it and rejected it 
for some reason.  It's not something we should do, anyway.

So I think there are two options here: use redirectors or make mapping a 
priviledged operation.  I prefer the last one.

> String items can be supported, but one must be careful.
>
> The idea is that you allow page faults on the server side to happen,
> but not on the client side[1].  The client must then lock down all
> memory needed for string items to or from the server.  This is easier
> said than done, especially if you don't know up-front how long the
> reply is going to be.  There is a whole paper on this issue (by
> someone else, in fact, the paper that made me start to worry about
> this in detail), and I have written about it in length before.  Look
> at the xfer timeout parameter of the IPC system call for how to avoid
> being blocked when page faults occur.

If the server can not trust the client, how can it know about the memory 
it uses?  I thought the server could only send a string item (or accept 
one), not know where it's coming from.

> It's thus a bit complicated to use string items, but they are an
> important optimization.  You can't just always pass container handles
> to mappable memory around, for example for every filename you want to
> lookup.  We have to decide how to use this on a case-by-case basis.

I was expecting to use the untyped words for short messages (perhaps 
using some follow-up code to use slightly more space if needed by using 
several IPCs) and map containers for large messages.  There are 64 MRs, 
of which at least 1, but likely 2 will be needed to encode the purpose 
of the transfer.  That leaves (on a 32-bit system) 62*4=248 bytes per 
IPC for a short message.  Things like filenames should usually fit in it.

Of course at some point using a container will be a better idea.  There 
can be a library function which considers using IPC and a container, and 
just uses which is appropriate.  The caller doesn't need to know how the 
transfer was done :-)

I understand that string items can speed things up, especially if the 
size is just a little more than 62 words.  However, doing all the 
checking for correct string buffers probably slows the whole thing down 
again.

Just one more idea: Allow transfers to be done using a third task, which 
 holds a permanent container with the server.  This task is run by the 
user, so the program which wants to send or receive the data has mutual 
trust with it.  The string transfer can then be done between those, for 
example directly into the container.  The server has a container it can 
write in and read from (which doesn't need to be created and destroyed 
every time, of course), so it should be happy.

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature