From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 12:04:26 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D4281065673; Sat, 26 Mar 2011 12:04:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 39C8E8FC1C; Sat, 26 Mar 2011 12:04:25 +0000 (UTC) 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 p2QC4M41090424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2011 14:04:22 +0200 (EET) (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.4/8.14.4) with ESMTP id p2QC4MA8059322; Sat, 26 Mar 2011 14:04:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p2QC4L7v059321; Sat, 26 Mar 2011 14:04:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Mar 2011 14:04:21 +0200 From: Kostik Belousov To: giffunip@tutopia.com Message-ID: <20110326120421.GX78089@deviant.kiev.zoral.com.ua> References: <650638.91967.qm@web113506.mail.gq1.yahoo.com> <86wrjmtiab.fsf@kopusha.home.net> <20110326095810.GW78089@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="90Im4sMSctB4pvMl" Content-Disposition: inline In-Reply-To: <20110326095810.GW78089@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Mikolaj Golub , freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 12:04:26 -0000 --90Im4sMSctB4pvMl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 26, 2011 at 11:58:10AM +0200, Kostik Belousov wrote: > On Sat, Mar 26, 2011 at 10:09:16AM +0200, Mikolaj Golub wrote: > >=20 > > On Fri, 25 Mar 2011 18:01:39 -0700 (PDT) Pedro F. Giffuni wrote: > >=20 > > PFG> --- On Fri, 3/25/11, Kostik Belousov wrote: > >=20 > > PFG> .... > > >> No, I do not want it in our testing framework. I want to > > >> see a standalone test that demonstrates the issue. > > >> I think the leak is real, but want to have a way to > > >> reproduce it before committing. > > >>=20 > > >> The diff you pointed out to t_vnops.c does not make much > > >> sense to me. > >=20 > > PFG> I looked a little more in their records and I found this: > > PFG> _____ > > PFG> ... > > PFG> /* rename directory over an empty directory */ > > PFG> md(pb1, mp, "parent"); > > PFG> md(pb2, mp, "parent/dir1"); > > PFG> md(pb3, mp, "parent/dir2"); > > PFG> RL(rump_sys_mkdir(pb1, 0777)); > > PFG> RL(rump_sys_mkdir(pb2, 0777)); > > PFG> RL(rump_sys_mkdir(pb3, 0777)); > > PFG> RL(rump_sys_rename(pb2, pb3)); > >=20 > > PFG> RL(rump_sys_stat(pb1, &sb)); > > PFG> ATF_CHECK_EQ(sb.st_nlink, 3); > > PFG> RL(rump_sys_rmdir(pb3)); > > PFG> if (FSTYPE_TMPFS(tc)) > > PFG> atf_tc_expect_signal(-1, "PR kern/44288"); > > PFG> ______ > >=20 > > PFG> There's also this that was removed once the PR was fixed: > >=20 > > PFG> - if (FSTYPE_MSDOS(tc)) > > PFG> - atf_tc_skip("test fails in some setups, reason u= nknown"); > >=20 > > PFG> hope that helps. > >=20 > > I suppose doing something like this on msdos fs: > >=20 > > mkdir parent > > mkdir parent/1 > > mv parent/1 parent/2 > > ls -dl parent > >=20 > > In the case of the leak we should see 4 in hard links number field inst= ead of > > expected 3. > No, the supposed leak only affects the vnode usecount, and not the > inode hardlink count. The later is indeed reported as 1 for FreeBSD > implementation of msdosfs, AFAIR. >=20 > Probably, the only way to verify the case is to use debugger. Ok, after rereading the code, I do not believe that we need the change. The doscheckpath() does vput() on tdvp, and tvp is vput'ed right before line 1083, so jumping to the label `bad' instead of `out' will only result in the lock assertion being fired. Also, the msdosfs mount correctly unmounts after the attempt to perform a rename that doscheckpath() banned. This is additional evidence supporting my point. The question is, why did you decided that the fix is needed for FreeBSD ? > >=20 > > But in FreeBSD it looks like msdosfs always reports link count 1: > >=20 > > /dev/md1 on /mnt (msdosfs, local) > >=20 > > [root@lolek ~]# cd /mnt/ > > [root@lolek /mnt]# mkdir parent > > [root@lolek /mnt]# mkdir parent/1 parent/2 parent/3 > > [root@lolek /mnt]# ls -ld parent > > drwxr-xr-x 1 root wheel 4096 Mar 26 11:56 parent > >=20 > > Tested on 8-STABLE and CURRENT. > >=20 > > --=20 > > Mikolaj Golub --90Im4sMSctB4pvMl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2N1kUACgkQC3+MBN1Mb4hnJwCdG+Ou3Zh8pvEEk0gk9GkWWGI1 vGYAnRHc5/KsJpJdQ920DQRM8wovd5/R =e9eS -----END PGP SIGNATURE----- --90Im4sMSctB4pvMl--