Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code

[Martin Buchholz]

You could operate in paranoid mode and do *both* : use O_CLOEXEC and use
fcntl to set the bit after creating it, perhaps after verifying via fcntl
whether the bit was successfully set by open.

Martin

On Thu, Jan 31, 2013 at 12:07 PM, Dan Xu <dan.xu at oracle.com> wrote:

> Hi Karen,
>
> In my opinion, it is recommemded to use O_CLOEXEC flag directly in open()
> function than setting it later via fcntl(). And according to the man page
> on Solaris and Mac, open() behaves the same on those platforms.
>
> I only find the support platform list for jdk7 at http://www.oracle.com/**
> technetwork/java/javase/**config-417990.html<http://www.oracle.com/technetwork/java/javase/config-417990.html>.
> Because Linux 2.6.23 was released long ago on Oct 9, 2007, most platforms
> should already have the support to O_CLOEXEC flag.
>
> Thanks,
>
> -Dan
>
>
>
> On 01/31/2013 07:30 AM, Karen Kinnear wrote:
>
>> Dan,
>>
>> I had a question on this comment.
>>
>> Should we fix this in hotspot?
>>
>> So you mention recent Linux open() documentation.
>> How does this behave on Solaris and Mac? I assume the library code is
>> shared code across platforms.
>> Also - what is the oldest Linux we support for JDK8?
>>
>> thanks,
>> Karen
>>
>> On Jan 29, 2013, at 6:55 AM, Alan Bateman wrote:
>>
>>
>>>
>>>>
>>>>> - I don't think the O_CLOEXEC code is needed in handleOpen, was this
>>>>> copied from HotSpot?
>>>>>
>>>> In the original hotspot code, it has one section to enable the
>>>> close-on-exec flag for the new file descriptor as the following.
>>>>
>>>>            #ifdef FD_CLOEXEC
>>>>                {
>>>>                    int flags = ::fcntl(fd, F_GETFD);
>>>>                    if (flags != -1)
>>>>                        ::fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
>>>>                }
>>>>            #endif
>>>>
>>>> According to the comment, "All file descriptors that are opened in the
>>>> JVM and not specifically destined for a subprocess should have the
>>>> close-on-exec flag set.  If we don't set it, then careless 3rd party native
>>>> code might fork and exec without closing all appropriate file descriptors
>>>> (e.g. as we do in closeDescriptors in UNIXProcess.c), and this in turn
>>>> might:
>>>>     - cause end-of-file to fail to be detected on some file
>>>> descriptors, resulting in mysterious hangs, or
>>>>     - might cause an fopen in the subprocess to fail on a system
>>>> suffering from bug 1085341."
>>>>
>>>> And the recent open() function (since Linux 2.6.23) already has
>>>> O_CLOSEXEC flag to enable this flag by default. And it is a preferred way
>>>> according to the man page, " Specifying this  flag  permits  a program  to
>>>>  avoid  additional fcntl(2) F_SETFD operations to set the FD_CLOEXEC flag.
>>>>  Addi-tionally, use of this flag is essential in some multithreaded
>>>> programs since using a separate fcntl(2)  F_SETFD  operation to set the
>>>> FD_CLOEXEC flag does not suffice to avoid race conditions where one thread
>>>> opens a file descriptor at the same time  as  another  thread  does  a
>>>> fork(2) plus execve(2).
>>>> Additionally, if O_CLOEXEC is not supported, F_DUPFD_CLOEXEC is
>>>> preferred than FD_CLOEXEC, which is what hotspot is using right now.
>>>>
>>> I don't think we need this because the file descriptor will be closed at
>>> exec time anyway (there is logic in Runtime.exec to iterate over the file
>>> descriptors and close them). Also we don't do this in other areas of the
>>> platform where we use open directly.
>>>
>>>
>>>>
>>
>