Date: Sat, 26 Mar 2011 14:04:21 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: giffunip@tutopia.com Cc: Mikolaj Golub <trociny@freebsd.org>, freebsd-fs@freebsd.org Subject: Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD Message-ID: <20110326120421.GX78089@deviant.kiev.zoral.com.ua> In-Reply-To: <20110326095810.GW78089@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kostikbel@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110326120421.GX78089>