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

[John Baldwin]

The following reply was made to PR threads/79887; it has been noted by GNATS.

From: John Baldwin <jhb at freebsd.org>
To: David Xu <davidxu at freebsd.org>
Cc: bug-followup at freebsd.org,
 tejblum at yandex-team.ru
Subject: Re: threads/79887: [patch] freopen() isn't thread-safe
Date: Wed, 8 Dec 2010 10:03:34 -0500

 On Tuesday, December 07, 2010 9:43:35 pm 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.
 
 Actually, the freopen() code honors custom _close() routines earlier when it
 checks for _file being < 0.  I do really think this is ok.  _close() is not
 public, it is only allowed to be set via funopen().  We also need the dup2()
 change to effectively implement this function's rationale, which is a way to
 redirect stdin, stdout, and stderr.
 
 I will take care of committing this today, with an extra bit of comment.
 
 -- 
 John Baldwin