RFR: 8294003: Don't handle si_addr == 0 && si_code == SI_KERNEL SIGSEGVs

[Stefan Karlsson]

On Mon, 19 Sep 2022 12:33:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We have this code code in our signal handler:
> 
> 
> #ifndef AMD64
>     // Halt if SI_KERNEL before more crashes get misdiagnosed as Java bugs
>     // This can happen in any running code (currently more frequently in
>     // interpreter code but has been seen in compiled code)
>     if (sig == SIGSEGV && info->si_addr == 0 && info->si_code == SI_KERNEL) {
>       fatal("An irrecoverable SI_KERNEL SIGSEGV has occurred due "
>             "to unstable signal handling in this distribution.");
>     }
> #endif // AMD64
> 
> 
> This bug added that change:
> https://bugs.openjdk.java.net/browse/JDK-8004124
> 
> In the Generational ZGC we hit the exact same condition whenever we try to (incorrectly) dereference one of our colored pointers. From the bug above:
> 
> "A segmentation violation that occurs as a result of userspace process accessing virtual memory above the TASK_SIZE limit will cause a segmentation violation with an si_code of SI_KERNEL"
> 
> That is, if we have set high-order bits (past the TASK_SIZE limit), we get these kind of SIGSEGVs.
> 
> As the signal handle code is written today, we don't "stop" this signal, and instead try to handle it as an implicit null check. This causes hard-to-debug error messages and crashes in code that incorrectly try to deoptimize the faulty code.
> 
> I propose that we short-cut the signal handling code, and let this problematic SIGSEGV get passed to VMError::report_and_die.
> 
> We've been running with this patch in the Generational ZGC repository for over a year, without any problems.

Oracle doesn't build and test 32-bit versions anymore, so I can't effectively try to verify if this is needed or not. I wouldn't mind if someone else takes ownership of investigating if this is still needed for 32-bits.

-------------

PR: https://git.openjdk.org/jdk/pull/10340