On 18-Jul-2002 Matthew Dillon wrote: > >: >: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.
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/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
