From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uakii-00054F-EF for qemu-devel@nongnu.org; Fri, 10 May 2013 06:38:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uakih-0007Yc-8V for qemu-devel@nongnu.org; Fri, 10 May 2013 06:38:36 -0400 Received: from e28smtp01.in.ibm.com ([122.248.162.1]:52720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uakig-0007YL-Gk for qemu-devel@nongnu.org; Fri, 10 May 2013 06:38:35 -0400 Received: from /spool/local by e28smtp01.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 10 May 2013 16:03:02 +0530 From: "Aneesh Kumar K.V" In-Reply-To: <518C96D5.9070009@gmail.com> References: <518AE484.9090204@gmail.com> <87r4hfo6jr.fsf@linux.vnet.ibm.com> <518C96D5.9070009@gmail.com> Date: Fri, 10 May 2013 16:08:24 +0530 Message-ID: <87obcjnmqn.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] 9p: Be robust against paths without FS_IOC_GETVERSION List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gabriel de Perthuis Cc: qemu-devel@nongnu.org, qemu-stable@nongnu.org Gabriel de Perthuis writes: > Le 10/05/2013 05:30, Aneesh Kumar K.V a =C3=A9crit : >> Gabriel de Perthuis writes: >>=20 >>> The current implementation checked for supported filesystems at mount >>> time, but actual support depends on the path. Don't error out when >>> finding unversioned paths. >>=20 >> Can you elaborate this a bit ? > > ioctl support generally depends on the mount point. > > You have a check that verifies the filesystem at the root of the source s= ide > is ext4 or something else whitelisted to have generation support, but tha= t's > not sufficient, the source may contain other mountpoints that don't suppo= rt > the getversion ioctl. When a path gives you ENOTTY, that means the ioctl > is not supported. May be we can update the commit message to be more clear. ie, currently the st_gen support is decided based on whether export file system support ioc_getversion ioctl. But we could have other file system mounted f= urther down in the exported path that doesn't support ioc_getversion. So instead of failing stat request, we do the same we did for the export path. If we find the ioctl not supported we silently ignore the error. This results in = us returning st_gen value 0 which should be ok=20 Reviewed-by: Aneesh Kumar K.V > >>> This fix allows booting a linux kernel with the same / filesystem as the >>> host; otherwise the boot fails when mounting devtmpfs. >>> >>> Signed-off-by: Gabriel de Perthuis >>> --- >>> hw/9pfs/cofile.c | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c >>> index 2efebf3..194c130 100644 >>> --- a/hw/9pfs/cofile.c >>> +++ b/hw/9pfs/cofile.c >>> @@ -36,10 +36,14 @@ int v9fs_co_st_gen(V9fsPDU *pdu, V9fsPath *path, mo= de_t st_mode, >>> err =3D -errno; >>> } >>> }); >>> v9fs_path_unlock(s); >>> } >>> + /* The ioctl may not be supported depending on the path */ >>> + if (err =3D=3D -ENOTTY) { >>> + err =3D 0; >>> + } >>=20 >> So you don't want to consider -ENOTTY as an error ? why ? > > ENOTTY means the ioctl is not supported. > That should be handled the same as if the source-side root didn't have a > whitelisted filesystem. That means we need to return 0 in both cases. > >>> return err; >>> } >>> >>> int v9fs_co_lstat(V9fsPDU *pdu, V9fsPath *path, struct stat *stbuf) >>> { >>> --=20 >>=20 >> -aneesh