Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

possible fix for PR 39307 (mfs sometimes crashing on unmount)



Hi,

I have been puzzling over the symptoms of PR # 39307 for a while, mfs
sometimes causes a panic in VFS_START.  Looking at it, mfs is a
strange beast.  The start routine (mfs_start) does not exit until the
mount is going away and then mfs_start() actually calls dounmount()
directly to unmount itself - once this is done, the race is on, can
mfs_start() exit and VFS_START() do it's final bit before the memory
that was the struct mount * is reused.  Hence the crash.

I was able to easily reproduce this panic every time using qemu.  I
have found what I think is a fix but I am not sure it is *correct*.
The panic is due to the mnt_refcnt being wrong, there are too few
references to the mount structure, when mfs_start() calls dounmount()
there are two vfs_destroy() calls near the end of dounmount() - the
comments say one is to clear the caller's reference and the other is
for mount().  Well, mfs_start() does not increment the mnt_refcnt
before calling dounmount() which causes the ensuing chaos.  The
following fixes the symptom but I don't know if it is the "right" way
to fix the bug:

Index: mfs_vfsops.c
===================================================================
RCS file: /cvsroot/src/sys/ufs/mfs/mfs_vfsops.c,v
retrieving revision 1.98
diff -u -r1.98 mfs_vfsops.c
--- mfs_vfsops.c        28 Jun 2008 01:34:05 -0000      1.98
+++ mfs_vfsops.c        25 Sep 2008 12:23:29 -0000
@@ -403,7 +403,7 @@
        mutex_enter(&mfs_lock);
        mfsp->mfs_refcnt++;
        mutex_exit(&mfs_lock);
-       vfs_unbusy(mp, false, NULL);
+       vfs_unbusy(mp, true, NULL);
 
        base = mfsp->mfs_baseoff;
        mutex_enter(&mfs_lock);

-- 
Brett Lymn
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."




Home | Main Index | Thread Index | Old Index