Date: Wed, 08 Dec 2010 12:08:10 +0800 From: David Xu <davidxu@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: threads/79887: [patch] freopen() isn't thread-safe Message-ID: <4CFF04AA.6060905@freebsd.org> In-Reply-To: <Pine.GSO.4.64.1012072245570.20951@sea.ntplx.net> References: <201012080250.oB82o6X5072936@freefall.freebsd.org> <Pine.GSO.4.64.1012072245570.20951@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > On Wed, 8 Dec 2010, David Xu wrote: > >> John Baldwin wrote: >> > David, >> > >> > I think the submitter's analysis is correct that the only place that >> can set >> > the close function pointer is funopen() and that for that case (and >> any other >> > "fake" files), the file descriptor will be -1. If the fd is >= 0, >> then it >> > must be a file-descriptor-backed FILE, and relying on dup2() to >> close the fd >> > is ok. >> > >> > As the manpage notes, the most common usage is to redirect stderr or >> stdout by >> > doing 'freopen("/dev/null", "w", stderr)'. The bug allows some >> other random >> > code that is calling open() in another thread to have that open() >> return 2 >> > during the window where fd '2' is closed during freopen(). That >> other file >> > descriptor then gets trounced by the dup2() call in freopen() to >> point to >> > something else. >> > >> > The code likely uses _close() rather than close() directly to be >> cleaner. >> > Given that this is stdio, I don't think we are really worried about the >> > performance impact of one extra wrapper function. >> > >> > I think the original patch is most likely correct. >> > >> >> The patch works, I just don't like the design of the >> (*fp->_close)(fp->_cookie) >> it seems the patch make freopen bypass it. >> I think the patch can be committed, but I am busy and have >> no time to do it by myself. > > I can do it, but will be away on vacation until later next > week. If you want to wait, I can commit it. > > Would you like to replace the (*fp->_close)(fp->_cookie) > with just _close(fp->_file) as you suggest in one of your > followups? > Thanks, I think you can keep it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CFF04AA.6060905>