threads/79887: [patch] freopen() isn't thread-safe

[Daniel Eischen]

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?

-- 
DE