Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Apr 2007 16:31:31 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Maxim Sobolev <sobomax@freebsd.org>
Cc:        freebsd-fs@freebsd.org, "current@freebsd.org" <current@freebsd.org>
Subject:   Re: Bug in the unmounting code
Message-ID:  <20070423133131.GA32370@deviant.kiev.zoral.com.ua>
In-Reply-To: <46296E0F.2070202@FreeBSD.org>
References:  <46296E0F.2070202@FreeBSD.org>

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

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

On Fri, Apr 20, 2007 at 06:51:11PM -0700, Maxim Sobolev wrote:
> Hi,
>=20
> I have noticed that there is a bug in unmounting code which could make
> filesystem unmountable when its parent filesystem has been forcefully
> unmounted. Following is quick way to reproduce the problem:
>=20
> [sobomax@pioneer ~]$ sudo mkdir -p /tmp/1/2
> [sobomax@pioneer ~]$ sudo mkdir /tmp/3
> [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3
> [sobomax@pioneer ~]$ sudo mount_nullfs /tmp/1 /tmp/3/2
> [sobomax@pioneer ~]$ sudo umount -f /tmp/3
> [sobomax@pioneer ~]$ sudo mount -v
> /tmp/1 on /tmp/3/2 (nullfs, local, fsid 03ff000202000000)
> [sobomax@pioneer ~]$ sudo umount 03ff000202000000
> umount: unmount of /tmp/3/2 failed: No such file or directory
> umount: retrying using path instead of file system ID
> umount: unmount of /tmp/3/2 failed: No such file or directory
>=20
> Investigation has revealed that in this case vn_lock() call fails with
> ENOENT due to the following piece of code:
>=20
> vn_lock()
> [...]
>                 if (error =3D=3D 0 && vp->v_iflag & VI_DOOMED &&
>                     (flags & LK_RETRY) =3D=3D 0) {
>                         VOP_UNLOCK(vp, 0, td);
>                         error =3D ENOENT;
>                         break;
>                 }
> [...]
>=20
> Addition of LK_RETRY flag fixed the problem, but my knowledge of VFS is
> quite limited so that I would appreciate if somebody could verify that
> the fix below won't have any undesirable effects.
>=20
> -Maxim
>=20
> --- vfs_mount.c 2007/04/21 01:40:53     1.1
> +++ vfs_mount.c 2007/04/21 01:41:09
> @@ -1155,7 +1155,7 @@
>                 mnt_gen_r =3D mp->mnt_gen;
>                 VI_LOCK(coveredvp);
>                 vholdl(coveredvp);
> -               error =3D vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK,=
 td);
> +               error =3D vn_lock(coveredvp, LK_EXCLUSIVE | LK_INTERLOCK |
> LK_RETRY, td);
>                 vdrop(coveredvp);
>                 /*
>                  * Check for mp being unmounted while waiting for the

Thank you for tracking this. The regression was introduced by me in rev. 1.=
232.
There is no need to check for error after vn_lock(LK_RETRY).

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

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

iD8DBQFGLLUyC3+MBN1Mb4gRAigiAJ4ovfbYuVXBz7wvEbaSxukjE+NT8wCeIqsn
51dI3qp7BJEh29npBaD9ih0=
=825B
-----END PGP SIGNATURE-----

--ew6BAiZeqk4r7MaW--



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