Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Mar 2011 11:58:10 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Mikolaj Golub <trociny@freebsd.org>
Cc:        freebsd-fs@freebsd.org, giffunip@tutopia.com
Subject:   Re: kern/152079: [msdosfs] [patch] Small cleanups from the other NetBSD/OpenBSD
Message-ID:  <20110326095810.GW78089@deviant.kiev.zoral.com.ua>
In-Reply-To: <86wrjmtiab.fsf@kopusha.home.net>
References:  <650638.91967.qm@web113506.mail.gq1.yahoo.com> <86wrjmtiab.fsf@kopusha.home.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--WcefIMV7bKFlmpJx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 unk=
nown");
>=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 instea=
d 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.

Probably, the only way to verify the case is to use debugger.
>=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

--WcefIMV7bKFlmpJx
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk2NuLEACgkQC3+MBN1Mb4jQ1gCgwMdaYagMcmerEE6MP9ZA708r
mTEAn1hBH8cevyMd7b3XZIULuIf0Yrk4
=m15b
-----END PGP SIGNATURE-----

--WcefIMV7bKFlmpJx--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110326095810.GW78089>