From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=50843 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pv96E-0000gx-8J
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 09:01:57 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mohan@in.ibm.com>) id 1Pv964-0005VC-IU
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 09:01:45 -0500
Received: from e23smtp01.au.ibm.com ([202.81.31.143]:57711)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mohan@in.ibm.com>) id 1Pv964-0005Ug-2J
	for qemu-devel@nongnu.org; Thu, 03 Mar 2011 09:01:40 -0500
Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247])
	by e23smtp01.au.ibm.com (8.14.4/8.13.1) with ESMTP id p23Dvfen017731
	for <qemu-devel@nongnu.org>; Fri, 4 Mar 2011 00:57:41 +1100
Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139])
	by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id
	p23E1Nfl2429106
	for <qemu-devel@nongnu.org>; Fri, 4 Mar 2011 01:01:26 +1100
Received: from d23av04.au.ibm.com (loopback [127.0.0.1])
	by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id
	p23E1Np5030120
	for <qemu-devel@nongnu.org>; Fri, 4 Mar 2011 01:01:23 +1100
From: "M. Mohan Kumar" <mohan@in.ibm.com>
Date: Thu, 3 Mar 2011 19:31:21 +0530
References: <1298892156-11667-1-git-send-email-mohan@in.ibm.com>
	<1298892156-11667-5-git-send-email-mohan@in.ibm.com>
	<AANLkTinTeGdxkHcZMaUSJ6m4Nrc3oO5aeXsXKOqToD++@mail.gmail.com>
In-Reply-To: <AANLkTinTeGdxkHcZMaUSJ6m4Nrc3oO5aeXsXKOqToD++@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201103031931.21534.mohan@in.ibm.com>
Subject: [Qemu-devel] Re: [V6 PATCH 4/9] virtio-9p: Add qemu side interfaces
	for chroot environment
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: qemu-devel@nongnu.org

On Thursday 03 March 2011 5:08:10 pm Stefan Hajnoczi wrote:
> On Mon, Feb 28, 2011 at 11:22 AM, M. Mohan Kumar <mohan@in.ibm.com> wrote:
> > +    retval = recvmsg(sockfd, &msg, 0);
> > +    if (retval < 0) {
> > +        *sock_error = 1;
> > +        return -EIO;
> > +    }
> 
> Are we guaranteed this will be called with signals blocked?  Otherwise
> we need to handle EINTR.

Ok

> 
> > +    if (fd_info.fi_flags & FI_FD_SOCKERR) {
> > +        *sock_error = 1;
> > +        return -EIO;
> > +    }
> > +    /* If fd is invalid, ancillary data is not present */
> > +    if (fd_info.fi_fd < 0 || fd_info.fi_flags & FI_FD_INVALID) {
> > +        return fd_info.fi_fd;
> > +    }
> 
> Testing fd_info.fi_flags & FI_FD_INVALID looks dangerous to me.  If
> for some reason fi_fd >= 0 then we'd return success here.  fd_fd < 0
> should be a sufficient check, perhaps you wanted an assert() instead?

This check is required because,

Creating special objects like directory, device nodes will not have a valid 
fd, usually fd will be 0 on success and -ve on error. During success cases, we 
can't do sendmsg for fd=0 value with SCM_RIGHTS, that would result in problem. 
In this case, we set fd_info.fi_flags to FI_FD_INVALID indicating fd is not a 
valid one, but its not an error case also.
 
----
M. Mohan Kumar