Date: Tue, 9 Oct 2001 14:33:06 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Alfred Perlstein <bright@mu.org> Cc: John Baldwin <jhb@FreeBSD.org>, arch@FreeBSD.org Subject: Re: ucred API Message-ID: <Pine.BSF.4.21.0110091416500.27416-100000@InterJet.elischer.org> In-Reply-To: <20011009150339.X59854@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
errr, Alfred.. The kernel "thread" structure is only valid when the user thread "dips" into the kernel.. The more threads "dip" into the kernel (e.g. do syscalls,) the more kernel threads are created to run on their behalf. Thus strictly speaking kernel thread structures only last for the lifetime of a syscall. (in practice they are cached but theoretically they are freed and reallocated). Since there may be many syscalls outstanding, each works with the creds that existed at the moment when it was invoked. On Tue, 9 Oct 2001, Alfred Perlstein wrote: > * John Baldwin <jhb@FreeBSD.org> [011009 13:30] wrote: > > Hey all. I'd like to make the following changes to the ucred API in the > > interests of making the locking more sane. The changes will occur in 2 stages. > > Stage 2: > > - Add a per-thread reference to the ucred that is created on syscall > > entry and released on syscall exit. It is also created and released > > if needed on trap enter/exit. It is _not_ created for interrupts since > > interrupts should not care about the ucred of their borrowed context. > > The per-thread ucred reference will then point to a ucred that won't > > ever change (setuid, etc. update the per-process ucred) and thus won't > > need any locking. Almost all references to ucreds for suser(), VOP's > > etc. will use the thread reference. This will ensure that a thread's > > ucred will be the same for an entire syscall which will close many > > races involving multithreaded programs and ucreds. The only place where > > the per-process ucred will be used for access checks is places that > > modify the ucred as we want to ensure there is no race of one thread > > making a credential change it isn't qualified to make due to it performing > > its access checks on a stale ucred before updating the master ucred. > > > > I've talked with Robert Watson about these already and they sound good to him. > > Any objections? > > Stage 2 is bogus. > > You only need to reference the cred when a thread is created. > > In terms of KSE, what I think that means when you'd block leaving a > context (lazy thread creation) you'd do your dup. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > > 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.0110091416500.27416-100000>