:
:In revision 1.94 of kern_descrip.c, in the dup2() syscall a goto
:retry loop was added so that if we did a fdalloc() we always retested
:everything. Since fd_nfiles can't shrink and new and old can't
:change, I don't see why the loop is necessary. Neither dup() or
:the F_DUPFD fcntl() were modified in this way either. Also,
:calling fdalloc() in this case is somewhat bogus, because fdalloc()
:is going to try and reserve an open slot and update variables such
:as fd_lastfile, etc. appropriately. Perhaps we should have an
:fdextend() function that both dup2() and fdalloc() call? Also,
:in do_dup() you have commented out the call to munmapfd() on an
:open file with UF_MAPPED and never turned it back on. Was that
:intentional or just an accidental oversight?
:
:--
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
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.
the munmap descriptor junk is obsolete and has not been used
for a very long time.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
