All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.