Replacing syscall(_NR_fork) on linux with syscall(_NR_clone) (original) (raw)

David Holmes david.holmes at oracle.com
Tue Apr 14 05:57:46 UTC 2015

On 11/04/2015 12:19 AM, Martin Buchholz wrote:

_At Google, we also had trouble with syscall(NRfork). We switched to simply calling fork despite the ominous warnings and have had no trouble since. We avoid calling clone - see my old failures with it in UNIXProcessmd.c. Although if we follow the successful precedent of UNIXProcessmd.c we should call vfork instead, but we haven't yet had the need.

Thanks Martin. As per my reply to Thomas I think following the path you've already trod seems the simplest short-term approach.

David

@@ -6012,8 +6689,15 @@ // separate process to execve. Make a direct syscall to fork process. // On IA64 there's no fork syscall, we have to use fork() and hope for // the best... _- pidt pid = NOTIA64(syscall(NRfork);) - IA64ONLY(fork();) _+ // pidt pid = NOTIA64(syscall(NRfork);) + // IA64ONLY(fork();) + + // Google Specific: Changing the above code to use the fork glibc call in + // NOTIA64. This allows the successful execution of the fork in a case where + // the previous syscall hung and hence allows successful OOM exit. + // We believe that fork() is now async-safe and suspect the above note about + // pthreadatfork handlers and resetting the pthread library is outdated. + pidt pid = fork(); if (pid < 0) {_ _// fork failed_ _@@ -6029,10 +6713,16 @@_ _// in the new process, so make a system call directly._ _// IA64 should use normal execve() from glibc to match the glibc_ _fork()_ _// above._ _- NOTIA64(syscall(_NRexecve, "/bin/sh", argv, environ);)_ _- IA64ONLY(execve("/bin/sh", (char* const*)argv, environ);)_ _+ // NOTIA64(syscall(_NRexecve, "/bin/sh", argv, environ);)_ _+ // IA64ONLY(execve("/bin/sh", (char* const*)argv, environ);)_ _+_ _+ // Google Specific: Based on fork case above changed this code to_ _use execve_ _+ // glibc call in NOTIA64 case._ _+ execve("/bin/sh", (char* const*)argv, environ);_ _// execve failed_ _+ tty->printcr("execve of OnError command "/bin/sh -c %s" failed with errno %d: %s", + cmd, errno, strerror(errno)); exit(-1); } else {

On Fri, Apr 10, 2015 at 12:47 AM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> wrote: In os::forkandexec we provide a per platform fork/exec implementation for use by the OnError and OnOutOfMemory JVM options. On linux this is implemented with direct syscalls to NRfork (sysfork) and NRexecve. We already encountered a problem on linux-sparc: http://mail.openjdk.java.net/_pipermail/hotspot-runtime-dev/_2015-February/013811.html <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-February/013811.html> due to a different register usage for the return value, which is so far restricted to the 7u train but will need addressing in 8u and 9. Further it seems that the fork syscall has actually been deprecated for quite some time and we are now seeing kernels on some platforms which are no longer providing any of the deprecated syscalls - we simply get an error ENOSYS. The fork() library was updated to use clone a long time ago, but as I understand it we can't use the fork() library call because we might be executing in a signal-handling context within the error handler. So I'm considering switching to use the clone syscall for all linux systems. Thoughts/comments? David

More information about the hotspot-dev mailing list