VOP_WRITE & read-only file system

[Kostik Belousov]

On Wed, May 27, 2009 at 06:02:59PM +0300, Jaakko Heinonen wrote:
> 
> Hi,
> 
> 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.
> 
> Ways I found:
> 
> 1) mmap(2)
>   - mmap(2) a file
>   - close(2) the file handle
>   - remount file-system as read-only
>   - modify mapped memory
> 
> 2) ktrace(2)
>   - start ktracing a process
>   - remount file-system as read-only
> 
> 3) alq(9)
>   - I didn't really test this but it looks obvious
> 
> 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).

> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20090527/3b984117/attachment.pgp