From owner-freebsd-bugs Wed Jun 4 09:04:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA07000 for bugs-outgoing; Wed, 4 Jun 1997 09:04:45 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA06995 for ; Wed, 4 Jun 1997 09:04:43 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id JAA09579; Wed, 4 Jun 1997 09:04:16 -0700 (PDT) Message-Id: <199706041604.JAA09579@austin.polstra.com> To: Doug Rabson cc: freebsd-bugs@hub.freebsd.org Subject: Re: kern/3771 NFS hangs when writing to local FS re-mounted via NFS In-reply-to: Your message of "Wed, 04 Jun 1997 16:57:19 BST." References: Date: Wed, 04 Jun 1997 09:04:16 -0700 From: John Polstra Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The deadly embrace is in NFS. The sequence of events is something like > this: > > NFS client allocates a buffer and fills it with data > NFS client does a write rpc and locks the socket to read the reply > NFS server gets the write rpc and starts to process it > NFS server allocates a buffer to write the data > VFS runs out of clean buffers and picks a dirty one > (B_NEEDCOMMIT|B_DELWRI) > VFS calls NFS client to clean the buffer > NFS client tries to do a commit rpc but hangs because the socket > is locked That sounds like a different problem than the one that hits CVSup, then. CVSup just opens up two SOCK_STREAM connections between client and server, and does a bunch of non-blocking reads and writes. Because of the way the application is structured, it's easily proved that there's no inherent deadlock. (It's a linear pipeline of 5 threads connected by 4 unidirectional channels.) It hangs when localhost is used, but not when other transports are used. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth