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

Reply via email to