From owner-freebsd-bugs Mon Jul 24 20:22:57 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id UAA04884 for bugs-outgoing; Mon, 24 Jul 1995 20:22:57 -0700 Received: (from dyson@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id UAA04874 ; Mon, 24 Jul 1995 20:22:56 -0700 From: John Dyson Message-Id: <199507250322.UAA04874@freefall.cdrom.com> Subject: Re: brelse() panic in nfs_read()/nfs_bioread() To: dfr@render.com (Doug Rabson) Date: Mon, 24 Jul 1995 20:22:56 -0700 (PDT) Cc: dillon@blob.best.net, bugs@freebsd.org In-Reply-To: from "Doug Rabson" at Jul 24, 95 05:13:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2231 Sender: bugs-owner@freebsd.org Precedence: bulk > > 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); > > 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, your were close in on the right area where there is/was a bug. I just submitted a fix to vfs_unbusy_pages to DG for his review/mods that should solve some problems. It appears that the bogus page handling was faulty for the 2nd and subsequent pages in a buffer. This only manifests itself on read-aheads on VREG files. It is most likely a major component (perhaps the only component) of the elusive problem that you and others have been seeing. A person that DG has been working with fairly closely noticed that the situation got much better when the async daemons were turned off. I had my suspicions -- and noticed that foff was not being incremented properly in vfs_unbusy_pages!!! DG will probably test and commit this change soon... John dyson@root.com