Date: Mon, 28 Jun 1999 09:06:54 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Kirk McKusick <mckusick@flamingo.McKusick.COM> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alan Cox <alc@cs.rice.edu>, Mike Smith <mike@smith.net.au>, Peter Wemm <peter@FreeBSD.ORG>, "John S. Dyson" <toor@dyson.iquest.net>, dg@root.com, dyson@iquest.net, current@FreeBSD.ORG, Greg Lehey <grog@lemis.com> Subject: Re: Found the startup panic - ccd ( patch included ) Message-ID: <Pine.BSF.3.95.990628090542.10211A-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.3.95.990628011044.8298P-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I hate reeplying to myself, especially when it's to tell me that I'm an idiot.. I just realised (i think) that what I suggest below is exactly what you are doing... julian On Mon, 28 Jun 1999, Julian Elischer wrote: > > > On Sun, 27 Jun 1999, Kirk McKusick wrote: > > > I see that Peter has already committed it. > > > > On the subject of BUF_KERNPROC, this must be done as I have coded > > it, not later in biodone. The problem is when the filesystem does > > a readahead. It starts the I/O on the buffer that it really wants, > > then starts ASYNC reads on the readahead buffers. When it finishes > > with the buffer that it wanted and the application enters the kernel > > to get the next buffer, the filesystem will attempt to lock the > > buffer on which it earlier initiated the read. If the I/O has not > > yet finished one of two bad things will happen. If the lock is not > > recursive, it will panic with `locking against myself' since it will > > hold the lock from the time when it initiated the readahead. If > > recursive locking is allowed, then it will get the buffer (since > > it holds the exclusive lock) and use it before it has been filled. > > So, it is semantically important that ASYNC read buffers be disowned > > (i.e., given to the kernel) at the time they are created. That way, > > only the kernel can access the buffer until the read I/O is done. > > I agree that this code is ugly, but it is necessary. > > > > One solution to the "locking against self" probelm with read-ahead > buffers would be to give some other entity the ownership of the read-ahead. > I would consider even having a separate ID for async operations > (the asyncd kermnel thread?) Possibly they could simply be assigned to > an existing PID (we have several to chose from .. pagedaemon, > syncer or vmdaemon) > > I mean the requesting process isn't really actually requesting the > lookahead, so it should be up to the entity that DID request it > (the kernel?) to lock the buffers. I think that whenever you > try make something appear as something that it is not you complicate > the picture. In this case we are tryin g to make it look as if that process > was responsible for the readahead requests, when in actual fact, it is > another entity taking it upon itself to make that decision, and see where > it gets us? > > > julian > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990628090542.10211A-100000>