From owner-freebsd-arch Tue Oct 9 13: 3:42 2001 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 9C91537B401; Tue, 9 Oct 2001 13:03:39 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id A0B8C81D01; Tue, 9 Oct 2001 15:03:39 -0500 (CDT) Date: Tue, 9 Oct 2001 15:03:39 -0500 From: Alfred Perlstein To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: ucred API Message-ID: <20011009150339.X59854@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Tue, Oct 09, 2001 at 11:29:23AM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * John Baldwin [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