From owner-freebsd-current Mon Jun 28 9: 7: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5A0C415143; Mon, 28 Jun 1999 09:07:03 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id JAA19630; Mon, 28 Jun 1999 09:06:55 -0700 (PDT) Date: Mon, 28 Jun 1999 09:06:54 -0700 (PDT) From: Julian Elischer To: Kirk McKusick Cc: Matthew Dillon , Alan Cox , Mike Smith , Peter Wemm , "John S. Dyson" , dg@root.com, dyson@iquest.net, current@FreeBSD.ORG, Greg Lehey Subject: Re: Found the startup panic - ccd ( patch included ) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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