From owner-freebsd-current Mon Jun 28 1:28:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8910314E1E; Mon, 28 Jun 1999 01:28:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA18365; Mon, 28 Jun 1999 01:28:29 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 01:28:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199906280828.BAA18365@apollo.backplane.com> To: Kirk McKusick Cc: Alan Cox , Julian Elischer , 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 ) References: <199906280347.UAA01061@flamingo.McKusick.COM> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message