[Bug 210316] panic after trying to r/w mount msdosfs on write protected media

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210316

--- Comment #7 from Damjan Jovanovic <damjan.jov at gmail.com> ---
If I add this code snippet (copied from somewhere in the ext2fs driver) so that
vinvalbuf() is called before g_vfs_close(), the r/w mount of a r/o geom fails
(EPERM), and the panic doesn't happen:

diff --git a/sys/fs/msdosfs/msdosfs_vfsops.c b/sys/fs/msdosfs/msdosfs_vfsops.c
index 76a238c5ff77..7477d5b03a1f 100644
--- a/sys/fs/msdosfs/msdosfs_vfsops.c
+++ b/sys/fs/msdosfs/msdosfs_vfsops.c
@@ -717,6 +717,12 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp)
 error_exit:
        if (bp)
                brelse(bp);
+
+       vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY);
+       if (vinvalbuf(devvp, 0, 0, 0) != 0)
+               panic("mountmsdosfs: dirty");
+       VOP_UNLOCK(devvp, 0);
+
        if (cp != NULL) {
                g_topology_lock();
                g_vfs_close(cp);

Apart from not really understanding it, I don't like it, because if every
filesystem should be calling vinvalbuf() before g_vfs_close(), then shouldn't
g_vfs_close() rather be calling vinvalbuf() itself? Also msdosfs_unmount()
doesn't call vinvalbuf() before its own g_vfs_close(), but it does call
msdosfs_sync() and vflush(). Would those also work, or be even better?

Fixing UFS will be a different story, as msdosfs writes to the filesystem
during mount [in markvoldirty()], so the panic is almost immediate. I could
only crash UFS by trying to write to a file after mounting.

-- 
You are receiving this mail because:
You are the assignee for the bug.