From owner-freebsd-hackers Sun Jun 13 16:23:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 7662615182 for ; Sun, 13 Jun 1999 16:23:15 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA26382; Sun, 13 Jun 1999 16:21:51 -0700 (PDT) Message-Id: <199906132321.QAA26382@implode.root.com> To: Matthew Dillon Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: problem for the VM gurus In-reply-to: Your message of "Sat, 12 Jun 1999 21:39:25 PDT." <199906130439.VAA65304@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 13 Jun 1999 16:21:51 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Interesting. It's an overlapping same-process deadlock with mmap/write. > This bug also hits NFS, though in a slightly different way, and also > occurs with mmap/write when two processes are mmap'ing two files and > write()ing the other descriptor using the map as a buffer. > > I see a three-stage solution: > > * We change the API for the VM pager *getpages() code. > > At the moment the caller busies all pages being passed to getpages() > and expects the primary page (but not any of the others) to be > returned busied. I also believe that some of the code assumes that > the page will not be unbusied at all for the duration of the > operation ( though vm_fault was hacked to handle the situation where > it might have been ). > > This API is screwing up NFS and would also make it very difficult for > general VFS deadlock avoidance to be implemented properly and for > a fix to the specific case being discussed in this thread to be > implemented properly. > > I recommend changing the API such that *ALL* passed pages are > unbusied prior to return. The caller of getpages() must then > VM lookup the page again. Always. vm_fault already does this, > in fact. We would clean up the code and document it to this effect. > > This change would allow us to immediately fix the self-referential > deadlocks and I think it would also allow me to fix a similar bug > in NFS trivially. I should point out here that the process of looking up the pages is a significant amount of the overhead of the routines involved. Although doing this for just one page is probably sufficiently in the noise as to not be a concern. > The easiest interim solution is to break write atomicy. That is, > unlock the vnode if the backing store of the uio being written is > (A) vnode-pager-backed and (B) not all in-core. Uh, I don't think you can safely do that. I thought one of the reasons for locking a vnode for writes is so that the file metadata doesn't change underneath you while the write is in progress, but perhaps I'm wrong about that. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message