From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN5JQ-0008Ah-KB for qemu-devel@nongnu.org; Thu, 19 May 2011 11:38:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN5JP-0003FY-Eh for qemu-devel@nongnu.org; Thu, 19 May 2011 11:38:56 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:47112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN5JP-0003FR-9Q for qemu-devel@nongnu.org; Thu, 19 May 2011 11:38:55 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4JFUkjM013558 for ; Thu, 19 May 2011 09:30:46 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p4JFcGD3123346 for ; Thu, 19 May 2011 09:38:49 -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 p4J9SHcP010609 for ; Thu, 19 May 2011 03:28:17 -0600 Received: from oc6675851006.ibm.com (sig-9-48-58-108.mts.ibm.com [9.48.58.108]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4J9SE4E010427 for ; Thu, 19 May 2011 03:28:15 -0600 Message-ID: <4DD53729.5000104@linux.vnet.ibm.com> Date: Thu, 19 May 2011 08:28:41 -0700 From: Venkateswararao Jujjuri MIME-Version: 1.0 References: <1305661431-21289-1-git-send-email-jvrao@linux.vnet.ibm.com> <1305661431-21289-7-git-send-email-jvrao@linux.vnet.ibm.com> <4DD41301.5060804@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [V2 06/25] [virtio-9p] coroutines for readlink List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 05/18/2011 10:37 PM, Stefan Hajnoczi wrote: > On Wed, May 18, 2011 at 7:42 PM, Venkateswararao Jujjuri > wrote: >> On 05/18/2011 02:43 AM, Stefan Hajnoczi wrote: >>> On Tue, May 17, 2011 at 8:43 PM, Venkateswararao Jujjuri (JV) >>> wrote: >>>> Signed-off-by: Venkateswararao Jujjuri " >>>> --- >>>> Makefile.objs | 2 +- >>>> hw/9pfs/cofs.c | 42 >>>> ++++++++++++++++++++++++++++++++++++++++++ >>>> hw/9pfs/virtio-9p-coth.h | 1 + >>>> hw/9pfs/virtio-9p.c | 27 ++++----------------------- >>>> hw/9pfs/virtio-9p.h | 3 ++- >>>> 5 files changed, 50 insertions(+), 25 deletions(-) >>>> create mode 100644 hw/9pfs/cofs.c >>>> >>>> diff --git a/Makefile.objs b/Makefile.objs >>>> index 96f6a24..36005bb 100644 >>>> --- a/Makefile.objs >>>> +++ b/Makefile.objs >>>> @@ -297,7 +297,7 @@ hw-obj-$(CONFIG_SOUND) += $(sound-obj-y) >>>> 9pfs-nested-$(CONFIG_VIRTFS) = virtio-9p.o virtio-9p-debug.o >>>> 9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-local.o virtio-9p-xattr.o >>>> 9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-xattr-user.o >>>> virtio-9p-posix-acl.o >>>> -9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-coth.o >>>> +9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-coth.o cofs.o >>>> >>>> hw-obj-$(CONFIG_REALLY_VIRTFS) += $(addprefix 9pfs/, $(9pfs-nested-y)) >>>> $(addprefix 9pfs/, $(9pfs-nested-y)): QEMU_CFLAGS+=$(GLIB_CFLAGS) >>>> diff --git a/hw/9pfs/cofs.c b/hw/9pfs/cofs.c >>>> new file mode 100644 >>>> index 0000000..6d94673 >>>> --- /dev/null >>>> +++ b/hw/9pfs/cofs.c >>>> @@ -0,0 +1,42 @@ >>>> + >>>> +/* >>>> + * Virtio 9p backend >>>> + * >>>> + * Copyright IBM, Corp. 2011 >>>> + * >>>> + * Authors: >>>> + * Aneesh Kumar K.V >>>> + * >>>> + * This work is licensed under the terms of the GNU GPL, version 2. See >>>> + * the COPYING file in the top-level directory. >>>> + * >>>> + */ >>>> + >>>> +#include "fsdev/qemu-fsdev.h" >>>> +#include "qemu-thread.h" >>>> +#include "qemu-coroutine.h" >>>> +#include "virtio-9p-coth.h" >>>> + >>>> +int v9fs_co_readlink(V9fsState *s, V9fsString *path, V9fsString *buf) >>>> +{ >>>> + int err; >>>> + ssize_t len; >>>> + V9fsString tbuf; >>>> + >>>> + tbuf.data = qemu_malloc(PATH_MAX); >>> Why introduce tbuf when the buf is available? You end up having to >>> copy back fields at the end of the function and load from an >>> uninitialized address (tbuf.size) in the error case. >> tbuf is introduced for re-entrent purpose. >> We should be calling v9fs_string_init() on this though. > I see no issue here and no safety added by using a local variable. > Can you explain what you're trying to do? No issues in the current usage. Just looking at the micro level of this routine, we have an passd-in buffer passed under lock and is getting updated outside the lock (worker thread). Can take it out, not an issue. - JV > Stefan >