From owner-freebsd-arch Tue Oct 9 15:43:25 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id AF12D37B403 for ; Tue, 9 Oct 2001 15:43:22 -0700 (PDT) Received: (qmail 16746 invoked from network); 9 Oct 2001 22:43:22 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Oct 2001 22:43:22 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011009150339.X59854@elvis.mu.org> Date: Tue, 09 Oct 2001 15:42:48 -0700 (PDT) From: John Baldwin To: Alfred Perlstein Subject: Re: ucred API Cc: arch@FreeBSD.org 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 On 09-Oct-01 Alfred Perlstein wrote: > * 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. No, it's not. Otherwise I have to lock the process to get a new reference to a ucred to keep it from not changing out from under me since another thread could change the ucred on another CPU. By using a thread reference, I don't have to use locks except for at the beginning of the syscall when I get the initial reference. > You only need to reference the cred when a thread is created. No. If thread A changes the ucred and later on thread B executes a syscall, it should use the new cred. > In terms of KSE, what I think that means when you'd block leaving a > context (lazy thread creation) you'd do your dup. Think of an SMP system where one thread is reading from a file while another is changing the groups, etc. Granted, that is a userland race that userland needs to handle, but we at lesat have to keep the kernel data structures from getting hosed by userland races. -- John Baldwin -- 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