qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] Fix bug with virtio-9p fsync
Date: Tue, 26 Apr 2011 14:12:45 -0700	[thread overview]
Message-ID: <4DB7354D.4040005@linux.vnet.ibm.com> (raw)
In-Reply-To: <1303836715-4401-1-git-send-email-sassan@sassan.me.uk>

[-- Attachment #1: Type: text/plain, Size: 4554 bytes --]

On 04/26/2011 09:51 AM, Sassan Panahinejad wrote:
> v9fs_fsync and possibly others break when asked to operate on a directory.
> It does not check fid_type to see if it is operating on a directory and therefore accesses the wrong element of the fs union.
> This error can result in guest applications failing (in my case it was dpkg).
> This patch fixes the issue, although there may be other, similar bugs in virtio-9p.
>
> Signed-off-by: Sassan Panahinejad<sassan@sassan.me.uk>
> ---
>
> Here I've implemented it as a function. If you'd prefer a macro or inline function then let me know.
>
> Thanks
> Sassan

Please put your commentary on the top. After "---" you should only 
expect code diff.
>   hw/virtio-9p.c |   43 +++++++++++++++++++++++++++++++++++++------
>   1 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c
> index 7e29535..26be0fc 100644
> --- a/hw/virtio-9p.c
> +++ b/hw/virtio-9p.c
> @@ -1860,6 +1860,18 @@ static void v9fs_post_do_fsync(V9fsState *s, V9fsPDU *pdu, int err)
>       complete_pdu(s, pdu, err);
>   }
>
> +static int v9fs_get_fd(V9fsFidState *fidp)
> +{
> +    switch (fidp->fid_type) {
> +        case P9_FID_FILE:
> +            return fidp->fs.fd;
> +        case P9_FID_DIR:
> +            return dirfd(fidp->fs.dir);
> +        default:
> +            return -1;
> +    }
> +}
> +
>   static void v9fs_fsync(V9fsState *s, V9fsPDU *pdu)
>   {
>       int32_t fid;
> @@ -1867,6 +1879,7 @@ static void v9fs_fsync(V9fsState *s, V9fsPDU *pdu)
>       V9fsFidState *fidp;
>       int datasync;
>       int err;
> +    int fd;
>
>       pdu_unmarshal(pdu, offset, "dd",&fid,&datasync);
>       fidp = lookup_fid(s, fid);
> @@ -1875,7 +1888,11 @@ static void v9fs_fsync(V9fsState *s, V9fsPDU *pdu)
>           v9fs_post_do_fsync(s, pdu, err);
>           return;
>       }
> -    err = v9fs_do_fsync(s, fidp->fs.fd, datasync);
> +    if ((fd = v9fs_get_fd(fidp))>= 0) {
> +        err = v9fs_do_fsync(s, fd, datasync);
> +    } else {
> +	err = -EINVAL;
> +    }
>       v9fs_post_do_fsync(s, pdu, err);
>   }
>
> @@ -2984,6 +3001,7 @@ static void v9fs_wstat(V9fsState *s, V9fsPDU *pdu)
>       int32_t fid;
>       V9fsWstatState *vs;
>       int err = 0;
> +    int fd;
>
>       vs = qemu_malloc(sizeof(*vs));
>       vs->pdu = pdu;
> @@ -2999,7 +3017,10 @@ static void v9fs_wstat(V9fsState *s, V9fsPDU *pdu)
>
>       /* do we need to sync the file? */
>       if (donttouch_stat(&vs->v9stat)) {
> -        err = v9fs_do_fsync(s, vs->fidp->fs.fd, 0);
> +        if ((fd = v9fs_get_fd(vs->fidp))>= 0) {
> +            err = v9fs_do_fsync(s, fd, 0);
> +        } else
> +            err = -EINVAL;
>           v9fs_wstat_post_fsync(s, vs, err);
>           return;
>       }
> @@ -3176,6 +3197,7 @@ static void v9fs_lock(V9fsState *s, V9fsPDU *pdu)
>   {
>       int32_t fid, err = 0;
>       V9fsLockState *vs;
> +    int fd;
>
>       vs = qemu_mallocz(sizeof(*vs));
>       vs->pdu = pdu;
> @@ -3198,8 +3220,12 @@ static void v9fs_lock(V9fsState *s, V9fsPDU *pdu)
>           err = -ENOENT;
>           goto out;
>       }
> -
> -    err = v9fs_do_fstat(s, vs->fidp->fs.fd,&vs->stbuf);
> +    if ((fd = v9fs_get_fd(vs->fidp))>= 0) {
> +        err = v9fs_do_fstat(s, fd,&vs->stbuf);
> +    } else {
> +        err = -EINVAL;
> +        goto out;
> +    }

I think we need a different handle for lock and getlock.
If the operation is on a dir we need to return

EISDIR

    The /cmd/ parameter is F_GETLK, F_GETLK64, F_SETLK, F_SETLK64,
    F_SETLKW, or F_SETLKW64, and /fildes/ refers to a directory.

Since the handling is different, I am not sure if the separate function 
makes any sense now.
    May be go back to your initial check for sync and for locks, if the
    fid is a dir type then EISDIR
otherwise EINVAL.

Thanks,
JV



>       if (err<  0) {
>           err = -errno;
>           goto out;
> @@ -3221,6 +3247,7 @@ static void v9fs_getlock(V9fsState *s, V9fsPDU *pdu)
>   {
>       int32_t fid, err = 0;
>       V9fsGetlockState *vs;
> +    int fd;
>
>       vs = qemu_mallocz(sizeof(*vs));
>       vs->pdu = pdu;
> @@ -3236,8 +3263,12 @@ static void v9fs_getlock(V9fsState *s, V9fsPDU *pdu)
>           err = -ENOENT;
>           goto out;
>       }
> -
> -    err = v9fs_do_fstat(s, vs->fidp->fs.fd,&vs->stbuf);
> +    if ((fd = v9fs_get_fd(vs->fidp))>= 0) {
> +        err = v9fs_do_fstat(s, fd,&vs->stbuf);
> +    } else {
> +        err = -EINVAL;
> +        goto out;
> +    }
>       if (err<  0) {
>           err = -errno;
>           goto out;


[-- Attachment #2: Type: text/html, Size: 5588 bytes --]

  reply	other threads:[~2011-04-26 21:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-25 17:54 [Qemu-devel] [PATCH] Fix bug with virtio-9p fsync Sassan Panahinejad
2011-04-26  9:18 ` Stefan Hajnoczi
2011-04-26 12:14   ` Sassan Panahinejad
2011-04-26 12:58     ` Stefan Hajnoczi
2011-04-26 13:29       ` Sassan Panahinejad
2011-04-26 14:25         ` Venkateswararao Jujjuri
2011-04-26 16:51         ` Sassan Panahinejad
2011-04-26 21:12           ` Venkateswararao Jujjuri [this message]
2011-04-27 11:41             ` Sassan Panahinejad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DB7354D.4040005@linux.vnet.ibm.com \
    --to=jvrao@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).