Re: [RFC] Race condition?

[Dave Hansen]

Oliver Neukum wrote:
>>The root of the problem is that the reference count is being relied on
>>for the wrong thing.  There is a race on p->user between the
>>dup_task_struct() and whenever the atomic_inc(&p->user->__count)
>>occcurs.   The user reference count needs to be incremented in
>>dup_task_struct(), before the copy occurs.
> 
> I don't get you. The user_struct can hardly go away while we are
> forking.

Good point.  I was figuring that it could disappear when the task 
clearly can't be exiting or setuid'ing while forking.

> IMHO you should add a spinlock to user_struct and take it.
> A clear solution that doesn't hurt the common case.

That _is_ a pretty clear solution.  It looks like there are grand 
plans for struct user, so it might come in handy in the future.  But, 
a spinlock _will_ hurt the common case.  With the atomic incs, we have 
2 of them in the common case and, at most, 4 in the failure case. 
Adding a spinlock will require more lock instructions, which are the 
most costly operations in either a spinlock or atomic op.

Either of these are _incredibly_ small prices to pay in any case. 
Forks are slow anyway.  A spinlock would be just fine with me.
-- 
Dave Hansen
[e-mail]