From owner-freebsd-current Mon Jun 28 9:10:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from flamingo.McKusick.COM (flamingo.mckusick.com [209.31.233.178]) by hub.freebsd.org (Postfix) with ESMTP id 4446F15143; Mon, 28 Jun 1999 09:10:43 -0700 (PDT) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (mckusick@localhost.concentric.net [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id EAA02335; Mon, 28 Jun 1999 04:54:08 -0700 (PDT) Message-Id: <199906281154.EAA02335@flamingo.McKusick.COM> To: Julian Elischer Subject: Re: Found the startup panic - ccd ( patch included ) Cc: Matthew Dillon , Alan Cox , Mike Smith , Peter Wemm , "John S. Dyson" , dg@root.com, dyson@iquest.net, current@freebsd.org, Greg Lehey In-reply-to: Your message of "Mon, 28 Jun 1999 01:21:21 PDT." Date: Mon, 28 Jun 1999 04:54:07 -0700 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Mon, 28 Jun 1999 01:21:21 -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: <199906280347.UAA01061@flamingo.McKusick.COM> 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 The BUF_KERNPROC does exactly what you are talking about. It says take this buffer and give it away to the kernel. It is assigned the "kernel" pid so that it will not be accessible to the process that initiated it until it is released by the kernel. Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message