Hi Rahul,

On 07.11.2016 12:21, Rahul Raghavan wrote:
> Hi,
> 
> Request review for closed bug fix - JDK-8159035.
> 
> <webrev> - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/

Looks good to me!

> Notes:
> 
> 1. <jbs> - https://bugs.openjdk.java.net/browse/JDK-8159035 - 
> (com/sun/crypto/provider/Cipher/CTS/CTSMode.java test crashed due to 
> unhandled case of cipher length value as 0)
> Related issues - 
>     https://bugs.openjdk.java.net/browse/JDK-8076112 - 'Add 
> @HotSpotIntrinsicCandidate annotation to indicate methods for which Java 
> Runtime has intrinsics'
>     https://bugs.openjdk.java.net/browse/JDK-8167595 - 'AArch64: SEGV in stub 
> code cipherBlockChaining_decryptAESCrypt'
> 
> 2. Found root cause of the reported jvm crash for sparc -
> Crash happens at 'generate_cipherBlockChaining_decryptAESCrypt_Parallel()' 
> [stubGenerator_sparc.cpp]
> The implDecrypt can be called from CipherBlockChaining.decrypt, even with 
> cipherLen as 0.
> But the same condition is not handled in the stub code and results in crash.
> (the same applicable for implEncrypt)
> 
> 3. Though the reported case was for sparc, understood that same issue is 
> present for x86, aarch64 (JDK-8167595).
> So in above <webrev> fix proposed in Java wrapper method side 
> [CipherBlockChaining.java].
> 
> 4. The same issue in aarch64 (JDK-8167595) was fixed earlier in 
> stubGenerator_aarch64.
> So once above <webrev> is approved, I will initiate new hotspot webrev to 
> revert  this earlier 8167595 change.

Please file another bug for this and link it to this bug.

> 5. Checked for any other similar cases with HotSpotIntrinsicCandidate support 
> and found two cases as proposed in <webrev> 
>  - implCrypt() / CounterMode.java 
>  - implEncodeISOArray() / ISO_8859_1.java 
> 
> Confirmed no Issues for <webrev> with  jprt testing (-testset hotspot, core)

Please also run our RBT testing before pushing.

Thanks,
Tobias

> Thanks,
> Rahul
> 

Reply via email to