From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVOA9-0004Sv-1R for qemu-devel@nongnu.org; Tue, 10 Mar 2015 13:41:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVOA4-0003o6-JZ for qemu-devel@nongnu.org; Tue, 10 Mar 2015 13:41:48 -0400 Received: from e28smtp08.in.ibm.com ([122.248.162.8]:48730) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVOA3-0003md-UN for qemu-devel@nongnu.org; Tue, 10 Mar 2015 13:41:44 -0400 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Mar 2015 23:11:40 +0530 Received: from d28relay04.in.ibm.com (d28relay04.in.ibm.com [9.184.220.61]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 467193940048 for ; Tue, 10 Mar 2015 23:11:39 +0530 (IST) Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay04.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t2AHfchX64422058 for ; Tue, 10 Mar 2015 23:11:38 +0530 Received: from d28av01.in.ibm.com (localhost [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t2AHfcES002804 for ; Tue, 10 Mar 2015 23:11:38 +0530 From: "Aneesh Kumar K.V" In-Reply-To: <54FE71C2.2080609@msgid.tls.msk.ru> References: <54FB6199.6030306@redhat.com> <54FB775D.6080608@msgid.tls.msk.ru> <877fur4fq8.fsf@linux.vnet.ibm.com> <54FE71C2.2080609@msgid.tls.msk.ru> Date: Tue, 10 Mar 2015 23:11:37 +0530 Message-ID: <87egowrbqm.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 1/3] 9pfs-proxy: simplify error handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: qemu-devel@nongnu.org Michael Tokarev writes: > 08.03.2015 19:27, Aneesh Kumar K.V wrote: >> Michael Tokarev writes: > [] >>> Actually, after reading almost whole 9pfs and fsdev code, I can >>> say with great confidence this code is nearly hopeless. >> >> Is that about the 9pfs-proxy code, or the rest of 9pfs. I understand > > Well. the marshal/unmarshal interface is in core code as far as > I can see, and it is very fragile at best, as the below example of > its usage shows. I haven't dug deeper. So far, it was only the > 9pfs proxy code. May be i am missing something here. Can you help me understand the issue. > static int v9fs_receive_status(V9fsProxy *proxy, > struct iovec *reply, int *status) > ... > proxy_unmarshal(reply, 0, "dd", &header.type, &header.size); > if (header.size != sizeof(int)) { > *status = -ENOBUFS; > } > ... > proxy_unmarshal(reply, PROXY_HDR_SZ, "d", status); > > proxy_unmarshall(), for "d" element, expects an int32_t > pointer. Here we have int pointer, and compare its > size with sizeof(int). This is a generic problem of whole > v9fs_(un)marshall interface, which is in the core of 9pfs... > this is a status return, which is int32. Proxy helper do write sizeof(int) as a part of header response. So it read the header.size and check whether it is same as what it is expecting. If not it error out. So i am not sure what the issue you are listing here. -aneesh