Date: Mon, 28 Jun 1999 04:54:07 -0700 From: Kirk McKusick <mckusick@flamingo.McKusick.COM> To: Julian Elischer <julian@whistle.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: <199906281154.EAA02335@flamingo.McKusick.COM> In-Reply-To: Your message of "Mon, 28 Jun 1999 01:21:21 PDT." <Pine.BSF.3.95.990628011044.8298P-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Mon, 28 Jun 1999 01:21:21 -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 ) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906281154.EAA02335>