Date: Mon, 12 Nov 2001 15:08:36 -0800 (PST)
From: John Baldwin <jhb@FreeBSD.org>
To: Terry Lambert <tlambert2@mindspring.com>
Cc: freebsd-arch@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>
Subject: Re: cur{thread/proc}, or not.
Message-ID: <XFMail.011112150836.jhb@FreeBSD.org>
In-Reply-To: <3BF05241.74F895EF@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12-Nov-01 Terry Lambert wrote: > Robert Watson wrote: >> With the eventual addition >> of td->td_ucred, it will be desirable to use the credential for the >> current thread, rather than the proc, which will require locking to use. > > I think locking credential instances is bad. No, he's not locking credentials, he would be locking the process to avoid having the credential change out from under him. However, this won't be needed in most cases since each thread has a read-only reference to the process credential. (When the process changes credentials, the references of other threads force it to duplicate its current cred into a new one before making the change.) > If so, then no locking is required, since the LCK CMPXCHG can > be utilized to do atomic increment and decrement on the > reference counting, without needing locks. Except that people keep complaining about using atomic ops for ref counts, however that can be done later as an optimization. Regarding object credentials, I agree, and I thought that this was how things were already performed. >> I don't pretend to have a grasp of all the issues here, so the purpose of >> this message is to raise the issues so that I can understand them. I have >> a tree where I've eliminated many references to curproc; however, I'm now >> wondering if it wouldn't simply be more useful to eliminate many of the >> references to struct proc in the function arguments, and use curproc >> instead, and add references to ucred (and related ref-counted structures) >> as needed for delegation types of situations. In particular, that would >> suggest the following changes: > > I think this is the wrong direction, but if you wanted to do this, > I think that you would need to put the cur* symbols into the per > CPU private pages. This is problematic in the extreme, because it > means that you must set these values each time going down, in order > to be able to substitute a per CPU global for the stack reference. Errr, Terry. Where do you think curthread/curproc lives now? It's _already_ in a per-CPU page. We set curthread/curproc on each context switch. > I would much rather that the credentials be object referenced off > of non-process, non-thread objects, based on whatever the correct > scoping really is, for the security model you want to enforce. My > "accept" example is only one of a class of changes that could > facilitate this. I agree with this. I think Robert's question wasn't just about socket credentials however, his question was why pass a proc pointer (or thread poiter) all the way down the stack that is implicitly assumed to be curproc/curthread in several places instead of just using curproc/curthread which your only response seems to be to suggest that we "change" to doing something that we already do. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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.011112150836.jhb>