On 10/10/2012 04:31 PM, Eric Blake wrote:
Another missing validation check is for duplicate use. With the monitor command, you ALWAYS have a unique fd (thanks to SCM_RIGHTS). But with the command line, I can type 'qemu -add-fd fd=4,set=1 -add-fd fd=4,set=2'. Oops - I've now corrupted your set layout, unless you validate that every fd requested in -add-fd does not already reside in any existing set.
Thinking aloud: On the other hand, being able to pass in one fd to multiple sets MIGHT be useful; in the SCM_RIGHTS monitor command case, I can pass the same fd from the management perspective into multiple sets, even though in qemu's perspective, there will be multiple fds created (one per call). Perhaps instead of directly adding the inherited fd to a set, and having to then sweep all sets to check for duplicates, it might make sense to add dup(fd) to a set, so that if I call:
qemu -add-fd fd=4,set=1 -add-fd fd=4,set=2 -add-fd fd=5,set=2
what REALLY happens is that qemu adds dup(4)==6 to set 1, dup(4)==7 to set 2, and dup(5)==8 to set 3. Then, after all ALL -add-fd have been processed, qemu then does another pass through them calling close(4) and close(5) (to avoid holding the original fds open indefinitely if the corresponding sets are discarded).
Another idea: a hybrid approach - the _first_ -add-fd 4 directly adds 4 to the set, all other -add-fd 4 end up adding dup(4) instead (well, fcntl(F_DUPFD_CLOEXEC), but you get the picture). That is, do the duplicate scanning, and if there is no duplicate, use the fd directly; if there IS a duplicate, then put a unique fd number as a copy into the remaining sets. That way, you don't have to do a final close() sweep across the -add-fd arguments passed on the command line, and you still don't have to worry about duplicated fds across multiple sets causing mayhem in qemu_close(). -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org