]> CyberLeo.Net >> Repos - FreeBSD/stable/9.git/commit
MFC: r252528
authorrmacklem <rmacklem@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 10 Jul 2013 00:31:28 +0000 (00:31 +0000)
committerrmacklem <rmacklem@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 10 Jul 2013 00:31:28 +0000 (00:31 +0000)
commit36e2e479b7ede22f5bf5856662411073daf8dba4
treed49ec1ca4dec8f3c416c0430b6ec845b59e83e22
parent4698df4ecc19f6e48c5e46b7bd7438ebdb91bd20
MFC: r252528
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 (actually
pre-r248567, r248581, r248567 for the new client) such that the call to
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.
A better solution might be to replace the mutex with a sleep lock,
but that is a non-trivial conversion, so this fix is hoped to be
sufficient in the meantime.

Tested by: remy.nonnenmacher@activnetworks.com

git-svn-id: svn://svn.freebsd.org/base/stable/9@253124 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/fs/nfsclient/nfs_clport.c