On 18-Jul-2002 Matthew Dillon wrote: > >:>:-- >:>: >:>: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. >: >:But it doesn't really matter if we cycle the lock. What I described >:is the current behavior, btw. >: >:-- >: >:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > > Well, the original code for dup2() looped to ensure that the > source descriptor number was still a valid descriptor. Why > the dup() code doesn't do this I'm not sure, but I think it > needs to. If you cycle the locks and do not retry, someone else > could get in and close() the source descriptor and dup2() will > not return an error when it should. > > Also, do_dup() assumes that the source descriptor is non-NULL. > If dup2() (and dup()) do not retry then do_dup() can wind up > getting called with fd_ofiles[old] NULL (race against another > thread close()ing or dup2()ing over the original descriptor). > > If I remember right, a dup2()/dup2() race was one of the problems > being explicitly solved by this commit.
Okies, I'll look at this some more. We might need to move the loop into do_dup(), or have do_dup() do an additional check. -- 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
