Date: Mon, 28 Jun 1999 01:21:21 -0700 (PDT)
From: Julian Elischer <[EMAIL PROTECTED]>
To: Kirk McKusick <[EMAIL PROTECTED]>
cc: Matthew Dillon <[EMAIL PROTECTED]>,
Alan Cox <[EMAIL PROTECTED]>,
Mike Smith <[EMAIL PROTECTED]>, Peter Wemm <[EMAIL PROTECTED]>,
"John S. Dyson" <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Greg Lehey <[EMAIL PROTECTED]>
Subject: Re: Found the startup panic - ccd ( patch included )
In-Reply-To: <[EMAIL PROTECTED]>
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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
