Date: Thu, 18 Jul 2002 14:17:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Questions about kern_descrip.c Message-ID: <200207182117.g6ILHuFr020395@apollo.backplane.com> References: <XFMail.20020718161925.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>:-- :>: :>:John Baldwin <jhb@FreeBSD.org> <>< 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 <jhb@FreeBSD.org> <>< 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. -Matt Matthew Dillon <dillon@backplane.com> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207182117.g6ILHuFr020395>