Re: 8.0-BETA4 panic: ffs_sync: rofs mod

On Thursday 10 September 2009 11:13:29 Jaakko Heinonen wrote:
> On 2009-09-09, Mel Flynn wrote:
> > This problem has also been seen on -questions [1] and I forgot to follow
> > up after time issues. According to the poster it's easy to reproduce:
> > - have a mountpoint in /etc/fstab with ro options
> > - unmount the mountpoint
> > - remount using -o rw
> 
> This has been also reported as PR kern/133614. I have tried to reproduce
> the problem earlier but I didn't succeed until now. Here's how to
> reproduce it:
> 
> 1. Have mountd(8) running
> 2. # mdconfig -a -t vnode -f ufsimg
> 3. # mount -o ro,rw /dev/md0 /mnt
> 4. # touch /mnt/foo && sync
> 
> This is what's going on:
> 
> Initial nmount() is done with "ro" and "rw" options. The mount point
> will have "ro", "rw" and "noro" string mount options after nmount().
> MNT_RDONLY flag is not set.
> 
> Then mountd(8) calls nmount() with "update" and "export" string options.
> This results FFS code to re-mount the file system as read-only because
> the "ro" string option is active for the mount point. ffs_mount() sets
> MNT_RDONLY and FFS fs_ronly flags. MNT_RDONLY gets later cleared in
> vfs_domount() because vfs_export() fails with ENOENT but the fs_ronly
> flag stays enabled.
> 
> The most obvious problem seems to be that both "ro" and "rw" options are
> allowed to enter to mount point options concurrently.

Why does mountd(8) call nmount with update? As I read the above, any command 
line overrides done through umount/mount will be negated by having mountd 
running. That's a bit surprising.
-- 
Mel