Date: Sun, 10 Feb 2002 12:08:12 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Julian Elischer <julian@elischer.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, FreeBSD current users <current@FreeBSD.ORG> Subject: Re: cred stuff.. Message-ID: <20020210114611.W5212-100000@gamplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0202091052570.7793-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Feb 2002, Julian Elischer wrote:
> On Sun, 10 Feb 2002, Bruce Evans wrote:
>
> > On Fri, 8 Feb 2002, Julian Elischer wrote:
> ...
> > > and in userret() and ast()
> > >
> > > >#ifdef DEBUG /*your choice of variable here*/
> > > > if (td->td_ucred != NULL) {
> > > > mtx_lock(&Giant);
> > > > crfree(td->td_ucred);
> > > > td->td_ucred = NULL;
> > > > mtx_unlock(&Giant);
> > > > }
> > > >#endif
> >
> > I think this is better left where it is in the functions that aquire
> > the locks. It can then be done unconditionally, and not in a loop.
>
> AST is not always called
> and userret is always called, but unfortunatly sometimes multiple times
userret() isn't always called either in my version :-). When I'm
finished, it will never be called (but I might rename ast() to userret()
since it is essenttially the unusual case for the original userret()).
> if someone were to clean up AST/userret
> it would be easier, but I am not sure I understand all the issues..
>
> Particularly the interraction between ast() and userret() and the various
> possible ASTs
Logically, it belongs at the end of userret(), but I would prefer it
to be immediately after all calls to userret() like it almost is now
so that I don't have to change it. ast() is not special here, modulo
optimizations -- it is just one caller of userret(). Think of it as
just an optimization of once case of trap().
> > The style of the null pointer check in this is bug for bug compatible
> > with the corresponding one above.
>
> which way would you prefer?
I prefer explicit comparisions with NULL and 0 except for booleans.
Bruce
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?20020210114611.W5212-100000>