From owner-freebsd-current Tue Feb 23 8:25:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id C5CE51169B for ; Tue, 23 Feb 1999 08:25:56 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id LAA09126; Tue, 23 Feb 1999 11:25:53 -0500 (EST) (envelope-from luoqi) Date: Tue, 23 Feb 1999 11:25:53 -0500 (EST) From: Luoqi Chen Message-Id: <199902231625.LAA09126@lor.watermarkgroup.com> To: dyson@iquest.net, luoqi@watermarkgroup.com Subject: Re: Filesystem deadlock Cc: freebsd-current@FreeBSD.ORG, green@unixhelp.org, kan@sti.cz 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. > Do you still have that piece of code? Does it handle the case involves more than one process? For example, process 1 mmaps file B and reads file A into the mmapped region, while process 2 mmaps file A and reads file B, this could also result in a deadlock. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message