Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Feb 2002 23:36:59 -0500 (EST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        arch@FreeBSD.ORG, Julian Elischer <julian@elischer.org>
Subject:   Re: RE: that INVARIANT/ucred freeing stuff.
Message-ID:  <XFMail.020221233659.jhb@FreeBSD.org>
In-Reply-To: <200202212204.g1LM4vQ09988@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 21-Feb-02 Matthew Dillon wrote:
>     We learned a lesson with DIAGNOSTIC.  You are repeating the same mistakes
>     DIAGNOSTIC had which resulted in DIAGNOSTIC becoming essentially
> unusable.
>     INVARIANTS != DIAGNOSTIC.  If you want to resurrect DIAGNOSTIC you are
>     welcome to throw this ucred-clearing code under that option.
> 
>     INVARIANTS is not supposed to change algorithms or optimizations
>     wholesale.  It is simply supposed to add additional sanity checks to
>     existing algorithms and optimizations.
> 
>     So when the decision was made to implement td_ucred as an optimization,
>     that means that is what we need to use.  We should not go lobotomizing
>     it for INVARIANTS.
> 
>     It's that simple.  It is nothing even close to the <sarcastic> absurdness
>     of removing KASSERT for INVARIANTS that you are trying to contrast it
>     against.
> 
>     What I recommend you do, John, is to add KASSERT()s at a few critical
>     points in the code to assert that td_ucred is not being used out of
>     context.  We ... meaning Julian and myself mainly, see absolutely no
>     point in lobotomizing an optimization that has such a huge effect on
>     performance just because INVARIANTS is turned on.  That is not the
>     purpose of INVARIANTS.   We want that code *GONE*.
> 
>     We would like you to acquiesce to this request.

Fine, stick it under DIAGNOSTIC (which isn't dead.)  The problem is that there
aren't just 5 places in the kernel that you would need to stick this assert,
you would need it all over the place.  But I guess no one else has looked at
all the places that p_ucred is used and thought about how to ensure we don't
use a bogus td_ucred.

>                                               -Matt

-- 

John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




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