Date: Sun, 13 Jun 1999 16:21:51 -0700 From: David Greenman <dg@root.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: problem for the VM gurus Message-ID: <199906132321.QAA26382@implode.root.com> In-Reply-To: Your message of "Sat, 12 Jun 1999 21:39:25 PDT." <199906130439.VAA65304@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906132321.QAA26382>