On Thu, 7 Jan 2021 21:00:58 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>> I chose the term 'leak' in the sense of a resource not properly cleaned up. >> In this case, the 'leak' would not cause a memory/sockets/file-descriptors >> but a 'usable-sessions' exhaustion. It's always an analogy, but the sense is >> that something (a Session) unexpectedly (with an active operation) passes >> from one side (a P11Cipher instance) to another (the Session Manager). I >> don't believe 'corruptor' describes the concept better than 'leaker'. The >> Session is not corrupt, it can be used for for a specific purpose (the same >> operation that previously failed). Any other suggestion? Hmm... I cannot >> think of something better. > > So, after this PKCS11 session failed with an error, you can continue using > it, say give it another byte[] and it would continue to work as if the > earlier failed call never happened? I have not really tried it and thought > that this session is unusable due to the combination of an existing error > (say some exception happened during the encrypt update call) and active > operation state. Yes, that's right: you can use the session to continue the same operation. In fact, there is a pattern -also used in some Windows API functions- that you send an output buffer of length 0, you get a CKR_BUFFER_TOO_SMALL error and the buffer size that would have been required; and you make a second call with the right buffer size. This pattern is used from the OpenJDK native library that communicates with the PKCS#11 lib. Some types of errors (those that do not free the context) are not fatal. The problem is that we end up returning a session to the Session Manager and we try to use the session to initialize a different operation, while the previous is still active. ------------- PR: https://git.openjdk.java.net/jdk/pull/1901
