Re: mach_msg blocking on call to vm_map

[Richard Braun]

On Thu, Sep 01, 2016 at 01:34:43PM -1000, Brent W. Baccala wrote:
> What happened with select?  mach_msg() returned prematurely?  I can handle
> that fine.  In this case, mach_msg() isn't returning at all.

You're missing the point. The point is vm_map has no timeout. In
addition, the fact that the receiver is the kernel certainly makes
it more complicated to predict. See ipc/mach_msg.c:mach_msg_trap()
where the time_out argument is ignored if it's a kernel send, i.e.
when the code branches to the kernel_send label.

> > In my opinion, your network server should do what all servers do,
> > i.e. dedicate a thread to the processing of a complete RPC and spawn
> > as many as necessary when receiving messages.
> >
> 
> I've thought of that.  It might be desirable at some point for performance,
> but do I really need it for correctness?  I just have to accept that
> mach_msg can hang once in a while and make sure that I can burn its thread
> if it does?
> 
> I don't like that idea at all!  It's just ugly.

Well, not ugly. It might be useful if we want to relay scheduling
properties, but even that makes little sense across a network.

Of course, the implementation of mach_msg when handling messages sent
to kernel objects could be changed, but it makes little sense to
implement timeouts on those messages, because the kernel guarantees
immediate processing (the client thread services itself inside the
kernel). Consider how this could be implemented. Should the kernel
act as a true server with its own threads ? Should it queue messages ?
Since there is currently no queueing, and instead the kernel part of
the client thread directly runs the server routine, does it make sense
to state that a send could fail because of a timeout ?

So really, what's happening here is a misbehaving userspace pager
affecting a client that shouldn't have trusted it in the first
place. I'm really not sure how you can truely fix that on a system
such as the Hurd. Perhaps by using this server trusting mechanism
I mentioned, and somehow sharing it with the network server. But
even then, trusting doesn't mean it works, it only means that if
it doesn't, it's on you. So the other users of the network server
shouldn't be affected because one got it wrong.

Therefore I'm going back to the idea of using a thread pool. If a
mach_msg call succeeds, good for you, grab the next message. If not,
at least you're not affecting other users, except maybe through a
denial of service, the only kind of security issue inevitable with
a design where servers allocate from their own resources on behalf
of their clients. That's when you get to things like quotas and
resource limits.

-- 
Richard Braun