Date: Thu, 07 Feb 2002 22:25:48 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@freebsd.org, Julian Elischer <julian@elischer.org> Subject: Re: ucred for threads Message-ID: <3C636F6C.96506043@mindspring.com> References: <XFMail.020207230331.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > No, an unlocked compare is _not_ ok. What if the p_ucred pointer was changed > on some other processor by another thread from this processor? I saw your response to Julian... I understand the concern, but I think it's unfounded. Let me explain. > Without a lock > you don't have a guarantee that that other processor's writes are visible to > you. We really don't want to be using stale credentials for syscalls given the > past history of race conditions involving credentials. If in the future it is > deemed that getting a stale cred is an acceptable race, then this can be > optimized then, but for now we had better get it right. There's "stale" and there's "Stale". I thnk "stale" is OK. Here's how I see it: If there's a race between changing and using a cred in kernel space, it can only come about because of a similar race in user space. This means that if I change from cred A to cred B, there's no difference in the closure between losing the race in the kernel (and getting a stale value) and losing the race in user space (and getting a stale value). Basically, if it's an issue, then user level primitives have to be used to protect the request for the credential change. Maybe a picture would be better: Threads Creds 1 2 A B case i: setuid x------>x create x case ii: setuid create x <- user race lost x------>x case iii: setuid x------>x create x <- stale > FreeBSD doesn't run on just the i386 anymore, we have Alpha, ia64, and sparc64 > SMP machines to deal with as well. I understand; I'm very noisy about this point myself, e.g. the recent binutils breakage that made Alpha not build at all. However, I'm not convinced that it's possible to have the kernel race be present, without a corresponding user race, which means protecting against "case iii" doe nothing for you, if you can still get the inversion from "case ii". If, on the other hand, you have user space synchornization that guards against "case ii", then the fact that the synchornization operates across the same barrier as the credential change call means that the you also protect against "case iii". Are there any obvious cases that I'm just not seeing here where a "case iii" is possible without a "case ii"? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C636F6C.96506043>