Date: Tue, 09 Oct 2001 15:42:48 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <bright@mu.org> Cc: arch@FreeBSD.org Subject: Re: ucred API Message-ID: <XFMail.011009154248.jhb@FreeBSD.org> In-Reply-To: <20011009150339.X59854@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09-Oct-01 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. 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 <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011009154248.jhb>