qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "M. Mohan Kumar" <mohan@in.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [V4 PATCH 3/8] Add client side interfaces for chroot environment
Date: Tue, 8 Feb 2011 21:51:07 +0530	[thread overview]
Message-ID: <201102082151.07677.mohan@in.ibm.com> (raw)
In-Reply-To: <AANLkTimtVxbTjrPdQu7aCst70T61Dwr27S11CyquPH7N@mail.gmail.com>

On Wednesday 02 February 2011 3:24:16 pm Stefan Hajnoczi wrote:
> On Tue, Feb 1, 2011 at 5:26 AM, M. Mohan Kumar <mohan@in.ibm.com> wrote:
> > +/* Receive file descriptor and error status from chroot process */
> > +static int v9fs_receivefd(int sockfd, int *error)
> 
> The return value and int *error overlap in functionality.  Would it be
> possible to have only one mechanism for returning errors?
> 

v9fs_receivefd function returns 'fd' on success and returns EIO (and error as 
EIO) if there was a socket error and -1 on other errors.

We need to return -EIO and error as EIO to differentiate between generic EIO 
error and socket failure.
 
> *error = 0 is never done so a caller that passes an uninitialized
> local variable gets back junk when the function succeeds.  It would be
> safer to clear it at the start of this function.
I will update the patch.
> 
> Inconsistent use of errno constants and -1:
> return -EIO;
> return -1; /* == -EPERM, probably not what you wanted */

-1 denotes failure

> 
> How about getting rid of int *error and returning the -errno?  If
> if_error is set then return -fd_info.error.

Do you mean return fd on success and -errno on failure? In this case how to 
differentiate between actual EIO and EIO because of socket read/write failure?

> 
> > +/*
> > + * V9fsFileObjectRequest is written into the socket by QEMU process.
> > + * Then this request is read by chroot process using read_request
> > function + */
> > +static int v9fs_write_request(int sockfd, V9fsFileObjectRequest
> > *request) +{
> > +    int retval, length;
> > +    char *buff, *buffp;
> > +
> > +    length = sizeof(request->data) + request->data.path_len +
> > +                    request->data.oldpath_len;
> > +
> > +    buff = qemu_malloc(length);
> > +    buffp = buff;
> > +    memcpy(buffp, &request->data, sizeof(request->data));
> > +    buffp += sizeof(request->data);
> > +    memcpy(buffp, request->path.path, request->data.path_len);
> > +    buffp += request->data.path_len;
> > +    memcpy(buffp, request->path.old_path, request->data.oldpath_len);
> > +
> > +    retval = qemu_write_full(sockfd, buff, length);
> 
> qemu_free(buff);
> 
> Also, weren't you doing the malloc() + single write() to avoid
> interleaved write()?  Is that still necessary, I thought a mutex was
> introduced?  It's probably worth adding a comment to explain why
> you're doing the malloc + write.

This is used to avoid multiple write system calls. Probably I can update with 
comments. 

----
M. Mohan Kumar

  reply	other threads:[~2011-02-08 16:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-01  5:21 [Qemu-devel] [V4 PATCH 0/8] virtio-9p: Use chroot to safely access files in passthrough security model M. Mohan Kumar
2011-02-01  5:24 ` [Qemu-devel] [V4 PATCH 1/8] virtio-9p: Implement qemu_read_full M. Mohan Kumar
2011-02-01  5:25 ` [Qemu-devel] [V4 PATCH 2/8] Provide chroot environment server side interfaces M. Mohan Kumar
2011-02-01 10:32   ` Daniel P. Berrange
2011-02-01 12:02     ` Stefan Hajnoczi
2011-02-08 12:17     ` M. Mohan Kumar
2011-02-09 10:14       ` Daniel P. Berrange
2011-02-01  5:26 ` [Qemu-devel] [V4 PATCH 3/8] Add client side interfaces for chroot environment M. Mohan Kumar
2011-02-02  9:54   ` [Qemu-devel] " Stefan Hajnoczi
2011-02-08 16:21     ` M. Mohan Kumar [this message]
2011-02-01  5:26 ` [Qemu-devel] [V4 PATCH 4/8] Add support to open a file in " M. Mohan Kumar
2011-02-01  5:27 ` [Qemu-devel] [V4 PATCH 5/8] Create support " M. Mohan Kumar
2011-02-01 14:23   ` [Qemu-devel] " Stefan Hajnoczi
2011-02-01  5:27 ` [Qemu-devel] [V4 PATCH 6/8] Support for creating special files M. Mohan Kumar
2011-02-01 14:29   ` Stefan Hajnoczi
2011-02-01  5:27 ` [Qemu-devel] [V4 PATCH 7/8] Move file post creation changes to none security model M. Mohan Kumar
2011-02-01  5:27 ` [Qemu-devel] [V4 PATCH 8/8] Chroot environment for other functions M. Mohan Kumar

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=201102082151.07677.mohan@in.ibm.com \
    --to=mohan@in.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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).