6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux
fweimer at redhat.com
Tue Oct 23 09:39:49 UTC 2018
* Thomas Stüfe:
>> The main problem for vfork in application code is that you need to *all*
>> disable signals, even signals used by the implementation. If a signal
>> handler runs by accident while the vfork is active, memory corruption is
>> practically guaranteed. The only way to disable the signals is with a
>> direct system call; sigprocmask/pthread_sigmask do not work.
>> Does your implementation do this?
> I understand. No, admittedly not. But we squeeze the vulnerable time
> window to the minimal possible:
> if (vfork() == 0) exec(..);
> which was a large step forward from the stock Ojdk solution.
> While not completely bullet proof, I saw not a single instance of an
> error in all these years (I understand those errors would be very
> intermittent and difficult to attribute to vfork+signalling, so we may
> have missed some).
Well, such tight races never matter until they suddenly do. I'm always
amazed how races previously thought impossible reproduce reliably with
high probability, given the right circumstances. The highlight so far
was a single-instruction race (not even a data race) in our condition
variable implementation, which broke our iSCSI implementation.
>> > The current posix_spawn() implementation was added to glibc with glibc
>> > 2.24. So, what was the state of posix_spawn() before that version? Is
>> > it safe to use, does it do the right thing, or will we encounter
>> > regressions?
>> It uses fork by default. It can be told to use vfork, via
>> POSIX_SPAWN_USEVFORK, but then it is buggy. For generic JDK code, this
>> seems hardly appropriate.
> Are you sure about this? The coding I saw in glibc < 2.24 was that it
> would use vfork if both attributes and file actions were NULL, which
> should be the case with the OpenJDK and jspawnhelper.
Oh, right. All the more reason to backport the glibc 2.24 change. 8-)
More information about the core-libs-dev