Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Jun 1999 10:35:21 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Peter Wemm <peter@netplex.com.au>
Cc:        Kirk McKusick <mckusick@flamingo.McKusick.COM>, Julian Elischer <julian@whistle.com>, Alan Cox <alc@cs.rice.edu>, Mike Smith <mike@smith.net.au>, "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:  <199906281735.KAA23042@apollo.backplane.com>
References:   <19990628165738.E590283@overcee.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
: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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906281735.KAA23042>