From patchwork Thu Sep 2 19:39:48 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: jvrao X-Patchwork-Id: 63548 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B6D02B718F for ; Fri, 3 Sep 2010 06:56:25 +1000 (EST) Received: from localhost ([127.0.0.1]:60399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OrGM9-0004qH-7W for incoming@patchwork.ozlabs.org; Thu, 02 Sep 2010 16:25:57 -0400 Received: from [140.186.70.92] (port=43785 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OrFTS-0004PJ-TD for qemu-devel@nongnu.org; Thu, 02 Sep 2010 15:29:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OrFTR-0004iz-Js for qemu-devel@nongnu.org; Thu, 02 Sep 2010 15:29:26 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:41278) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OrFTR-0004it-DH for qemu-devel@nongnu.org; Thu, 02 Sep 2010 15:29:25 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o82JKxXX021115 for ; Thu, 2 Sep 2010 13:20:59 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o82JTO0c189196 for ; Thu, 2 Sep 2010 13:29:24 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o82JTN5O022561 for ; Thu, 2 Sep 2010 13:29:24 -0600 Received: from localhost.localdomain (elm9m80.beaverton.ibm.com [9.47.81.80]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o82JSwYH020779; Thu, 2 Sep 2010 13:29:22 -0600 From: "Venkateswararao Jujjuri (JV)" To: qemu-devel@nongnu.org Date: Thu, 2 Sep 2010 12:39:48 -0700 Message-Id: <1283456388-13083-29-git-send-email-jvrao@linux.vnet.ibm.com> X-Mailer: git-send-email 1.6.0.6 In-Reply-To: <1283456388-13083-1-git-send-email-jvrao@linux.vnet.ibm.com> References: <1283456388-13083-1-git-send-email-jvrao@linux.vnet.ibm.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: aliguori@us.ibm.com, Sripathi Kodi , Venkateswararao Jujjuri Subject: [Qemu-devel] [PATCH -V5 28/28] virtio-9p: Change handling of flags in open() path for 9P2000.L X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org From: Sripathi Kodi This patch applies on top of 9P2000.L patches that we have on the list. I took a look at how 9P server is handling open() flags in 9P2000.L path. I think we can do away with the valid_flags() function and simplify the code. The reasoning is as follows: O_NOCTTY: (If the file is a terminal, don't make it the controlling terminal of the process even though the process does not have a controlling terminal) By the time the control reaches 9P client it is clear that what we have is not a terminal device. Hence it does not matter what we do with this flag. In any case 9P server can filter this flag out before making the syscall. O_NONBLOCK: (Don't block if i) Can't read/write to the file ii) Can't get locks) This has an impact on FIFOs, but also on file locks. Hence we can pass it down to the system call. O_ASYNC: From the manpage: O_ASYNC Enable signal-driven I/O: generate a signal (SIGIO by default, but this can be changed via fcntl(2)) when input or output becomes pos- sible on this file descriptor. This feature is only available for terminals, pseudo-terminals, sockets, and (since Linux 2.6) pipes and FIFOs. See fcntl(2) for further details. Again, this does not make any impact on regular files handled by 9P. Also, we don't want 9P server to receive SIGIO. Hence I think 9P server can filter this flag out before making the syscall. O_CLOEXEC: This flag makes sense only on the client. If guest user space sets this flag the guest VFS will take care of calling close() on the fd if an exec() happens. Hence 9P client need not be bothered with this flag. Also I think QEMU will not do an exec, but if it does, it makes sense to close these fds. Hence we can pass this flag down to the syscall. O_CREAT: Since we are in open() path it means we have confirmed that the file exists. Hence there is no need to pass O_CREAT flag down to the system. In fact on some versions of glibc this causes problems, because we pass O_CREAT flag, but don't have permission bits. Hence we can just mask this flag out. So in summary: Mask out: O_NOCTTY O_ASYNC O_CREAT Pass-through: O_NONBLOCK O_CLOEXEC Signed-off-by: Sripathi Kodi Signed-off-by: Venkateswararao Jujjuri --- hw/virtio-9p.c | 14 +------------- 1 files changed, 1 insertions(+), 13 deletions(-) diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c index 4b15ce7..32fa3bc 100644 --- a/hw/virtio-9p.c +++ b/hw/virtio-9p.c @@ -1684,15 +1684,6 @@ out: qemu_free(vs); } -static inline int valid_flags(int flag) -{ - if (flag & O_NOCTTY || flag & O_NONBLOCK || flag & O_ASYNC || - flag & O_CLOEXEC) - return 0; - else - return 1; -} - static void v9fs_open_post_lstat(V9fsState *s, V9fsOpenState *vs, int err) { int flags; @@ -1709,11 +1700,8 @@ static void v9fs_open_post_lstat(V9fsState *s, V9fsOpenState *vs, int err) v9fs_open_post_opendir(s, vs, err); } else { if (s->proto_version == V9FS_PROTO_2000L) { - if (!valid_flags(vs->mode)) { - err = -EINVAL; - goto out; - } flags = vs->mode; + flags &= ~(O_NOCTTY | O_ASYNC | O_CREAT); } else { flags = omode_to_uflags(vs->mode); }