From owner-freebsd-current Mon Jun 28 10:35: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 8B47C1539D for ; Mon, 28 Jun 1999 10:35:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA23042; Mon, 28 Jun 1999 10:35:21 -0700 (PDT) (envelope-from dillon) Date: Mon, 28 Jun 1999 10:35:21 -0700 (PDT) From: Matthew Dillon Message-Id: <199906281735.KAA23042@apollo.backplane.com> To: Peter Wemm Cc: Kirk McKusick , Julian Elischer , Alan Cox , Mike Smith , "John S. Dyson" , dg@root.com, dyson@iquest.net, current@FreeBSD.ORG, Greg Lehey Subject: Re: Found the startup panic - ccd ( patch included ) References: <19990628165738.E590283@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Certain places use B_CALL and have biodone() from the b_iodone routine, :so we can't reliably use B_ASYNC as an indicator of needing to reassign :to LK_KERNPROC. We have to do it on a case-by-case basis. : :It's easier to do cluster_head processing at the point it's gathered :rather than in BUF_KERNPROC(). : :vfs_cluster.c is confusing, but I think I've figured out how to get it :right. I'm not 100% sure about checking for B_CALL in both cases prior :to VOP_STRATEGY(), and maybe reqbp needs to be considered for the first :... There has got to be a better way to do this. This is unbelievably messy. Please, guys. I am all for stabilizing what was committed but I just spent a month removing fragility from the buffer cache code, and this is adding it right back in. This stuff is just too fragile. Even if we fix it now, it is only going to cause serious problems in the future. It looks to me that these hacks exist to get around potential problems with exclusive lock recursion. We are not *doing* any exclusive lock recursion right now. I am fairly confident that Kirk can implement the new softupdates-related elements without having to resort to exclusive lock recursion, with only a little thought on the matter. Can we please get rid of the lock reassign junk that only exists to support exclusive lock recusion and instead go with something simpler? That way we can remove all of these BUF_KERNPROC calls which have been strewn all over the code. We have the luxury of time here, can we please do this implementation right instead of rushing through making design mistakes? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message