Date: Thu, 18 Jul 2002 18:35:55 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: current@FreeBSD.org Subject: Re: Questions about kern_descrip.c Message-ID: <XFMail.20020718183555.jhb@FreeBSD.org> In-Reply-To: <200207182117.g6ILHuFr020395@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18-Jul-2002 Matthew Dillon wrote: > >:>:-- >:>: >:>: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. 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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.20020718183555.jhb>