Date: Sun, 11 Nov 2001 10:23:06 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: freebsd-arch@FreeBSD.org
Subject: Re: cur{thread/proc}, or not.
Message-ID: <Pine.BSF.4.21.0111110957150.89663-100000@InterJet.elischer.org>
In-Reply-To: <Pine.NEB.3.96L.1011111101234.11566A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Nov 2001, Robert Watson wrote:
>
> Every now and then, we get to discuss curproc, and its merits. Let's do
> it again.
>
> There are a number of uses of curproc in the netinet code, used to
> retrieve credentials for authorization somewhere down the stack, when no
> proc or thread pointer has been passed down. 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.
> (This is, incidentally, true of many places in the system). As I
> understand it, use of curproc was branded 'undesirable' at some point in
> the semi-distant past, and since that time, a reference to 'proc' has been
> passed down the stack. With a change to KSE, this has been translated to
> references the thread, but the issue remains the same. This comes up in
> particular because I have a tree where I have propagated the thread
> pointer down if_ioctl in the network stack: the normal ioctl call carries
> a thread pointer now, but when it is translated into if_ioctl by the
> network stack, that pointer is lost. This raises the question: should we
> (in practice) be adding process or thread pointers to many more of the
> function arguments, or should we switch to using curproc/curthread
> instead.
I think we should, though there are some cases where it is not clear that
there is always a thread to add other than the base thread of the idle
process. Also, since thread structures in the kernel are only assigned to
a process to do work for the duration of the particular system call
that they are performing, no thread pointer should be stored somewhere
where it may be referenced after the syscall has returned to userland.
In that case the best you can do is a proc pointer.
Also, in SMPng cur{thread,proc} takes some time to get as I'm told that
dereferencing %fs is very slow.. (Not sure how true that is).
>
> The argument I've seen a couple of times for using the proc/thread pointer
> is that of delegation: a kernel thread might be acting on behalf of
> another process, and need a reference to the process so that it can use
> its (file descriptors, credential, address space, ...).
I was worried about this case doing the KSE switchover
but I never actually saw a case where it was obviously doing this...
(though I have my suspicions that it may still happen in some
non-obvious places).
> I suspect that,
> in practice, this is a Bad Idea, given the increased complexity of
> fine-grained threading/locking and SMPng. "borrowing" references in such
> an environment seems like a recipe for buginess, and instead such
> references should be "given" by the thread that obeys the
> locking/reference counting, and should not be done at the level of the
> proc. For example, for a credential, you would simply grab another
> reference to the credential and pass off the reference, rather than
> sharing a reference. In fact, it seems that in a lot of places where a
> struct proc is passed in, the implicit assumption of the code is that this
> is the "current process", and as we add more process-related locking, that
> assumption will probably only grow stronger, so as to not raise lock order
> issues.
There are other reasons for needing the pointer than for a credential.
For example in AIO, the process pointer is stored so that
address space can be loaned to the aio threads to do the IO.
>
> 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 have thought about this both ways...
both have advantages. In some architectures, getting curthread might
be very expensive.
Removing the proc pointers would take us back where we were before BSD4.4
(anyone know if Kirk is on this list?)
>
> (1) 'suser' would always use 'curthread', and lose its proc/thread
> argument (proc in the main tree, thread in my tree). 'suser_cred'
> would be used for delegation situations (as is the case in my tree).
>
> (Note that this remains incompatible with other platforms, which
> generally accept a cred argument for 'suser', including other *BSD and
> Solaris.)
>
> (2) proc/thread arguments would (in general) be removed (gradually) from
> the arguments of many existing kernel functions, and
> 'curproc'/'curthread' would be used instead. For example, in the
> 'VOP_*' interface, use of the 'p' or 'td' entries would be abandoned,
> and 'cred' would be more widely passed down (such as into open).
>
> (Note that this is the path taken by a number of other fine-grained
> UNIX kernels, including Solaris, IRIX, et al).
>
> (3) Use of 'curproc' would be removed in a number of places, where
> abstracted functions such as 'suser' would invoke curthread instead.
I believe it was an early move to start
to prepare for some sort of SMP work
where they couldn't think of an architecture neutral
way of getting 'curthread' that was guaranteed to be efficient
everywhere.
>
> It seems to me that unless a very strong argument exists against using
> curproc/curthread (and I don't preclude one existing), using them would
> actually be an improvement, as it would assert that this class of
> 'borrowing' couldn't exist, simplifying the kernel, not to mention
> squeezing a bit more stuff out of the stack (which, at ten levels deep,
> actually begins to add up on 64-bit machines). I believe that there are
> many places where the 'p' passed in is implicitly assumed to be the
> current process, and that making that reliance explicit would be an
> improvement, rather than a problem.
>
> Flames appreciated.
I think you'll get few flames..
but probably a lot of silence froma many people.
>
> Robert N M Watson FreeBSD Core Team, TrustedBSD Project
> robert@fledge.watson.org NAI Labs, Safeport Network Services
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
>
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?Pine.BSF.4.21.0111110957150.89663-100000>