threads/79887: [patch] freopen() isn't thread-safe
David Xu
davidxu at freebsd.org
Wed Dec 8 04:08:11 UTC 2010
Daniel Eischen wrote:
> 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?
>
Thanks, I think you can keep it.
More information about the freebsd-threads
mailing list