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: bug-followup at freebsd.org,
 tejblum at yandex-team.ru
Cc: David Xu <davidxu at freebsd.org>
Subject: Re: threads/79887: [patch] freopen() isn't thread-safe
Date: Tue, 7 Dec 2010 09:31:36 -0500

 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.
 
 -- 
 John Baldwin