From owner-cvs-all Tue Oct 24 3:13:42 2000 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 56CB637B479; Tue, 24 Oct 2000 03:13:38 -0700 (PDT) Received: (from dwmalone@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id DAA74467; Tue, 24 Oct 2000 03:13:38 -0700 (PDT) (envelope-from dwmalone@FreeBSD.org) Message-Id: <200010241013.DAA74467@freefall.freebsd.org> From: David Malone Date: Tue, 24 Oct 2000 03:13:37 -0700 (PDT) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/nfs nfs.h nfs_subs.c nfsm_subs.h X-FreeBSD-CVS-Branch: HEAD Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dwmalone 2000/10/24 03:13:37 PDT Modified files: sys/nfs nfs.h nfs_subs.c nfsm_subs.h Log: 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 Reviewed by: dillon Tested by: Vadim Belman Revision Changes Path 1.56 +2 -2 src/sys/nfs/nfs.h 1.96 +13 -4 src/sys/nfs/nfs_subs.c 1.28 +3 -3 src/sys/nfs/nfsm_subs.h To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message