From owner-freebsd-current Mon Feb 22 23:24:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (Postfix) with SMTP id 5708B11AD6 for ; Mon, 22 Feb 1999 23:24:13 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 5547 invoked from network); 23 Feb 1999 07:24:10 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 23 Feb 1999 07:24:10 -0000 Received: (from toor@localhost) by y.dyson.net (8.9.1/8.9.1) id CAA02628; Tue, 23 Feb 1999 02:24:07 -0500 (EST) Message-Id: <199902230724.CAA02628@y.dyson.net> Subject: Re: Filesystem deadlock In-Reply-To: <199902230712.CAA02316@lor.watermarkgroup.com> from Luoqi Chen at "Feb 23, 99 02:12:50 am" To: luoqi@watermarkgroup.com (Luoqi Chen) Date: Tue, 23 Feb 1999 02:24:07 -0500 (EST) Cc: green@unixhelp.org, kan@sti.cz, freebsd-current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luoqi Chen said: > > > This seems to be the good old vnode deadlock during vm_fault() that has been > reported a couple of times, and there's still no satisfactory solution to it: > fgrep does something like this: (don't ask me why) > > addr = mmap(0, len, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, offset); > read(fd, addr, count); > > the read() syscall first locks the vnode, read the data from disk, then copy > the data to buffer at addr, now if addr is not in core, there'll be a page > fault and the fault handler vm_fault will try to lock the vnode pager backing > the page at addr, which is already locked, deadlock. This deadlock then > propagates all the way back to the root vnode and the whole system would > freeze. > I believe that I had a pseudo-fix to that, and it might have been removed. (In non-multithreaded kernels, when having to do things like the above, allowing recursive locks under certain circumstances can solve the problem. The key is to avoid the case where it covers up real bugs.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message