Date: Mon, 11 Feb 2002 16:15:26 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: jhb@freebsd.org, bde@freebsd.org, current@freebsd.org Subject: Re: ucred holding patch, BDE version Message-ID: <20020212021251.06D959F40C@okeeffe.bestweb.net>
next in thread | raw e-mail | index | archive | help
On Mon, 11 Feb 2002, Alfred Perlstein wrote: > * Julian Elischer <julian@elischer.org> [020211 15:00] wrote: > > In the current world, when the thread enters userland, it does: > > > > lock giant > > crfree() (which includes mutexes) > > unlock giant > > This isn't needed afaik. Argue with jhb. > > > if there are ASTs it does this once again for each AST waiting as well. > > > > And on the way into the system it does: > > lock process > > crhold() (which includes mutex ops) > > unlock process > > This isn't needed, at least afaik. see below. > > > so if there is a single AST (not uncommon) it does on a system call, 4 to > > 6 locks and 4 to 6 unlocks just to get a reference on the ucred it already > > had a reference on. By not freeing it when going to userland, and checking > > if it is the right one when returning to the kernel, we replace that with > > a pointer comparison (well maybe 2) 99.999% of the time. > > > > John still wants to free it if INVARIANTS is on so he canh trap on > > inapropriate access. I'm not sure it's needed but am willing to do so.. > > This makes little sense to me. > > Maybe I'm missing something, but by virtue of ownership we don't > have to worry about the ucred's refcount on entry into the kernel > because it is the owner and no one else is allowed to change our > privledges besideds ourselves via set[ug]id(). multiple threads can do it.. The proclock is needed to get the reference, guarding against other threads, and giant is needed fo rnot to free it because if it reaches a refcount of 0 it needs to call free(). (which john assures me needs Giant at this time). We could avoid the proclock with judicious use of an atomic refcount incrementing method. When Giant goes away it won't be so bad but it will STILL be quicker to not drop it across userland. > > Therefore the additional hold on entry is completely useless no > matter what and with that the release on exit is also useless. > > -Alfred > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message 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?20020212021251.06D959F40C>