Date: Wed, 8 Dec 2010 02:50:06 GMT From: David Xu <davidxu@freebsd.org> To: freebsd-threads@FreeBSD.org Subject: Re: threads/79887: [patch] freopen() isn't thread-safe Message-ID: <201012080250.oB82o6X5072936@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: David Xu <davidxu@freebsd.org>
To: John Baldwin <jhb@freebsd.org>
Cc: bug-followup@freebsd.org, tejblum@yandex-team.ru
Subject: Re: threads/79887: [patch] freopen() isn't thread-safe
Date: Wed, 08 Dec 2010 10:43:35 +0800
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012080250.oB82o6X5072936>