Date: Mon, 28 Jun 1999 01:28:29 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kirk McKusick <mckusick@flamingo.McKusick.COM> Cc: Alan Cox <alc@cs.rice.edu>, Julian Elischer <julian@whistle.com>, 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: <199906280828.BAA18365@apollo.backplane.com> References: <199906280347.UAA01061@flamingo.McKusick.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
: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,
:...
: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.
Ok, I see the problem. But I still think we need to implement
this a different way. Polluting all the VOP_STRATEGY calls with
yet another setup requirement that someone may forget to do is
a step backwards, especially if it is only covering a specific
situation that could be solved in other ways.
Perhaps we can implement a locking system that is immune to the
problem. i.e. not attempt to continue to use lockmgr() locks
which are turning out to be unsuited to the work but instead
use something like my qlocks, but modified to deal with the
I/O situation. Perhaps we can use Terry's suggestion for
function-specific locks.
Instead of using a shared/exclusive lock we instead implement
a zone bitmap type of lock, where we can obtain a bitmask of up to
32 non-recursive exclusive locks simultaniously. We would then use
the bits to indicate different situations.
We would no longer need recursive locks or even shared locks but instead
would define bits for immediate access (bits not held through a blocking
condition) and for long-term operations-in-progress, such as an
I/O-in-progress sitiation ( bits held through a blocking condition).
Alternatively, we can use a combination of locks to implement exclusivity
as well as shared access. e.g. one bit masking exclusive lock and one
normal lock.
Normal locks would be obtained and released quickly ( so there is no
recursion problem ), but when read I/O is initiated the
read-I/O-in-progress lock bit would be left set, and when write I/O is
initiated the write-I/O-in-progress lock bit would be left set.
Later on when we are trying to relock the buffer, but do not want to
allow the situation where we relock a buffer with I/O in progress,
we simply attempt to get the I/O bits *AND* the code serialization
bit all simultaniously. Since the I/O is in progress this attempt would
fail. If the I/O is not in progress both locks succeed; recursion
is not a problem because the access lock is strictly temporary and
was held and released earlier.
:not yet used). I propose the following change to the buffer locking
:code to basically avoid the locking against myself panic when doing
:a polling lock (since if recursion is not allowed it will return
:an error rather than blocking). I am going to leave this running
:on my test machine overnight to check for problems. I am committing
:it now as I believe it to be correct and that it will solve some
:of the locking problems that we have seen.
:
:Index: kern_lock.c
:===================================================================
:RCS file: /home/ncvs/src/sys/kern/kern_lock.c,v
:...
:
: Kirk
I'll try running this too.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199906280828.BAA18365>