"Ted Unangst" <t...@tedunangst.com> writes:
> On 2022-02-25, Robert Nagy wrote: >> Maybe we need a default vmd class? What do you guys think? > > Regardless of what the limit is, this seems like a daemon where people > will bump into the limit. Perhaps a reminder is in order too? > The reminder is good, but we still need to fix the problem that the vmm process can abort given the child dies so quickly. On my machine, the call to read(2) results in a zero byte read, tripping the existing fatal path. diff ff838b72f50de699ee43d3dac58ff7e8435669ee /usr/src blob - 4c6c99f1133cec7cb1e38dfd22e595e4d2023842 file + usr.sbin/vmd/vm.c --- usr.sbin/vmd/vm.c +++ usr.sbin/vmd/vm.c @@ -26,6 +26,7 @@ #include <sys/socket.h> #include <sys/time.h> #include <sys/mman.h> +#include <sys/resource.h> #include <dev/ic/i8253reg.h> #include <dev/isa/isareg.h> @@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd) ret = alloc_guest_mem(vcp); if (ret) { + struct rlimit lim; + const char *msg = "could not allocate guest memory - exiting"; + if (getrlimit(RLIMIT_DATA, &lim) == 0) + msg = "could not allocate guest memory (data limit is %llu) - exiting"; errno = ret; - fatal("could not allocate guest memory - exiting"); + fatal(msg, lim.rlim_cur); } ret = vmm_create_vm(vcp); blob - eb75b4c587884ec43704420ef4172386a5b39bd9 file + usr.sbin/vmd/vmm.c --- usr.sbin/vmd/vmm.c +++ usr.sbin/vmd/vmm.c @@ -616,6 +616,7 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p int ret = EINVAL; int fds[2]; size_t i, j; + ssize_t sz; if ((vm = vm_getbyvmid(imsg->hdr.peerid)) == NULL) { log_warnx("%s: can't find vm", __func__); @@ -674,9 +675,13 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p } /* Read back the kernel-generated vm id from the child */ - if (read(fds[0], &vcp->vcp_id, sizeof(vcp->vcp_id)) != - sizeof(vcp->vcp_id)) + sz = read(fds[0], &vcp->vcp_id, sizeof(vcp->vcp_id)); + if (sz < 0) fatal("read vcp id"); + else if (sz != sizeof(vcp->vcp_id)) { + log_warn("failed to read vcp id"); + goto err; + } if (vcp->vcp_id == 0) goto err;