Michael Tokarev <m...@tls.msk.ru> writes: > 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" ? :) > Hi,
9p.u is the extension of 9p protocol developed during Linux porting of 9p. Original 9p was designed for Plan 9 operating system. 9p.u has support for numerical uids, gids, additional mode and permissio bits. But still 9p.u lacked support for full Linux VFS operations. Such as xattrs, locking etc. In order to overcome these issues and address functionalities provides by Linux VFS a new protocol 9p2000.L was developed (http://code.google.com/p/diod/wiki/protocol) By default 9p.u is used, you can override by that mount -t 9p -otrans=virtio,version=9p2000.L tag /mnt > > [] >>> 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
