Date: Mon, 24 Jul 1995 17:13:35 +0100 (BST) From: Doug Rabson <dfr@render.com> To: John Dyson <dyson@freefall.cdrom.com> Cc: dillon@blob.best.net, bugs@freebsd.org Subject: Re: brelse() panic in nfs_read()/nfs_bioread() Message-ID: <Pine.BSF.3.91.950724170846.12542L-100000@minnow.render.com> In-Reply-To: <199507241559.IAA24492@freefall.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Jul 1995, John Dyson wrote: > > > > I am mystified by this one. It looks as if the VM system has helpfully > > reallocated one of the pages associated with the buffer between starting > > the read and releasing the buffer. This should be impossible, as the > DG and I have been working this problem for the last few days. It is > indeed subtile... (Actually a similar one -- probably the same cause.) > > > pages are marked busy (vfs_busy_pages(bp, 0)) and the buffer is busy > > (B_BUSY is set). I don't really understand this bogus_page stuff; can > > someone explain it to me? > > > The bogus page stuff is used to keep modified pages that might have > lost their association with a buffer from being lost. > The sequence of events in nfs_bioread is more-or-less: vfs_busy_pages(bp, 0); <read data into buffer> biodone(bp); /* called from nfs_doio */ ... uiomove(...); ... brelse(bp); Is it possible that the pages can be reclaimed between the biodone(bp) and the brelse(bp). The buffer is still busy, so another getblk will wait until the release but the pages are 'unbusied' in biodone. If a sleep happens in uiomove as a result of a pagefault, then perhaps the VM system snatches the pages away then. One could fix this by surrounding the uiomove with calls to vfs_busy_pages and vfs_unbusy_pages. There must be a better way though. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.950724170846.12542L-100000>