From owner-freebsd-hackers@FreeBSD.ORG Fri May 8 20:12:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC2E106564A; Fri, 8 May 2009 20:12:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id F3E078FC13; Fri, 8 May 2009 20:12:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1M2WQU-000Kve-8y; Fri, 08 May 2009 23:12:10 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n48KC3Om094384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 May 2009 23:12:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n48KC3oD033392; Fri, 8 May 2009 23:12:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n48KC3dU033391; Fri, 8 May 2009 23:12:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 May 2009 23:12:03 +0300 From: Kostik Belousov To: Tim Kientzle Message-ID: <20090508201203.GJ1948@deviant.kiev.zoral.com.ua> References: <4A03A202.2050101@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/SgVJVxFudH2R+XP" Content-Disposition: inline In-Reply-To: <4A03A202.2050101@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1M2WQU-000Kve-8y ca587a4264363c91efc85cdea80c31f9 X-Terabit: YES Cc: "'freebsd-hackers@freebsd.org'" Subject: Re: fdescfs brokenness X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2009 20:12:13 -0000 --/SgVJVxFudH2R+XP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 07, 2009 at 08:07:46PM -0700, Tim Kientzle wrote: > Colin Percival recently pointed out some issues > with tar and fdescfs. Part of the problem > here is tar; I need to rethink some of the > traversal logic. >=20 > But fdescfs is really wonky: >=20 > * This is a nit, but: ls /dev/fd/18 should not > return EBADF; it should return ENOENT, just > like any other reference to a non-existent filename. > (Just because a filename reflects a file descriptor > does not mean it is a file descriptor.) This is a traditional behaviour for fdescfs. According to man page, open("dev/fd/N") shall be equivalent to fcntl(N, F_DUPFD, 0). Solaris behaviour is the same. >=20 > * The fairly routine recursive directory walker > below gets hung in fdescfs. It appears that > the two opendir() invocations active at the > same time interfere with each other. What you mean by "gets hung" ? In my limited testing, it works. Opendir creates a new directory in /dir/fd by the mere fact of opening the directory. So it walks into that dir, returning to step 1. >=20 > * A similar chdir()-based version of the directory > walker below breaks badly; you can chdir() into > a directory under /dev/fd, but you can't chdir("..") > to get back out of it. (This is the particular > problem that tar is running afoul of.) Not sure about this one. I think that fdescfs vnodes do not support lookup on anything not being root of the fdescfs. >=20 > * Running "find /dev/fd" generates bogus ENOENT errors > because you can opendir() a directory inside of /dev/fd, > and read the entries, but you can't access those entries > because path searches don't work through fdescfs. Again, this may be a consequence of the previous issue. >=20 > I think the right solution here is to add a VOP_ACCESS > handler to fdescfs that bars all access to directory > nodes under /dev/fd. Basically, if your program has a > directory open, that should be reflected as a directory > node that you can't do anything with. The current implementation > allows you to chdir(), opendir(), etc, those directory > nodes, but the machinery to fully support those operations > is missing so they just screw things up. This would chomp the fdescfs functionality, IMHO. Why directory file descriptors should behave differently then any other file descriptor ? I think that the actual solution for the walker problems is to ignore the synthetic filesystems altogether. The information is provided by sysctl vfs.conflist (note that the output is binary), see VFCF_* flags, esp. VFCF_SYNTHETIC. The flag is correctly set at least by procfs, devfs and fdescfs. --/SgVJVxFudH2R+XP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoEkhIACgkQC3+MBN1Mb4ieHACfSdqlU3dWNPycraSH9+63Yy3a W54AoIL1nvTk/mYAQ5b7UVQoMig81SBR =/GP5 -----END PGP SIGNATURE----- --/SgVJVxFudH2R+XP--