qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] 9pfs segfaults on chmod(special)


From: M. Mohan Kumar
Subject: Re: [Qemu-devel] 9pfs segfaults on chmod(special)
Date: Thu, 28 Feb 2013 17:54:49 +0530
User-agent: Notmuch/0.13.2 (http://notmuchmail.org) Emacs/24.1.1 (x86_64-redhat-linux-gnu)

Michael Tokarev <address@hidden> writes:

> 28.02.2013 13:12, Aneesh Kumar K.V wrote:
>> Michael Tokarev <address@hidden> 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 <address@hidden>
>
> Thank you!
>
> /mjt




reply via email to

[Prev in Thread] Current Thread [Next in Thread]