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:
case ii:
                                x               <- user race lost

case iii:
                                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

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to