: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.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to