28.02.2013 13:12, Aneesh Kumar K.V wrote: > Michael Tokarev <m...@tls.msk.ru> writes: > >> When guest tries to chmod a block or char device file over 9pfs, >> the qemu process segfaults. >> >> On host: >> qemu-system-x86_64 -virtfs >> local,path=/dev,security_model=mapped-file,mount_tag=tag >> >> On guest: >> mount -t 9p -o trans=virtio tag /mnt >> chmod 0777 /mnt/tty > > any specific reason why you are trying 9p .u ?
Sorry? What _is_ "9p .u" ? :) [] >> Maybe the buffer (extension->data) should be passed to it instead of >> the whole structure (extension)? Or the check be extended (or, >> since this function isn't called from any other place, _replaced_) to >> test for non-NULL ->data too? >> > > Thanks for the detailed analysis. Something like below ? > > diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c > index f526467..073067f 100644 > --- a/hw/9pfs/virtio-9p.c > +++ b/hw/9pfs/virtio-9p.c > @@ -659,7 +659,7 @@ static mode_t v9mode_to_mode(uint32_t mode, V9fsString > *extension) > ret |= S_IFIFO; > } > if (mode & P9_STAT_MODE_DEVICE) { > - if (extension && extension->data[0] == 'c') { > + if (extension->size && extension->data[0] == 'c') { > ret |= S_IFCHR; > } else { > ret |= S_IFBLK; > Yeah, that looks much saner. And it obviously works, just like testing ext->data to be non-null. It has been this way since about beginning (as in, for example, 1.1 version of qemu is also affected), and probably is a good candidate for -stable too. Reviewed-By: Michael Tokarev <m...@tls.msk.ru> Thank you! /mjt