diff options
author | dwmalone <dwmalone@FreeBSD.org> | 2000-10-24 10:13:36 +0000 |
---|---|---|
committer | dwmalone <dwmalone@FreeBSD.org> | 2000-10-24 10:13:36 +0000 |
commit | 23aacadb399d3f3dd29eaa0a598b0359a2cd352a (patch) | |
tree | 85dc5320ff541ac0d2796e656cd50c2ebbf1bbf7 /bin/pwd | |
parent | 79719d2ea5f8674e63d2a884d88c38227a3f1e38 (diff) | |
download | FreeBSD-src-23aacadb399d3f3dd29eaa0a598b0359a2cd352a.zip FreeBSD-src-23aacadb399d3f3dd29eaa0a598b0359a2cd352a.tar.gz |
Problem to avoid processes getting stuck in "vmopar". From Ian's
mail:
The problem seems to originate with NFS's postop_attr
information that is returned with a read or write RPC.
Within a vm_fault context, the code cannot deal with
vnode_pager_setsize() shrinking a vnode.
The workaround in the patch below stops the nfsm_postop_attr()
macro from ever shrinking a vnode. If the new size in the
postop_attr information is smaller, then it just sets the
nfsnode n_attrstamp to 0 to stop the wrong size getting
used in the future. This change only affects postop_attr
attributes; the nfsm_loadattr() macro works as normal.
The change is implemented by adding a new argument to
nfs_loadattrcache() called 'dontshrink'. When this is
non-zero, nfs_loadattrcache() will never reduce the
vnode/nfsnode size; instead it zeros n_attrstamp.
There remain other was processes can get stuck in vmopar.
Submitted by: Ian Dowse <iedowse@maths.tcd.ie>
Reviewed by: dillon
Tested by: Vadim Belman <voland@lflat.org>
Diffstat (limited to 'bin/pwd')
0 files changed, 0 insertions, 0 deletions