I will just grab master then. Will this change be in the next 1.0.2 release?
-Bryan
> On May 8, 2015, at 10:12 AM, Salz, Rich wrote:
>
>
>> You can private message me the patch and I can benchmark it for you.
>> Please let me know what release version or hash on git that it will cleanly
>>
You can private message me the patch and I can benchmark it for you. Please
let me know what release version or hash on git that it will cleanly apply. Do
you know what release this will be going in?
-Bryan
> On May 1, 2015, at 6:49 AM, Salz, Rich wrote:
>
>> Lock #1 is CRYPTO_LOCK_ERR,
It is in non-blocking mode.
After removing the call to SSL_get_error for the SSL_read case (0 return value)
I discovered we call SSL_get_error in a couple more places. Here is a simple
request and the return codes on SSL_accept, SSL_read, and SSL_write and the
return codes from SSL_get_error.
Do you know if there is a way from preventing a call to SSL_get_error() after
getting a 0 byte read from SSL_read()? This is the main issue I am facing with
the OpenSSL error locking right now.
-Bryan
> On May 1, 2015, at 6:49 AM, Salz, Rich wrote:
>
>> Lock #1 is CRYPTO_LOCK_ERR, which I
>
>
>
> 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.
>>
>&
=0b732440636ab4e9eaedf237a5674bdc790c3e73;hp=2fae4820d7bab301340368e6be22445476d8d948;hb=d41e96f;hpb=ba1d6f7c9394c5efadb68cf9cf06f9b90f267b09
-Bryan
> On Apr 30, 2015, at 3: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 alwa
for the lifetime of the
> process and never disabled/re-enabled. You would invoke FIPS_mode_set(1) once
> prior to spinning up the worker threads. Therefore, the POST would be
> finished prior to any multi-threaded processing.
>
>
>
> On 04/29/2015 01:53 PM, Bryan Call wr
user intervention. Any future FIPS validations would
> be subject to the new rules. Hence, the behavior of FIPS_mode_set() may
> change in the future if OpenSSL decides to pursue another validation.
>
>
>
> On 04/28/2015 12:43 PM, Bryan Call wrote:
>> What do you
CK_FIPS39
> # define CRYPTO_LOCK_FIPS2 40
>
> You should try adding some logic to skip the lock in your lock handler when
> the lock ID is 39 or 40. Again, it should be safe to not lock on these two as
> long as the FIPS POST has completed.
>
>
&
t;
> # define CRYPTO_LOCK_ERR 1
> # define CRYPTO_LOCK_EX_DATA 2
>
> Have you checked the OpenSSL error log to see what errors are being generated?
>
> Also, if you disable FIPS, does the thread contention still occur?
>
>
>
> On 04
> Lastly, add some debugs to count the locks by lock ID in your lock handler.
> There are about 40 different lock IDs defined in crypto/crypto.h. You'll
> need to identify which lock is causing the thread contention. Once you know
> that, then you can look in the code to see wh
I was running a benchmark on a 28 core (56 hyper-threaded) server that is
running 84 threads in the process and I am seeing a lot of lock contention. I
saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I
am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We ha
12 matches
Mail list logo
