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