[11u] RFR(S): 8223266: PPC64: Check for branch to illegal address before checking for mem serialization
goetz.lindenmaier at sap.com
Mon May 6 07:09:49 UTC 2019
> > Looking at the issue:
> > actually the current VM would think the signal is a
> > memory serialization and return true, while it is
> > a real crash? (Or a simulated one as in the test?)
> is_memory_serialization() never returns, so the VM never knows if it's
> indeed a memory serialization case or not.
> Because the issue on some old kernels forbids us to rely on 'si_addr' we
> are inspecting the instruction at 'pc' to extract the registers used in
> the instruction to determine the actual faulty address before calling
> os::is_memory_serialize_page(), similarly to what we do to dertermine the
> faulty address in get_stack_bang_address().
> In doing it's assumed that SIGSEGV can only be caused due to a load/store
> (Data Storage Interrupt), because it assumes it's always possible to read
> the instruction at 'pc'. This is not true, particularly for a SIGSEGV due
> to a branch to an invalid address (e.g. not mapped / no permission to
> read/exec address), which is generated due to Instruction Storage Interrupt
> (ISI). Hence we can use the interruption type (passed in 'trap' member to
> the signal handler) to discern when it's possible to inspect the 'pc' (DSI)
> and when it's not possible (ISI).
> The test case 13 precisely stresses that case of branching to an invalid
> address by forcing a function bad pointer = 0xf and calling it (on PPC64
> that crash shows pc=0xc in the hs_err log due to the code alignment
> requirements for execution).
> So the additional code block checking for SIGSEGV related to UseMemBar
> feature on 11u needs to be adapted like the previous block using
> get_stack_bang_address(), which is already fixed on jdk/jdk tip.
Thanks for the detailed explanation! Our tests are green, too.
You can push to jdk11u-dev once the bug gets the jdk11u-fix-yes tag.
More information about the jdk-updates-dev