priv_check: check against alternative td?

[Robert Watson]

On Wed, 7 Apr 2010, Xin LI wrote:

> It looks like that we have:
>
>        KASSERT(td == curthread, ("priv_check: td != curthread"));
>
> In priv_check().  I'm wondering why we need this assertion?  i.e.  why don't 
> we just do priv_check(int priv) and use curthread instead?

Historically, we did allow it, and in principle, we could allow it again.  In 
most cases, it's not safe, but there are also (in theory) plenty where it is. 
Since it wasn't obvious to me that we might not want that in the future, I 
chose to leave the KPI the way it was, rather than cause every consumer piece 
of kernel code, kernel module, etc, change, and provide this safety belt.  My 
current belief is that there's not a strong motivation to cause further 
massive KPI disruption (there are a lot of callers), so I think we should 
leave it as it is.

FWIW, some other systems make a different design choice there (IRIX, for 
example).

Robert