Date: Fri, 22 Feb 2002 19:10:32 -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.020222191032.jhb@FreeBSD.org> In-Reply-To: <200202221835.g1MIZsZ18088@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Feb-02 Matthew Dillon wrote: > >:>:John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ >:> >:> Don't try to overengineer the problem. Unless you believe there is >:> a serious problem, there is no need to put a check in every single >:> conceivable place an error might occur. Just putting a few safety >:> checks >:> in a few critical places should be sufficient. >: >:I don't know where all the places we might look at a ucred wrongly are. >:That's >:why I wanted the much simpler solution of just clearing td_ucred to NULL so >:we >:had an implicit KASSERT for us in all those places. >: >:-- >: >:John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > > This doesn't make any sense whatsoever. *NOTHING* was using td_ucred > until just a few days ago, so unless *you* are blindly changing all > p->p_ucred's into td->td_ucred's, I don't see how it can become an issue. Yes, almost all the p_ucred's are changing to td_ucred. That is why we have td_ucred. td_ucred doesn't need a lock, but accessing p_ucred does. Did you read the description of td_ucred back when it was first proposed? > -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.020222191032.jhb>