Date: Wed, 27 May 2009 18:35:43 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Jaakko Heinonen <jh@saunalahti.fi> Cc: freebsd-fs@freebsd.org Subject: Re: VOP_WRITE & read-only file system Message-ID: <20090527153543.GK1927@deviant.kiev.zoral.com.ua> In-Reply-To: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi> References: <20090527150258.GA3666@a91-153-125-115.elisa-laajakaista.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
--N2sd0375daQhR1Ll Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2009 at 06:02:59PM +0300, Jaakko Heinonen wrote: >=20 > Hi, >=20 > I found a few ways to get VOP_WRITE called for a read-only system. Looks > like there is an assumption in (UFS) file system code that VOP_WRITE is > not called for read-only file-systems and indeed the assumption is true > in typical cases. Calling VOP_WRITE for a read-only file system leads to > erratic behavior at least with UFS. >=20 > Ways I found: >=20 > 1) mmap(2) > - mmap(2) a file > - close(2) the file handle > - remount file-system as read-only > - modify mapped memory >=20 > 2) ktrace(2) > - start ktracing a process > - remount file-system as read-only >=20 > 3) alq(9) > - I didn't really test this but it looks obvious >=20 > At which level this should be fixed? Is it caller's responsibility not > to call VOP_WRITE if the file system is read-only or should there be a > check in VOP_WRITE? Yes, the issue is there. Real cause for the problem is that mmap() does not increment v_writecnt of the vnode that backs shared writable mappings. I have a patch that fixes this, see http://people.freebsd.org/~kib/misc/vm_map_delete.3.patch It is complicated because you cannot lock a vnode while holding user map lock, and you need to increment v_writecnt during mmap (that is relatively easy, by locking vnode in advance) and when map entry is splitted (that is hard). >=20 > Another concern is races during remount. I don't see that UFS has > protection against read-only flag changing during VOPs. During remount rw->ro or unmount, UFS filesystem is suspended, see r183074. Suspension waits for the currently executing vops that modify the file system, and then blocks new vops until suspension is lifted. --N2sd0375daQhR1Ll Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkodXc8ACgkQC3+MBN1Mb4hfUACePXI5gMUQLbD1MMU0XVZoemn4 KDEAoIJa35IKJkfclbGb4cKTNXMXgB3T =lo4I -----END PGP SIGNATURE----- --N2sd0375daQhR1Ll--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090527153543.GK1927>