Date: Fri, 23 Apr 2004 18:37:04 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Stephan Uphoff <ups@tree.com> Cc: Stephan Uphoff <ups@tree.com> Subject: Re: Re99: how to flush out cache.? Message-ID: <200404240137.i3O1b4W0010070@apollo.backplane.com> References: <200404232345.TAA10405@stups.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:When I get the time (probably not next week) I will write a patch
:to release the cached buffers that would prevent page removal.
I would appreciate a CC if/when you have something along these lines.
It won't be easy. The VM system has no reliable way to determine the
buffer cache block size for a VM object or VNODE, nor any idea how to
deal with the buffer state which can vary in subtle ways between VFS's
(e.g. NFS vs UFS). So a new VOP call would probably have to be created
to clean out the buffers associated with a memory range.
We might want to create such a call anyway in order to support ranged
fsync()'s.
:The bug affects only in memory modified file data.
:
:In memory modifications to the file can be deleted
:and the file data reverts to a state before the
:file modification. (Not unlike a crash/power failure )
:
:The worst security scenario I can think of is the possibility
:to revert a file to uninitialized disk data blocks or to
:prevent the update of a file.
:
: Stephan
I won't say that it's imposible, but it would sure be hard to accomplish
since access to uninitialized disk data blocks is going to be governed
by the buffer cache, and the buffer is cleared unconditionally when
balloc'd inside ffs_write() (and the blocks will not be assigned if one
tries to do a read() if a file hole).
The only other code that calls VOP_BALLOC() for a file block is
ftruncate(), and it also does an unconditional write.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404240137.i3O1b4W0010070>