Messages in this thread | | | From | Oliver Neukum <> | Subject | Re: [RFC] Race condition? | Date | Fri, 2 Aug 2002 20:45:46 +0200 |
| |
Am Freitag, 2. August 2002 19:37 schrieb Dave Hansen: > Oliver Neukum wrote: > > Am Freitag, 2. August 2002 15:46 schrieb Kasper Dupont: > >>Is there a race condition in this piece of code from do_fork in > > > > It would seem so. Perhaps the BKL was taken previously. > > Even if it was, I doubt the code ever knowingly relied upon it. If I > know that I'm protected under a lock, I rarely go to the trouble of > atomic operations.
That depends on where else you need these variables.
> 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.
IMHO you should add a spinlock to user_struct and take it. A clear solution that doesn't hurt the common case.
Regards Oliver
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |