]> CyberLeo.Net >> Repos - FreeBSD/stable/8.git/commit
MFC: r252673
authorrmacklem <rmacklem@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Fri, 12 Jul 2013 00:59:03 +0000 (00:59 +0000)
committerrmacklem <rmacklem@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Fri, 12 Jul 2013 00:59:03 +0000 (00:59 +0000)
commit20caa3320be53c538856202682b7879f8f2c11e4
tree07d6210ac203b276444b9b7a033fa95845428fb4
parentbba27c0bfe6dbe34500d8d2c4a7f3fe82a87152d
MFC: r252673
A problem with the old NFS client where large writes to large files
would sometimes result in a corrupted file was reported via email.
This problem appears to have been caused by r251719 (reverting
r251719 fixed the problem). Although I have not been able to
reproduce this problem, I suspect it is caused by another thread
increasing np->n_size after the mtx_unlock(&np->n_mtx) but before
the vnode_pager_setsize() call. Since the np->n_mtx mutex serializes
updates to np->n_size, doing the vnode_pager_setsize() with the
mutex locked appears to avoid the problem.
Unfortunately, vnode_pager_setsize() where the new size is smaller,
cannot be called with a mutex held.
This patch returns the semantics to be close to pre-r251719 such that the
call to the vnode_pager_setsize() is only delayed until after the mutex is
unlocked when np->n_size is shrinking. Since the file is growing
when being written, I believe this will fix the corruption.

Tested by: remy.nonnenmacher@activnetworks.com

git-svn-id: svn://svn.freebsd.org/base/stable/8@253229 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/nfsclient/nfs_subs.c