File remove problem

[Don Lewis]

On  2 Dec, Bruce Evans wrote:

> So it should be safe to remove all the r/o checks in ufs_inactive() after
> fixing the other bugs.  ffs_truncate alread panics if fs_ronly, but only
> in some cases.  In particular, it doesn't panic for truncations that don't
> change the file size.  Such truncations aren't quite null, since standards
> require [f]truncate(2) to mark the ctime and mtime for update.
> ffs_truncate() sets the marks, which is correct for null truncations from
> userland but not ones from syncer internals.  Setting of the marks when
> fs_ronly is set should cause panics later (my patch has a vprint() for it).

I think the MNT_RDONLY check in ufs_itimes_locked() should be also be
changed to look at fs_ronly and panic if any marks are set.  This will
require some changes to add some early MNT_RDONLY checks.

In particular, ffs_read() and ffs_extread() need to check MNT_RDONLY in
addition to MNT_NOATIME (as is already done in vfs_mark_atime()).  This
also looks like it should be a reasonable optimization for read-only
file systems that should eliminate unnecessary work at the lower levels
of the code.

The early IN_ACCESS flag setting in ufs_setattr(), before the MNT_RDONLY
check, appears to be protected by the MNT_RDONLY check in
vfs_mark_atime().