Date: Thu, 07 Feb 2002 19:12:21 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: current@freebsd.org Subject: Re: ucred for threads Message-ID: <3C634215.23CF1227@mindspring.com> References: <Pine.BSF.4.21.0202071754060.91961-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
> yes.. well in booting yuo can have a null ucred. ( I know,s
> I've hit it), but in general you are correct.
[ ... ]
> > What is the default state of td->td_ucred?
>
> on creation, NULL followed very rapidly with being set to
> p->p_ucred. (via crhold)
Non-problem, then.
> > If that's the case, then the code should be:
> >
> > if (td->td_ucred != p->p_ucred) {
> > PROC_LOCK(p);
> > if (td->td_ucred) {
> > crfree(td->td_ucred);
> > }
>
> without the if it crashes in boot sometimes.
> (this may not be true right now but was during my testing of
> the KSE kernel)
The place to fix this is by setting up a default reference to
a root/boot ucred, I think, for use by the initial process
template.
What are the consequences, if any, of me having removed the
setting the thing to NULL, during boot? I guess that it
would leave the thread cred uninitialized. Obviously, the
problem with your crash is in the crhold( NULL). 8-).
It seems to me that the test would leave threads with NULL
ucreds around as well, and just complicate things later.
Is there a reason you can't set up an initial ucred?
-- Terry
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?3C634215.23CF1227>