Date: Tue, 9 Oct 2001 15:03:39 -0500 From: Alfred Perlstein <bright@mu.org> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: ucred API Message-ID: <20011009150339.X59854@elvis.mu.org> In-Reply-To: <XFMail.011009112923.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Tue, Oct 09, 2001 at 11:29:23AM -0700 References: <XFMail.011009112923.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011009150339.X59854>