From owner-freebsd-current Sat Aug 15 16:50:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04879 for freebsd-current-outgoing; Sat, 15 Aug 1998 16:50:25 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04874 for ; Sat, 15 Aug 1998 16:50:23 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA20449; Sat, 15 Aug 1998 16:49:26 -0700 (PDT) Message-Id: <199808152349.QAA20449@implode.root.com> To: Julian Elischer cc: Terry Lambert , current@FreeBSD.ORG Subject: Re: Tentative fix for VM bug In-reply-to: Your message of "Fri, 14 Aug 1998 10:59:57 PDT." From: David Greenman Reply-To: dg@root.com Date: Sat, 15 Aug 1998 16:49:26 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >yes, but is it a bug that he's reporting? I don't see anything wrong with vm_object_page_remove(). We'd have far more serious problems if there was something wrong with it (the system wouldn't last for more than a few seconds, if that), and further, the problem wouldn't be specific to just NFS. My thinking at the moment is that the problem is caused by the lack of NFSnode locking; we depend on VOP_LOCK actually doing something in many parts of the code, and with nfs_lock() being a noop, it just doesn't happen. There might be a way to fix this without messing with nfs_lock(), but the exact failure scenario will need to be looked at carefully before this can be determined. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message