Attempt to interlock races between the buffer cache and VM backing store
authorMatthew Dillon <dillon@dragonflybsd.org>
Tue, 16 May 2006 18:20:32 +0000 (18:20 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Tue, 16 May 2006 18:20:32 +0000 (18:20 +0000)
commitc4b46cb465e8dd46ace0f59e1128d73b59af170e
tree6b658e0985e1cae3de0bcce28956673e856e8168
parent7dbdaa298b80e9ac2b7767a2db76a15b83ee970b
Attempt to interlock races between the buffer cache and VM backing store
that might cause new buffers to be instantiated beyond the new file EOF
during a truncate operation.

Truncate the VM object size before attempting to flush the pages and buffers
in order to prevent new VM pages from being created beyond EOF during the
flush.  Add an extra pass on the buffer cache after truncation to make sure
the buffers have been cleaned out.  Generate a warning to the console if
buffers are found during the extra pass.

If an old buffer were left intact during a truncate, then a re-extension of
the file or directory could have resulted in granting access to the old
buffer which might have had an incorrect cached block number translation
(vs the new block allocated by the extension of the file or directory),
causing new data to be written to the wrong disk block and resulting in
file or directory corruption.  The regular file truncation/extension
code had other checks in it prior to this patch so if this problem could
occur at all before it would have been in the directory code.

There is a small chance that this race was related to reported
ufs: dirbad panics.  The M.O. matches but unfortunately there is still
no smoking gun.
sys/kern/vfs_subr.c
sys/vm/vnode_pager.c