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 --]
next prev parent 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).