Thanks Anton. I confirm that applying this on top of the most recent tree fixed the problem for me.
I wonder if a regression test of some sort is in order. The peanut gallery also observes that config_getvm is could use some light refactoring into smaller units. On Wed, Oct 24, 2018 at 8:51 AM Anton Lindqvist <an...@openbsd.org> wrote: > On Mon, Oct 22, 2018 at 11:05:13AM -0700, Greg Steuck wrote: > > Hi Reyk & Anton, > > > > I upgraded the syzkaller machine from Oct 11 to Oct 21 snapshot and > started > > seeing: > > Oct 22 10:00:21 ci-openbsd vmd[15707]: qc2_open: missing base image > > /syzkaller/managers/main/current/image > > Oct 22 10:00:21 ci-openbsd vmd[15707]: > > /syzkaller/managers/main/current/image: could not open qc2_open: No such > > file or directory > > Oct 22 10:00:21 ci-openbsd vmd[13268]: qc2_open: missing base image > > /syzkaller/managers/main/current/image > > Oct 22 10:00:21 ci-openbsd vmd[13268]: > > /syzkaller/managers/main/current/image: could not open qc2_open: No such > > file or directory > > Oct 22 10:00:21 ci-openbsd vmd[51186]: qc2_open: missing base image > > /syzkaller/managers/main/current/image > > Oct 22 10:00:21 ci-openbsd vmd[51186]: > > /syzkaller/managers/main/current/image: could not open qc2_open: No such > > file or directory > > > > Reverting the change in subject and rebuilding vmd&vmctl stops the > problem. > > > > The file in question exists: > > ci-openbsd$ file /syzkaller/managers/main/current/image > > /syzkaller/managers/main/current/image: QEMU QCOW Image (v3), 1073741824 > > bytes > > ci-openbsd$ ls -l /syzkaller/managers/main/current/image > > -rw-r----- 2 syzkaller syzkaller 545783808 Oct 22 10:34 > > /syzkaller/managers/main/current/image > > > > Under the hood this command line is executed: > > vmctl start ci-openbsd-main-0 -b /syzkaller/managers/main/current/kernel > -d > > /syzkaller/managers/main/workdir/instance-0/disk.qcow2 -m 512M -L -c -t > > syzkaller > > > > Anton, what does your code is syzkaller do to create this file? > > -rw------- 1 syzkaller syzkaller 262144 Oct 22 10:59 > > /syzkaller/managers/main/workdir/instance-0/disk.qcow2 > > > > > > The file does reference the base image: > > ci-openbsd$ strings > /syzkaller/managers/main/workdir/instance-0/disk.qcow2 > > > > h/syzkaller/managers/main/current/image > > > > Thanks > > Greg > > -- > > nest.cx is Gmail hosted, use PGP for anything private. Key: > > http://goo.gl/6dMsr > > Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0 > > I'm also not able to start a VM using a derived disk after this commit. > It looks to me like the code is trying to resolve the base disk for the > derived disk over and over instead of walking down the chain of derived > disks. This causes file descriptors to be opened only for the derived > disk whereas the base disk is expected. With the diff below, I'm able to > boot using a derived disk again. > > Index: config.c > =================================================================== > RCS file: /cvs/src/usr.sbin/vmd/config.c,v > retrieving revision 1.53 > diff -u -p -r1.53 config.c > --- config.c 19 Oct 2018 10:12:39 -0000 1.53 > +++ config.c 24 Oct 2018 15:48:00 -0000 > @@ -364,6 +364,10 @@ config_setvm(struct privsep *ps, struct > base, vcp->vcp_disks[i]); > goto fail; > } > + if (strlcpy(path, base, sizeof(path)) >= > sizeof(path)) { > + log_warnx("%s, base path too long", > __func__); > + goto fail; > + } > } > } > > -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://goo.gl/6dMsr Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
