Date: Tue, 22 Feb 2000 10:48:59 -0500 (EST) From: Luoqi Chen <luoqi@watermarkgroup.com> To: alfred@FreeBSD.org, bde@zeta.org.au Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sbin/mount mount.8 Message-ID: <200002221548.KAA26366@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> On Mon, 21 Feb 2000, Alfred Perlstein wrote:
>
> > * Luoqi Chen <luoqi@watermarkgroup.com> [000221 20:33] wrote:
> > > The danger of corruption when downgrading a rw mount to ro mount is real.
> > > I had a correspondence with kirk regarding one possible of scenario quite
> > > a while ago, but it was too nasty to fix (IIRC), so we dropped the issue.
> >
> > Do you have this archived anywhere, or can you explain what goes wrong?
>
> One problem (explained to me by Luoqi) is for unlinked open files. Consider
> the following sequence of events:
>
> (1) mount -o rw ...
> (2) fd = open("foo", O_WRONLY ...);
> (3) unlink("foo");
> (4) mount -u -o ro ... -> vflush(...);
> (5) close(fd); -> ufs_inactive(...);
>
> Step (3) doesn't remove the inode because the file is open. Step (5) can't
> remove the inode because the filesystem is read-only. Step (4) apparently
> doesn't handle this problem (except possibly in the FORCECLOSE case).
>
> I added a similar but relatively harmless bug in the special-file timestamp
> optimisations. Writing of timestamps is delayed until ufs_inactive(),
> but that is too late if the filesystem has become read-only.
>
> Bruce
>
Thanks, Bruce, this refreshed my memory. I was having trouble digging
through my emails. A small correction though, in step (2), open the
file O_RDONLY. Because it is not open for writing, it would escape
detection by vflush(WRITECLOSE) in step (4).
One fix is to modify vflush() to detect such cases, i.e.
(vp->v_writecount == 0 && ip->i_nlink == 0).
But vflush() doesn't have access to the FS specific inode information,
and we don't want to add any ufs specific code to vflush(), so the only
option we have is to add a VOP callback to allow individual filesystem
a chance to declare a vnode busy. (So it wasn't like what I said, too
nasty to fix. Too lazy might be a more suitable word :-)
Even if we fixed this one, we are not sure if there isn't any other problem
left that would compromise filesystem integrity (remember this part of the
code is barely tested). I think a warning label is still warranted.
-lq
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200002221548.KAA26366>