The following reply was made to PR kern/39307; it has been noted by GNATS.
From: Quentin Garnier <cube@xxxxxxxxxxx>
Subject: Re: kern/39307 (mfs will sometimes panic at umount time)
Date: Wed, 24 Sep 2008 16:00:21 +0200
Content-Type: text/plain; charset=us-ascii
On Wed, Sep 24, 2008 at 09:46:20AM +0000, ad@xxxxxxxxxx wrote:
> Synopsis: mfs will sometimes panic at umount time
> State-Changed-From-To: open->feedback
> State-Changed-By: ad@xxxxxxxxxx
> State-Changed-When: Wed, 24 Sep 2008 09:46:18 +0000
> Should be fixed - please verify.
It made the failure different this morning. However, it was a quick
test so I might have left a few asserts of my own in that kernel. I'll
have more time to test tonight.
Looking at your changes, however, I don't see how they could prevent the
panic. What I think is happening is a race between umount(2) and
The former will do its job and the necessary references are released.
That will signal mfs_mount(8) somehow, which is still in VFS_START at
that point. It will go ahead with doumount() which will do the final
call to vfs_destroy(), which in turns destroys the struct mount.
When mfs_start() returns to VFS_START, the pointer to the struct mount
is dereferenced and that's where it crashes.
It works when mfs_mount(8) gets signaled and to run before umount(2) is
finshed, so that the end of VFS_START can dereference the struct mount.
Quentin Garnier - cube@xxxxxxxxxxx - cube@xxxxxxxxxx
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)
-----END PGP SIGNATURE-----