Re: Suggestion needed to port the fix to JDK17 and JDK11S
On 14/02/2025 08:18, Shruthi . wrote: Hi Alan, Reordering |preClose()| in AIX resolves the customer issue. We have validated the fix, and the customer has confirmed it as well. It may have resolved your customer issue but I'm not yet convinced it's a robust workaround for the AIX issue. Can you check with your AIX team on how happens if pthread_kill(thread, SGRTMAX-1) is called and the target thread is in not in the read/write syscalls. It looks to me that the signal won't be handled and the thread may continue on and block in read/write. With your patch then thread calling the close method will do the dup2 and hang as before. It's the window between setting readerThread/writerThread and blocking in the read/write syscalls that you need to look at. -Alan
Re: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection
On Fri, 14 Feb 2025 07:33:58 GMT, Jaikiran Pai wrote: > Hello Sean, given the assertable change to the API documentation of > `java.net.JarURLConnection.getCertificates()`, which now specifies the order > of the returned certificates, would this require a CSR? Yes, I think we should. I'll do that. - PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2659404074
RE: Suggestion needed to port the fix to JDK17 and JDK11
Hi Alan,
Reordering preClose() in AIX resolves the customer issue. We have validated the
fix, and the customer has confirmed it as well.
Thanks
Shruthi
From: Alan Bateman
Sent: Thursday, February 13, 2025 10:20 PM
To: Shruthi . ; net-dev@openjdk.org
Cc: Syed Moinudeen
Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11
On 12/02/2025 06: 13, Shruthi . wrote: We discussed the issue with AIX OS team
to get their input as this issue is happening only in AIX platform. Update from
AIX OS dev team: A thread gets stuck in dup2() while duplicating a file
descriptor
On 12/02/2025 06:13, Shruthi . wrote:
We discussed the issue with AIX OS team to get their input as this issue is
happening only in AIX platform. Update from AIX OS dev team: A thread gets
stuck in dup2() while duplicating a file descriptor that is already being used
by two other threads (one for reading, one for writing). The writer thread does
not write or close the FIFO, causing the reader to wait indefinitely, which
blocks dup2(). Also he is saying that we cannot change OS side as it may break
or change its existing behavior which other existing applications may be
depending on.
Can we apply the previously proposed fix at java level(reordering the
preClose() method) while adding an AIX-specific check to ensure it doesn’t
affect other platforms? Or do you have any alternative suggestions?
if (!tryClose()) {
long th = thread;
if (th != 0) {
if (!AIX.isAIX)
nd.preClose(fd);
NativeThread.signal(th);
if (AIX.isAIX)
nd.preClose(fd);
}
}
Are you sure this really fixes the issue on AIX? It means a reader or writer
may be signalled before the syscall, is the signal missed or are you saying
that it queues up on AIX? If it missed then the close will block in dup2 as
before.
-Alan
Re: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection
On Fri, 14 Feb 2025 13:57:12 GMT, Sean Mullan wrote: > > Hello Sean, given the assertable change to the API documentation of > > `java.net.JarURLConnection.getCertificates()`, which now specifies the > > order of the returned certificates, would this require a CSR? > > Yes, I think we should. I'll do that. Please review the CSR at https://bugs.openjdk.org/browse/JDK-8350117. Thanks. - PR Comment: https://git.openjdk.org/jdk/pull/23616#issuecomment-2659794172
Re: RFR: 8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection
On Thu, 13 Feb 2025 16:27:03 GMT, Sean Mullan wrote: > This change adds an API note to these methods recommending that the caller > should perform further validation steps on the code signers that signed the > JAR file, such as validating the code signer's certificate chain, and > determining if the signer should be trusted. There was already a similar > warning in the `JarFile` and `JarInputStream` class descriptions, but this > adds a similar and more direct warning at the methods that return the code > signer's certificates. > > 2 other smaller changes: > - In `JarEntry.getCertificates`, added a recommendation to use the > `getCodeSigners` method instead > - Added details of the order of the returned certificates to > `JarURLConnection.getCertificates` (copied from `JarEntry.getCertificates`) Marked as reviewed by lancea (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/23616#pullrequestreview-2618386370
