Date: Tue, 7 Dec 2010 14:40:12 GMT From: John Baldwin <jhb@freebsd.org> To: freebsd-threads@FreeBSD.org Subject: Re: threads/79887: [patch] freopen() isn't thread-safe Message-ID: <201012071440.oB7EeCk5018511@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR threads/79887; it has been noted by GNATS.
From: John Baldwin <jhb@freebsd.org>
To: bug-followup@freebsd.org,
tejblum@yandex-team.ru
Cc: David Xu <davidxu@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012071440.oB7EeCk5018511>