:> The issue with dup2() was a race against open() or close()
:> I believe, where dup2() could potentially dup into a
:> descriptor that open() was about to use. Unfortunately, it
:> does appear that dup() has the same issue.
:>
:> fdalloc() does not reserve the descriptor number it
:> returns, it simply finds a free slot and says 'this
:> index is a free slot'. Even in the latest -current,
:> fdalloc() releases the fdp lock when it goes to
:> MALLOC so the race appears to still be present.
:
:Well, execpt that if we malloc(), we then grab the lock and loop
:again. If we return without an error, it means we reserved a slot
:while holding a lock and returned with the lock still held.
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
Yes, that makes sense... and it would be fairly trivial
optimization to make. I suppose you could have fdalloc()
return EAGAIN or something like that to indicate that
it had to cycle the lock.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
