Re: mach_msg blocking on call to vm_map

[Brent W. Baccala]

On Thu, Sep 1, 2016 at 2:16 PM, Richard Braun <rbraun@sceen.net> wrote:

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.

I've implemented this approach in the latest version of netmsg.  In addition to isolating the effects of a blocking mach_msg call, this also has the advantage of dealing (in the same way) with OOL data backed by a faulty memory manager that causes the memory access to block indefinitely.

Of course, we really don't want our memory managers stalling indefinitely, and, to that end, I've implemented the following, very simple, change to libpager.  It just notifies the kernel that it can't handle a particular memory object request, rather than remaining silent:

 --- /home/baccala/src/hurd/libpager/object-init.c    2016-08-03 12:11:39.099553252 -1000
+++ object-init.c    2016-09-07 12:05:24.825456046 -1000
@@ -54,6 +54,8 @@
     p->init_head = i;
       p->init_tail = i;
 #else
+      memory_object_ready (control, p->may_cache, p->copy_strategy);
+      memory_object_destroy (control, EBUSY);
       printf ("pager dup init\n");
 #endif     
       goto out;

It's not perfect.  It leaks ports, since it never destroys the control and name ports, but fixing that is not so trivial as just releasing the send rights, because the kernel will follow up the memory_object_destroy with a memory_object_terminate that includes the receive rights on those ports.

What this change does do, however, is expose the bug in glibc that I just opened a bug report on.  Once that's dealt with (and the current netmsg code deals with it), then attempting to exec a remote program using the standard exec server doesn't hang, but instead produces a "Killed" message along with a slew of warnings from netmsg.

I consider this progress!

    agape

    brent