Commit fix for NFS write deadlock, on filesystems mounted via

local-loopback (lo0). As posted for review on tech-kern 2003-18-09,
with a long  comment explaining (one of) the deadlock scenarios.

I've used this since shortly after 2002-09-12-, without noticing
performance degradataion or instability for non-loopback mounts.
This commit is contained in:
jonathan 2003-11-17 00:28:32 +00:00
parent 982688a7fd
commit 6ddd119256
1 changed files with 11 additions and 5 deletions

View File

@ -1,4 +1,4 @@
/* $NetBSD: nfs_bio.c,v 1.110 2003/09/26 11:51:53 yamt Exp $ */
/* $NetBSD: nfs_bio.c,v 1.111 2003/11/17 00:28:32 jonathan Exp $ */
/*
* Copyright (c) 1989, 1993
@ -35,7 +35,7 @@
*/
#include <sys/cdefs.h>
__KERNEL_RCSID(0, "$NetBSD: nfs_bio.c,v 1.110 2003/09/26 11:51:53 yamt Exp $");
__KERNEL_RCSID(0, "$NetBSD: nfs_bio.c,v 1.111 2003/11/17 00:28:32 jonathan Exp $");
#include "opt_nfs.h"
#include "opt_ddb.h"
@ -836,10 +836,16 @@ again:
/*
* If we have an iod which can process the request, then queue
* the buffer.
* the buffer. However, even if we have an iod, do not initiate
* queue cleaning if curproc is the pageout daemon. if the NFS mount
* is via local loopback, we may put curproc (pagedaemon) to sleep
* waiting for the writes to complete. But the server (ourself)
* may block the write, waiting for its (ie., our) pagedaemon
* to produce clean pages to handle the write: deadlock.
* XXX: start non-loopback mounts straight away? If "lots free",
* let pagedaemon start loopback writes anyway?
*/
if (gotiod) {
if (gotiod && (curproc != uvm.pagedaemon_proc)) {
/*
* Ensure that the queue never grows too large.