Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Apr 2007 22:13:51 -0400
From:      Kris Kennaway <kris@obsecurity.org>
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:  <20070421021351.GA45020@xor.obsecurity.org>
In-Reply-To: <46296E0F.2070202@FreeBSD.org>
References:  <46296E0F.2070202@FreeBSD.org>

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

--AqsLC8rIMeq19msA
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

Thanks for tracking this down, I have seen (and reported) these
unmountable filesystems myself but had not found a way to reproduce
it.

Kris

> 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
>=20
>=20
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
>=20

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

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

iD8DBQFGKXNeWry0BWjoQKURAv3HAKDGKaUnUBKClBVCJwQRi7k+myIjygCeOcnC
3zRzMUkJj0Nh/RNOJuy5PuM=
=w8no
-----END PGP SIGNATURE-----

--AqsLC8rIMeq19msA--



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