On Fri, Oct 27, 2017 at 01:59:22PM +0100, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berra...@redhat.com) wrote: > > When QEMU sets up a tap based network device backend, it mostly ignores > > errors > > reported from various ioctl() calls it makes, assuming the TAP file > > descriptor > > is valid. This assumption can easily be violated when the user is passing > > in a > > pre-opened file descriptor. At best, the ioctls may fail with a -EBADF, but > > if > > the user passes in a bogus FD number that happens to clash with a FD number > > that > > QEMU has opened internally for another reason, a wide variety of errnos may > > result, as the TUNGETIFF ioctl number may map to a completely different > > command > > on a different type of file. > > > > By ignoring all these errors, QEMU sets up a zombie network backend that > > will > > never pass any data. Even worse, when QEMU shuts down, or that network > > backend > > is hot-removed, it will close this bogus file descriptor, which could > > belong to > > another QEMU device backend. > > > > There's no obvious guaranteed reliable way to detect that a FD genuinely is > > a > > TAP device, as opposed to a UNIX socket, or pipe, or something else. > > Checking > > the errno from probing vnet hdr flag though, does catch the big common > > cases. > > ie calling TUNGETIFF will return EBADF for an invalid FD, and ENOTTY when > > FD is > > a UNIX socket, or pipe which catches accidental collisions with FDs used for > > stdio, or monitor socket. > > > > Previously the example below where bogus fd 9 collides with the FD used for > > the > > chardev saw: > > > > $ ./x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hostnet0,fd=9 \ > > -chardev socket,id=charchannel0,path=/tmp/qga,server,nowait \ > > -monitor stdio -vnc :0 > > qemu-system-x86_64: -netdev tap,id=hostnet0,fd=9: TUNGETIFF ioctl() failed: > > Inappropriate ioctl for device > > TUNSETOFFLOAD ioctl() failed: Bad address > > QEMU 2.9.1 monitor - type 'help' for more information > > (qemu) Warning: netdev hostnet0 has no peer > > > > which gives a running QEMU with a zombie network backend. > > > > With this change applied we get an error message and QEMU immediately exits > > before carrying on and making a bigger disaster: > > Right, that does make a better error so; > > Tested-by: Dr. David Alan Gilbert <dgilb...@redhat.com> > > Is there anyway we could get that error before the -chardev goes and > allocates the fd 9?
That is unfortunately determined by the order in which the QEMU command line args are parsed, and chardevs are procssed before netdevs. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
