From gromero at linux.vnet.ibm.com Fri Mar 22 15:29:03 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 22 Mar 2019 12:29:03 -0300 Subject: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address Message-ID: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> Hi, Please, could I get reviews for the following change: bug : https://bugs.openjdk.java.net/browse/JDK-8220794 webrev: http://cr.openjdk.java.net/~gromero/8220794/v1/ It fixes the JVM signal handler on Linux / PPC64 when a SIGSEGV generated by a branch to an illegal/invalid address (not mapped address, address with no executable flags, etc) is caught by the JVM signal handler. Currently the signal handler does not handle that case correctly and the JVM crashes silently. That issue was reported by Goetz (SAP). Thanks for reporting the issue, Goetz. Thank you. Best regards, Gustavo From gromero at linux.vnet.ibm.com Fri Mar 22 16:15:14 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 22 Mar 2019 13:15:14 -0300 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian Message-ID: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> Hi, Please, could I get reviews for the following change? bug : https://bugs.openjdk.java.net/browse/JDK-8221175 webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ It fixes the way a function pointer is defined in order to call a bad function at address 0xF (controlled crash case 13) on PPC64 big-endian machines. On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates function pointers to part of a function descriptor, at offset 0 [1]. Currently the SIGISEGV being generated by case 13 is incorrect because if a function descriptor is not use to call the bad function address the program segfaults before effectively calling the function, when trying to load the (bad) function pointer from offset 0 of base address 0xF, so before branching to the function. It does not affect PPC64 little-endian machines because by default ABI ELFv2 is used (instead of ABI ELFv1) and for that ABI no function descriptor is defined / employed. The fix consists in defining properly a function descriptor with a bad function at offset 0 (the following offset are no important in that case) and using that function descriptor to call the bad function, only on PPC64 big-endian machines. That issue was found when investigating the JDK-8220794 issue [2]. Thank you. Best regards, Gustavo [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES [2] https://bugs.openjdk.java.net/browse/JDK-8220794 From thomas.stuefe at gmail.com Fri Mar 22 17:18:15 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 22 Mar 2019 18:18:15 +0100 Subject: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address In-Reply-To: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> References: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> Message-ID: Hi Gustavo, Just a question, is the other case where we replace si_addr with address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc); really needed? Since we use si_addr in a number of places and I always assumed that just works like on every other posix system. E.g. we use it for assertion poison page handling or handling of secondary crashes during error reporting, see handle_assert_poison_fault(). Cheers, Thomas On Fri, Mar 22, 2019 at 4:29 PM Gustavo Romero wrote: > Hi, > > Please, could I get reviews for the following change: > > bug : https://bugs.openjdk.java.net/browse/JDK-8220794 > webrev: http://cr.openjdk.java.net/~gromero/8220794/v1/ > > It fixes the JVM signal handler on Linux / PPC64 when a SIGSEGV generated > by a branch to an illegal/invalid address (not mapped address, address > with no > executable flags, etc) is caught by the JVM signal handler. Currently the > signal > handler does not handle that case correctly and the JVM crashes silently. > > That issue was reported by Goetz (SAP). Thanks for reporting the issue, > Goetz. > > Thank you. > > Best regards, > Gustavo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ChrisPhi at LGonQn.Org Fri Mar 22 18:05:55 2019 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Fri, 22 Mar 2019 14:05:55 -0400 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> Message-ID: Hi On 2019-03-22 12:15 p.m., Gustavo Romero wrote: > Hi, > > Please, could I get reviews for the following change? > > bug?? : https://bugs.openjdk.java.net/browse/JDK-8221175 > webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ > > It fixes the way a function pointer is defined in order to call a bad > function > at address 0xF (controlled crash case 13) on PPC64 big-endian machines. > > On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates function > pointers to part of a function descriptor, at offset 0 [1]. > > Currently the SIGISEGV being generated by case 13 is incorrect because if a > function descriptor is not use to call the bad function address the program > segfaults before effectively calling the function, when trying to load > the (bad) function pointer from offset 0 of base address 0xF, so before > branching to the function. > > It does not affect PPC64 little-endian machines because by default ABI > ELFv2 > is used (instead of ABI ELFv1) and for that ABI no function descriptor is > defined / employed. > > The fix consists in defining properly a function descriptor with a bad > function > at offset 0 (the following offset are no important in that case) and > using that > function descriptor to call the bad function, only on PPC64 big-endian > machines. > > That issue was found when investigating the JDK-8220794 issue [2]. > > Thank you. > > Best regards, > Gustavo > > [1] > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES > [2] https://bugs.openjdk.java.net/browse/JDK-8220794 > > > Looks good, but not a reviewer. Chris From thomas.stuefe at gmail.com Sat Mar 23 20:43:18 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 23 Mar 2019 21:43:18 +0100 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> Message-ID: Hi Gustavo, looks good. Would be nice to cleanly factor function descriptor handling out at some point: we have various pieces, e.g. a struct FunctionDescriptor in assembler_ppc.hpp, a resolve function in os_aix.cpp, now this... also, I believe, on AIX there is a struct FunctionDescriptor in os headers, but I may remember this wrong. But cleanup can be done in a different change. Thanks for fixing! Cheers, Thomas On Fri, Mar 22, 2019 at 5:15 PM Gustavo Romero wrote: > Hi, > > Please, could I get reviews for the following change? > > bug : https://bugs.openjdk.java.net/browse/JDK-8221175 > webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ > > It fixes the way a function pointer is defined in order to call a bad > function > at address 0xF (controlled crash case 13) on PPC64 big-endian machines. > > On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates function > pointers to part of a function descriptor, at offset 0 [1]. > > Currently the SIGISEGV being generated by case 13 is incorrect because if a > function descriptor is not use to call the bad function address the program > segfaults before effectively calling the function, when trying to load > the (bad) function pointer from offset 0 of base address 0xF, so before > branching to the function. > > It does not affect PPC64 little-endian machines because by default ABI > ELFv2 > is used (instead of ABI ELFv1) and for that ABI no function descriptor is > defined / employed. > > The fix consists in defining properly a function descriptor with a bad > function > at offset 0 (the following offset are no important in that case) and using > that > function descriptor to call the bad function, only on PPC64 big-endian > machines. > > That issue was found when investigating the JDK-8220794 issue [2]. > > Thank you. > > Best regards, > Gustavo > > [1] > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES > [2] https://bugs.openjdk.java.net/browse/JDK-8220794 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Sun Mar 24 17:40:05 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Sun, 24 Mar 2019 14:40:05 -0300 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> Message-ID: <469729f3-f00a-1a5d-3e45-06f911163cce@linux.vnet.ibm.com> Hi Chris, On 03/22/2019 03:05 PM, Chris Phillips wrote: > Hi > > On 2019-03-22 12:15 p.m., Gustavo Romero wrote: >> Hi, >> >> Please, could I get reviews for the following change? >> >> bug?? : https://bugs.openjdk.java.net/browse/JDK-8221175 >> webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ [SNIP] > Looks good, but not a reviewer. Thanks a lot for reviewing it Chris. I'll add you as a (r)eviewer to the commit message after I get more inputs from hotspot-runtime-dev ML. Best regards, Gustavo From gromero at linux.vnet.ibm.com Sun Mar 24 19:12:15 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Sun, 24 Mar 2019 16:12:15 -0300 Subject: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address In-Reply-To: References: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> Message-ID: Hi Thomas, On 03/22/2019 02:18 PM, Thomas St?fe wrote: > Hi Gustavo, > > Just a question, is the other case where we replace si_addr with > > address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc); > > really needed? Since we use si_addr in a number of places and I always assumed that just works like on every other posix system. This a good point, Thomas. If si_addr had always worked on Linux I understand that get_stack_band_address() would have never existed and the signal handler would not have to discern between data and instruction interruptions at all. By the comments and logs it looks like si_addr was broken before kernel 2.6.6 (quite old) which afaics is not currently supported by any distros anymore. So get_stack_bang_address() in the past was necessary, but not anymore, since long time, thus relying on si_addr in other places you pointed out worked well so far and will continues to work. We could switch the code to trust si_addr only, since I believe there is no real impact nowadays. But in theory it can be a regression... ? Thomas and Goetz: which approach do you suggest here? Please, advise. Thank you. Best regards, Gustavo > E.g. we use it for assertion poison page handling or handling of secondary crashes during error reporting, see handle_assert_poison_fault(). > > Cheers, Thomas > > > On Fri, Mar 22, 2019 at 4:29 PM Gustavo Romero > wrote: > > Hi, > > Please, could I get reviews for the following change: > > bug : https://bugs.openjdk.java.net/browse/JDK-8220794 > webrev: http://cr.openjdk.java.net/~gromero/8220794/v1/ > > It fixes the JVM signal handler on Linux / PPC64 when a SIGSEGV generated > by a branch to an illegal/invalid address (not mapped address, address with no > executable flags, etc) is caught by the JVM signal handler. Currently the signal > handler does not handle that case correctly and the JVM crashes silently. > > That issue was reported by Goetz (SAP). Thanks for reporting the issue, Goetz. > > Thank you. > > Best regards, > Gustavo > From gromero at linux.vnet.ibm.com Sun Mar 24 19:20:44 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Sun, 24 Mar 2019 16:20:44 -0300 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> Message-ID: <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> Hi Thomas! On 03/23/2019 05:43 PM, Thomas St?fe wrote: > Hi Gustavo, > > looks good. Thanks a lot for reviewing it and for your comments! > Would be nice to cleanly factor function descriptor handling out at some point: we have various pieces, e.g. a struct FunctionDescriptor in assembler_ppc.hpp, a resolve function in os_aix.cpp, now this... also, I believe, on AIX there is a struct FunctionDescriptor in os headers, but I may remember this wrong. > > But cleanup can be done in a different change. Unfortunately I don't have access to AIX systems, so I can't test/work on AIX (that's one of the reasons I decided to CC ppc-aix-port-dev). I overlooked 'struct FunctionDescriptor' presence. All headers look in place, so how about using FunctionDescritor instead of an array? webrev v2: http://cr.openjdk.java.net/~gromero/8221175/v2/ Cheers, Gustavo > Thanks for fixing! > > Cheers, Thomas > > > On Fri, Mar 22, 2019 at 5:15 PM Gustavo Romero > wrote: > > Hi, > > Please, could I get reviews for the following change? > > bug : https://bugs.openjdk.java.net/browse/JDK-8221175 > webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ > > It fixes the way a function pointer is defined in order to call a bad function > at address 0xF (controlled crash case 13) on PPC64 big-endian machines. > > On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates function > pointers to part of a function descriptor, at offset 0 [1]. > > Currently the SIGISEGV being generated by case 13 is incorrect because if a > function descriptor is not use to call the bad function address the program > segfaults before effectively calling the function, when trying to load > the (bad) function pointer from offset 0 of base address 0xF, so before > branching to the function. > > It does not affect PPC64 little-endian machines because by default ABI ELFv2 > is used (instead of ABI ELFv1) and for that ABI no function descriptor is > defined / employed. > > The fix consists in defining properly a function descriptor with a bad function > at offset 0 (the following offset are no important in that case) and using that > function descriptor to call the bad function, only on PPC64 big-endian machines. > > That issue was found when investigating the JDK-8220794 issue [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES > [2] https://bugs.openjdk.java.net/browse/JDK-8220794 > From thomas.stuefe at gmail.com Sun Mar 24 19:37:19 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 24 Mar 2019 20:37:19 +0100 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> Message-ID: Hi Gustavo, On Sun 24. Mar 2019 at 20:20, Gustavo Romero wrote: > Hi Thomas! > > On 03/23/2019 05:43 PM, Thomas St?fe wrote: > > Hi Gustavo, > > > > looks good. > > Thanks a lot for reviewing it and for your comments! > > > > Would be nice to cleanly factor function descriptor handling out at some > point: we have various pieces, e.g. a struct FunctionDescriptor in > assembler_ppc.hpp, a resolve function in os_aix.cpp, now this... also, I > believe, on AIX there is a struct FunctionDescriptor in os headers, but I > may remember this wrong. > > > > But cleanup can be done in a different change. > > Unfortunately I don't have access to AIX systems, so I can't test/work on > AIX > (that's one of the reasons I decided to CC ppc-aix-port-dev). > > I overlooked 'struct FunctionDescriptor' presence. All headers look in > place, so > how about using FunctionDescritor instead of an array? > > webrev v2: > > http://cr.openjdk.java.net/~gromero/8221175/v2/ > Make sure this builds with precompiled headers disabled. I am guessing you miss inclusion of assembler_ppc.hpp here. Otherwise looks good. Cheers, thomas > Cheers, > Gustavo > > > Thanks for fixing! > > > > Cheers, Thomas > > > > > > On Fri, Mar 22, 2019 at 5:15 PM Gustavo Romero < > gromero at linux.vnet.ibm.com > wrote: > > > > Hi, > > > > Please, could I get reviews for the following change? > > > > bug : https://bugs.openjdk.java.net/browse/JDK-8221175 > > webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ < > http://cr.openjdk.java.net/%7Egromero/8221175/v1/> > > > > It fixes the way a function pointer is defined in order to call a > bad function > > at address 0xF (controlled crash case 13) on PPC64 big-endian > machines. > > > > On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates > function > > pointers to part of a function descriptor, at offset 0 [1]. > > > > Currently the SIGISEGV being generated by case 13 is incorrect > because if a > > function descriptor is not use to call the bad function address the > program > > segfaults before effectively calling the function, when trying to > load > > the (bad) function pointer from offset 0 of base address 0xF, so > before > > branching to the function. > > > > It does not affect PPC64 little-endian machines because by default > ABI ELFv2 > > is used (instead of ABI ELFv1) and for that ABI no function > descriptor is > > defined / employed. > > > > The fix consists in defining properly a function descriptor with a > bad function > > at offset 0 (the following offset are no important in that case) and > using that > > function descriptor to call the bad function, only on PPC64 > big-endian machines. > > > > That issue was found when investigating the JDK-8220794 issue [2]. > > > > Thank you. > > > > Best regards, > > Gustavo > > > > [1] > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES > > [2] https://bugs.openjdk.java.net/browse/JDK-8220794 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon Mar 25 08:19:02 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Mar 2019 08:19:02 +0000 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for fixing this, looks good. Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero > Sent: Freitag, 22. M?rz 2019 17:15 > To: hotspot-runtime-dev at openjdk.java.net > Cc: daniel.daugherty at oracle.com; Lindenmaier, Goetz > ; ppc-aix-port-dev at openjdk.java.net > Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on > PPC64 big-endian > > Hi, > > Please, could I get reviews for the following change? > > bug : https://bugs.openjdk.java.net/browse/JDK-8221175 > webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ > > It fixes the way a function pointer is defined in order to call a bad function > at address 0xF (controlled crash case 13) on PPC64 big-endian machines. > > On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates function > pointers to part of a function descriptor, at offset 0 [1]. > > Currently the SIGISEGV being generated by case 13 is incorrect because if a > function descriptor is not use to call the bad function address the program > segfaults before effectively calling the function, when trying to load > the (bad) function pointer from offset 0 of base address 0xF, so before > branching to the function. > > It does not affect PPC64 little-endian machines because by default ABI ELFv2 > is used (instead of ABI ELFv1) and for that ABI no function descriptor is > defined / employed. > > The fix consists in defining properly a function descriptor with a bad function > at offset 0 (the following offset are no important in that case) and using that > function descriptor to call the bad function, only on PPC64 big-endian > machines. > > That issue was found when investigating the JDK-8220794 issue [2]. > > Thank you. > > Best regards, > Gustavo > > [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC- > DES > [2] https://bugs.openjdk.java.net/browse/JDK-8220794 From goetz.lindenmaier at sap.com Mon Mar 25 08:32:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Mar 2019 08:32:07 +0000 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> Message-ID: Looks good, too. Best, Goetz > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Gustavo Romero > Sent: Sonntag, 24. M?rz 2019 20:21 > To: Thomas St?fe > Cc: ppc-aix-port-dev at openjdk.java.net; Daniel D. Daugherty > ; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8221175: Fix bad function case for controlled JVM crash on > PPC64 big-endian > > Hi Thomas! > > On 03/23/2019 05:43 PM, Thomas St?fe wrote: > > Hi Gustavo, > > > > looks good. > > Thanks a lot for reviewing it and for your comments! > > > > Would be nice to cleanly factor function descriptor handling out at some > point: we have various pieces, e.g. a struct FunctionDescriptor in > assembler_ppc.hpp, a resolve function in os_aix.cpp, now this... also, I believe, > on AIX there is a struct FunctionDescriptor in os headers, but I may remember > this wrong. > > > > But cleanup can be done in a different change. > > Unfortunately I don't have access to AIX systems, so I can't test/work on AIX > (that's one of the reasons I decided to CC ppc-aix-port-dev). > > I overlooked 'struct FunctionDescriptor' presence. All headers look in place, so > how about using FunctionDescritor instead of an array? > > webrev v2: > > http://cr.openjdk.java.net/~gromero/8221175/v2/ > > Cheers, > Gustavo > > > Thanks for fixing! > > > > Cheers, Thomas > > > > > > On Fri, Mar 22, 2019 at 5:15 PM Gustavo Romero > > > wrote: > > > > Hi, > > > > Please, could I get reviews for the following change? > > > > bug : https://bugs.openjdk.java.net/browse/JDK-8221175 > > webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ > > > > > It fixes the way a function pointer is defined in order to call a bad function > > at address 0xF (controlled crash case 13) on PPC64 big-endian machines. > > > > On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates > function > > pointers to part of a function descriptor, at offset 0 [1]. > > > > Currently the SIGISEGV being generated by case 13 is incorrect because if a > > function descriptor is not use to call the bad function address the program > > segfaults before effectively calling the function, when trying to load > > the (bad) function pointer from offset 0 of base address 0xF, so before > > branching to the function. > > > > It does not affect PPC64 little-endian machines because by default ABI > ELFv2 > > is used (instead of ABI ELFv1) and for that ABI no function descriptor is > > defined / employed. > > > > The fix consists in defining properly a function descriptor with a bad > function > > at offset 0 (the following offset are no important in that case) and using > that > > function descriptor to call the bad function, only on PPC64 big-endian > machines. > > > > That issue was found when investigating the JDK-8220794 issue [2]. > > > > Thank you. > > > > Best regards, > > Gustavo > > > > [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC- > elf64abi.html#FUNC-DES > > [2] https://bugs.openjdk.java.net/browse/JDK-8220794 > > From goetz.lindenmaier at sap.com Mon Mar 25 09:02:05 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Mar 2019 09:02:05 +0000 Subject: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address In-Reply-To: References: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> Message-ID: Hi, the change looks good, and passed our testing together with the test fix for be. I would remove get_stack_band_address() in a follow up. I would appreciate if this one gets downported to jdk11u. We run jdk11u on quite old linux versions, so we better leave this in place for 11. For 13++ it makes sense to remove the old stuff. Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Gustavo Romero > Sent: Sonntag, 24. M?rz 2019 20:12 > To: Thomas St?fe ; goetz.lindenmeir at sap.com > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch > to illegal address > > Hi Thomas, > > On 03/22/2019 02:18 PM, Thomas St?fe wrote: > > Hi Gustavo, > > > > Just a question, is the other case where we replace si_addr with > > > > address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc); > > > > really needed? Since we use si_addr in a number of places and I always > assumed that just works like on every other posix system. > > This a good point, Thomas. If si_addr had always worked on Linux I understand > that get_stack_band_address() would have never existed and the signal > handler > would not have to discern between data and instruction interruptions at all. > > By the comments and logs it looks like si_addr was broken before kernel 2.6.6 > (quite old) which afaics is not currently supported by any distros anymore. > So get_stack_bang_address() in the past was necessary, but not anymore, > since > long time, thus relying on si_addr in other places you pointed out worked > well so far and will continues to work. > > We could switch the code to trust si_addr only, since I believe there is no real > impact nowadays. But in theory it can be a regression... ? > > Thomas and Goetz: which approach do you suggest here? Please, advise. > > Thank you. > > Best regards, > Gustavo > > > E.g. we use it for assertion poison page handling or handling of secondary > crashes during error reporting, see handle_assert_poison_fault(). > > > > Cheers, Thomas > > > > > > On Fri, Mar 22, 2019 at 4:29 PM Gustavo Romero > > > wrote: > > > > Hi, > > > > Please, could I get reviews for the following change: > > > > bug : https://bugs.openjdk.java.net/browse/JDK-8220794 > > webrev: http://cr.openjdk.java.net/~gromero/8220794/v1/ > > > > > It fixes the JVM signal handler on Linux / PPC64 when a SIGSEGV > generated > > by a branch to an illegal/invalid address (not mapped address, address > with no > > executable flags, etc) is caught by the JVM signal handler. Currently the > signal > > handler does not handle that case correctly and the JVM crashes silently. > > > > That issue was reported by Goetz (SAP). Thanks for reporting the issue, > Goetz. > > > > Thank you. > > > > Best regards, > > Gustavo > > From thomas.stuefe at gmail.com Mon Mar 25 12:06:53 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 13:06:53 +0100 Subject: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address In-Reply-To: References: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> Message-ID: On Mon, Mar 25, 2019 at 10:02 AM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > the change looks good, and passed our testing together with > the test fix for be. > > I would remove get_stack_band_address() in a follow up. > I would appreciate if this one gets downported to jdk11u. > We run jdk11u on quite old linux versions, so we better leave > this in place for 11. For 13++ it makes sense to remove > the old stuff. > Okay. We should create a follow up issue. Thanks, Thomas > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-runtime-dev > bounces at openjdk.java.net> On Behalf Of Gustavo Romero > > Sent: Sonntag, 24. M?rz 2019 20:12 > > To: Thomas St?fe ; goetz.lindenmeir at sap.com > > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime- > > dev at openjdk.java.net > > Subject: Re: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on > branch > > to illegal address > > > > Hi Thomas, > > > > On 03/22/2019 02:18 PM, Thomas St?fe wrote: > > > Hi Gustavo, > > > > > > Just a question, is the other case where we replace si_addr with > > > > > > address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc); > > > > > > really needed? Since we use si_addr in a number of places and I always > > assumed that just works like on every other posix system. > > > > This a good point, Thomas. If si_addr had always worked on Linux I > understand > > that get_stack_band_address() would have never existed and the signal > > handler > > would not have to discern between data and instruction interruptions at > all. > > > > By the comments and logs it looks like si_addr was broken before kernel > 2.6.6 > > (quite old) which afaics is not currently supported by any distros > anymore. > > So get_stack_bang_address() in the past was necessary, but not anymore, > > since > > long time, thus relying on si_addr in other places you pointed out worked > > well so far and will continues to work. > > > > We could switch the code to trust si_addr only, since I believe there is > no real > > impact nowadays. But in theory it can be a regression... ? > > > > Thomas and Goetz: which approach do you suggest here? Please, advise. > > > > Thank you. > > > > Best regards, > > Gustavo > > > > > E.g. we use it for assertion poison page handling or handling of > secondary > > crashes during error reporting, see handle_assert_poison_fault(). > > > > > > Cheers, Thomas > > > > > > > > > On Fri, Mar 22, 2019 at 4:29 PM Gustavo Romero > > > > > wrote: > > > > > > Hi, > > > > > > Please, could I get reviews for the following change: > > > > > > bug : https://bugs.openjdk.java.net/browse/JDK-8220794 > > > webrev: http://cr.openjdk.java.net/~gromero/8220794/v1/ > > > > > > > > It fixes the JVM signal handler on Linux / PPC64 when a SIGSEGV > > generated > > > by a branch to an illegal/invalid address (not mapped address, > address > > with no > > > executable flags, etc) is caught by the JVM signal handler. > Currently the > > signal > > > handler does not handle that case correctly and the JVM crashes > silently. > > > > > > That issue was reported by Goetz (SAP). Thanks for reporting the > issue, > > Goetz. > > > > > > Thank you. > > > > > > Best regards, > > > Gustavo > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Mon Mar 25 16:12:12 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Mar 2019 13:12:12 -0300 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> Message-ID: Hi Thomas, On 03/24/2019 04:37 PM, Thomas St?fe wrote: > Make sure this builds with precompiled headers disabled. I am guessing you miss inclusion of assembler_ppc.hpp here. > > Otherwise looks good. Thanks for the review! I tested without explicitly including assembler_ppc.hpp (v2 change) by building on a brand new ./build dir and also with --disable-precompiled-headers. On both cases it builds fine. I'll push it today to jdk/jdk. Cheers, Gustavo From thomas.stuefe at gmail.com Mon Mar 25 16:16:08 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Mar 2019 17:16:08 +0100 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> Message-ID: Thanks for checking and fixing! .. Thomas On Mon, Mar 25, 2019, 5:12 PM Gustavo Romero wrote: > Hi Thomas, > > On 03/24/2019 04:37 PM, Thomas St?fe wrote: > > Make sure this builds with precompiled headers disabled. I am guessing > you miss inclusion of assembler_ppc.hpp here. > > > > Otherwise looks good. > > Thanks for the review! > > I tested without explicitly including assembler_ppc.hpp (v2 change) by > building on a brand new ./build dir and also with > --disable-precompiled-headers. > On both cases it builds fine. > > I'll push it today to jdk/jdk. > > Cheers, > Gustavo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Mon Mar 25 16:16:39 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Mar 2019 13:16:39 -0300 Subject: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address In-Reply-To: References: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> Message-ID: Hi Thomas and Goetz, On 03/25/2019 09:06 AM, Thomas St?fe wrote: > > > On Mon, Mar 25, 2019 at 10:02 AM Lindenmaier, Goetz > wrote: > > Hi, > > the change looks good, and passed our testing together with > the test fix for be. > > I would remove get_stack_band_address() in a follow up. > I would appreciate if this one gets downported to jdk11u. > We run jdk11u on quite old linux versions, so we better leave > this in place for 11.? ?For 13++ it makes sense to remove > the old stuff. > > > Okay. We should create a follow up issue. I've opened the following bug to track it: PPC64: Remove get_stack_bang_address workaround https://bugs.openjdk.java.net/browse/JDK-8221410 Best regards, Gustavo From gromero at linux.vnet.ibm.com Mon Mar 25 16:14:14 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 25 Mar 2019 13:14:14 -0300 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> Message-ID: <11045650-e4ff-e235-05e0-d2b32c80b137@linux.vnet.ibm.com> Hi Goetz, On 03/25/2019 05:32 AM, Lindenmaier, Goetz wrote: > Looks good, too. Thanks a lot for the review. Should I run it against submit tests before pushing? It's a change in shared code, but it can't affect other architectures. Best regards, Gustavo > Best, Goetz > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Gustavo Romero >> Sent: Sonntag, 24. M?rz 2019 20:21 >> To: Thomas St?fe >> Cc: ppc-aix-port-dev at openjdk.java.net; Daniel D. Daugherty >> ; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(S): 8221175: Fix bad function case for controlled JVM crash on >> PPC64 big-endian >> >> Hi Thomas! >> >> On 03/23/2019 05:43 PM, Thomas St?fe wrote: >>> Hi Gustavo, >>> >>> looks good. >> >> Thanks a lot for reviewing it and for your comments! >> >> >>> Would be nice to cleanly factor function descriptor handling out at some >> point: we have various pieces, e.g. a struct FunctionDescriptor in >> assembler_ppc.hpp, a resolve function in os_aix.cpp, now this... also, I believe, >> on AIX there is a struct FunctionDescriptor in os headers, but I may remember >> this wrong. >>> >>> But cleanup can be done in a different change. >> >> Unfortunately I don't have access to AIX systems, so I can't test/work on AIX >> (that's one of the reasons I decided to CC ppc-aix-port-dev). >> >> I overlooked 'struct FunctionDescriptor' presence. All headers look in place, so >> how about using FunctionDescritor instead of an array? >> >> webrev v2: >> >> http://cr.openjdk.java.net/~gromero/8221175/v2/ >> >> Cheers, >> Gustavo >> >>> Thanks for fixing! >>> >>> Cheers, Thomas >>> >>> >>> On Fri, Mar 22, 2019 at 5:15 PM Gustavo Romero >> > >> wrote: >>> >>> Hi, >>> >>> Please, could I get reviews for the following change? >>> >>> bug : https://bugs.openjdk.java.net/browse/JDK-8221175 >>> webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ >> >>> >>> It fixes the way a function pointer is defined in order to call a bad function >>> at address 0xF (controlled crash case 13) on PPC64 big-endian machines. >>> >>> On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates >> function >>> pointers to part of a function descriptor, at offset 0 [1]. >>> >>> Currently the SIGISEGV being generated by case 13 is incorrect because if a >>> function descriptor is not use to call the bad function address the program >>> segfaults before effectively calling the function, when trying to load >>> the (bad) function pointer from offset 0 of base address 0xF, so before >>> branching to the function. >>> >>> It does not affect PPC64 little-endian machines because by default ABI >> ELFv2 >>> is used (instead of ABI ELFv1) and for that ABI no function descriptor is >>> defined / employed. >>> >>> The fix consists in defining properly a function descriptor with a bad >> function >>> at offset 0 (the following offset are no important in that case) and using >> that >>> function descriptor to call the bad function, only on PPC64 big-endian >> machines. >>> >>> That issue was found when investigating the JDK-8220794 issue [2]. >>> >>> Thank you. >>> >>> Best regards, >>> Gustavo >>> >>> [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC- >> elf64abi.html#FUNC-DES >>> [2] https://bugs.openjdk.java.net/browse/JDK-8220794 >>> > From goetz.lindenmaier at sap.com Tue Mar 26 07:15:24 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Mar 2019 07:15:24 +0000 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: <11045650-e4ff-e235-05e0-d2b32c80b137@linux.vnet.ibm.com> References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> <11045650-e4ff-e235-05e0-d2b32c80b137@linux.vnet.ibm.com> Message-ID: > Should I run it against submit tests before pushing? It's a change in shared > code, but it can't affect other architectures. I think it's safe to be pushed. Best regards, Goetz. > > Best regards, > Gustavo > > > Best, Goetz > > > >> -----Original Message----- > >> From: ppc-aix-port-dev On > >> Behalf Of Gustavo Romero > >> Sent: Sonntag, 24. M?rz 2019 20:21 > >> To: Thomas St?fe > >> Cc: ppc-aix-port-dev at openjdk.java.net; Daniel D. Daugherty > >> ; hotspot-runtime-dev at openjdk.java.net > >> Subject: Re: RFR(S): 8221175: Fix bad function case for controlled JVM crash > on > >> PPC64 big-endian > >> > >> Hi Thomas! > >> > >> On 03/23/2019 05:43 PM, Thomas St?fe wrote: > >>> Hi Gustavo, > >>> > >>> looks good. > >> > >> Thanks a lot for reviewing it and for your comments! > >> > >> > >>> Would be nice to cleanly factor function descriptor handling out at some > >> point: we have various pieces, e.g. a struct FunctionDescriptor in > >> assembler_ppc.hpp, a resolve function in os_aix.cpp, now this... also, I > believe, > >> on AIX there is a struct FunctionDescriptor in os headers, but I may > remember > >> this wrong. > >>> > >>> But cleanup can be done in a different change. > >> > >> Unfortunately I don't have access to AIX systems, so I can't test/work on AIX > >> (that's one of the reasons I decided to CC ppc-aix-port-dev). > >> > >> I overlooked 'struct FunctionDescriptor' presence. All headers look in place, > so > >> how about using FunctionDescritor instead of an array? > >> > >> webrev v2: > >> > >> http://cr.openjdk.java.net/~gromero/8221175/v2/ > >> > >> Cheers, > >> Gustavo > >> > >>> Thanks for fixing! > >>> > >>> Cheers, Thomas > >>> > >>> > >>> On Fri, Mar 22, 2019 at 5:15 PM Gustavo Romero > >> > > >> wrote: > >>> > >>> Hi, > >>> > >>> Please, could I get reviews for the following change? > >>> > >>> bug : https://bugs.openjdk.java.net/browse/JDK-8221175 > >>> webrev: http://cr.openjdk.java.net/~gromero/8221175/v1/ > >> > >>> > >>> It fixes the way a function pointer is defined in order to call a bad > function > >>> at address 0xF (controlled crash case 13) on PPC64 big-endian > machines. > >>> > >>> On PPC64 big-endian compiler defaults to ABI ELFv1 which mandates > >> function > >>> pointers to part of a function descriptor, at offset 0 [1]. > >>> > >>> Currently the SIGISEGV being generated by case 13 is incorrect because > if a > >>> function descriptor is not use to call the bad function address the > program > >>> segfaults before effectively calling the function, when trying to load > >>> the (bad) function pointer from offset 0 of base address 0xF, so before > >>> branching to the function. > >>> > >>> It does not affect PPC64 little-endian machines because by default ABI > >> ELFv2 > >>> is used (instead of ABI ELFv1) and for that ABI no function descriptor is > >>> defined / employed. > >>> > >>> The fix consists in defining properly a function descriptor with a bad > >> function > >>> at offset 0 (the following offset are no important in that case) and using > >> that > >>> function descriptor to call the bad function, only on PPC64 big-endian > >> machines. > >>> > >>> That issue was found when investigating the JDK-8220794 issue [2]. > >>> > >>> Thank you. > >>> > >>> Best regards, > >>> Gustavo > >>> > >>> [1] http://refspecs.linuxfoundation.org/ELF/ppc64/PPC- > >> elf64abi.html#FUNC-DES > >>> [2] https://bugs.openjdk.java.net/browse/JDK-8220794 > >>> > > From gromero at linux.vnet.ibm.com Tue Mar 26 14:12:58 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 26 Mar 2019 11:12:58 -0300 Subject: RFR(S): 8221175: Fix bad function case for controlled JVM crash on PPC64 big-endian In-Reply-To: References: <44bd2ee6-28e7-17b5-a213-b57da9ece511@linux.vnet.ibm.com> <69c42d64-ed18-f815-d4fa-b6bbbcaa79bc@linux.vnet.ibm.com> <11045650-e4ff-e235-05e0-d2b32c80b137@linux.vnet.ibm.com> Message-ID: On 03/26/2019 04:15 AM, Lindenmaier, Goetz wrote: > >> Should I run it against submit tests before pushing? It's a change in shared >> code, but it can't affect other architectures. > I think it's safe to be pushed. Thank you. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/a2897fb258f1 Cheers, Gustavo From gromero at linux.vnet.ibm.com Tue Mar 26 14:16:55 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 26 Mar 2019 11:16:55 -0300 Subject: RFR(S): 8220794: PPC64: Fix signal handler for SIGSEGV on branch to illegal address In-Reply-To: References: <396a3f4d-a12c-127d-0579-bec17cae77cc@linux.vnet.ibm.com> Message-ID: <4ef56d57-2fca-0404-1a8b-67e1e284abed@linux.vnet.ibm.com> On 03/25/2019 06:02 AM, Lindenmaier, Goetz wrote: > Hi, > > the change looks good, and passed our testing together with > the test fix for be. Thanks Thomas and Goetz. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/e61065c08924 Cheers, Gustavo