So can I assume the FIPS POST has completed if I never call FIPS_mode_set() in the code? I was confused about that.
When we call SSL_read() and get a 0 byte return we call SSL_get_error() to see if there was an error not not. Maybe there is a more efficient handle this, like looking at the shutdown flag?
0 The read operation was not successful. The reason may either be a
clean shutdown due to a "close notify" alert sent by the peer (in
which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state
is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
possible, that the peer simply shut down the underlying transport
and the shutdown is incomplete. Call SSL_get_error() with the
return value ret to find out, whether an error occurred or the
connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).
When we call SSL_accept we also call SSL_get_error() to see we need to read or write. Is there a more efficient way to tell if we need to read or write?
If the underlying BIO is non-blocking, SSL_accept() will also return
when the underlying BIO could not satisfy the needs of SSL_accept() to
continue the handshake, indicating the problem by the return value -1.
In this case a call to SSL_get_error() with the return value of
SSL_accept() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
The calling process then must repeat the call after taking appropriate
action to satisfy the needs of SSL_accept(). The action depends on the
underlying BIO. When using a non-blocking socket, nothing is to be
done, but select() can be used to check for the required condition.
When using a buffering BIO, like a BIO pair, data must be written into
or retrieved out of the BIO before being able to continue.
Thank you...
-Bryan
> On May 1, 2015, at 5:34 AM, John Foley <foleyj at cisco.com> wrote:
>
> Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It appears your application is generating a lot of errors for some reason. Never tried it myself, but you probably can't disable this lock with multiple threads running. You should take a look at the error log to identify the cause of the errors. Then resolve the issue, whatever it may be.
>
>
>
> On 04/30/2015 06:52 PM, Bryan Call wrote:
>> This is for Apache Traffic Server and we have no knobs for turning on/off FIPS. I am thinking about always disabling FIPS right now and that would happen before we create the threads.
>>
>> I was able to get rid of all the FIPS lock connection with the changes you recommend (Big Thanks!). The big one now is type 1. I am printing out the log every time the contention total is mod 1M. Are there any tricks I can do for type 1 locks?
>>
>> [Apr 30 22:46:49.549] Server {0x7f1e4531d700} ERROR: contention for lock - total contention: 4000000 waiting: 1 file: pmeth_lib.c line: 185 type: 10
>> [Apr 30 22:46:49.688] Server {0x7f1e45822700} ERROR: contention for lock - total contention: 11000000 waiting: 2 file: err.c line: 469 type: 1
>> [Apr 30 22:46:50.406] Server {0x7f1e45c26700} ERROR: contention for lock - total contention: 4000000 waiting: 0 file: ex_data.c line: 304 type: 2
>> [Apr 30 22:46:50.932] Server {0x7f1e45b25700} ERROR: contention for lock - total contention: 12000000 waiting: 5 file: err.c line: 446 type: 1
>> [Apr 30 22:46:52.001] Server {0x7f1e45721700} ERROR: contention for lock - total contention: 1000000 waiting: 0 file: rand_lib.c line: 212 type: 19
>>
>> -Bryan
>>
>>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
