Hi Grant,
On 05/09/2017 10:38 PM, Grant Zhang wrote:
>
>> On May 9, 2017, at 02:38, Emeric Brun <[email protected]> wrote:
>>
>> Hi Grant,
>>
>> On 05/06/2017 12:41 AM, Grant Zhang wrote:
>>> Hi Emeric,
>>>
>>> Thanks for your review! Please see the updated patches and let me know if
>>> your comments have been properly addressed.
>>>
>>> Thanks,
>>>
>>> Grant
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On May 2, 2017, at 04:49, Emeric Brun <[email protected]> wrote:
>>>>
>>>> Hi Grant,
>>>>
>>>>
>>>> An other issue:
>>>>
>>>> static void ssl_sock_close(struct connection *conn) {
>>>>
>>>> if (conn->xprt_ctx) {
>>>> if (global_ssl.async) {
>>>> /* the async fd is created and owned by the SSL
>>>> engine, which is
>>>> * responsible for fd closure. Here we are done with
>>>> the async fd
>>>> * thus disable the polling on it, as well as clean
>>>> up fdtab entry.
>>>> */
>>>> fd_stop_both(conn->async_fd);
>>>> fdtab[conn->async_fd].async = 0;
>>>> fdtab[conn->async_fd].state = 0;
>>>> }
>>>>
>>>>
>>>> If yout configure ssl-async without an engine or filtering on a unused
>>>> algo. This code is
>>>> called with an uninitialized conn->async_fd, resulting some of the time
>>>> with a segfault.
>>>>
>>>> R,
>>>> Emeric
>>>
>>
>> The issue is still there:
>> +#if OPENSSL_VERSION_NUMBER >= 0x1010000fL
>> + if (openssl_engines_initialized && global_ssl.async) {
>> + /* the async fd is created and owned by the SSL engine,
>> which is
>> + * responsible for fd closure. Here we are done with
>> the async fd
>> + * thus disable the polling on it, as well as clean up
>> fdtab entry.
>> + */
>> + fd_stop_both(conn->async_fd);
>> + fdtab[conn->async_fd].async = 0;
>> + fdtab[conn->async_fd].state = 0;
>> + }
>> +#endif
>>
>> If no WANT_ASYNC is returned, the 'conn->async_fd' could remain
>> uninitialized (for instance a conn witch doesn't use algo provided by the
>> engine). A fix would be to initialize global_ssl.async to '-1' and to test
>> it.
> Now I see the issue, thanks. Wrt the fix, I might be missing something--I
> don't know how initialize global_ssl.async to -1 would fix the issue. Or do
> you mean initialize conn->async_fd to '-1'?
I mean conn->async_fd to '-1'
>> I still have the daemonize issue: the main process stalled on a futex if dh
>> param 2048 is set:
>>
>> global
>> tune.ssl.default-dh-param 2048
>>
> Hmm, I probably mixed "-d" with "-D" and thus couldn't repro the issue
> before. It looks like the main process stalls at DH_free(local_dh_1024) (part
> of __ssl_sock_deinit). Not sure why but I will debug and report back.
>
> Thanks,
I experienced the same issue (stalled on a futex) if i run haproxy in
foreground and trying to kill it with kill -USR1.
With this conf (dh param and ssl-async are disabled)
global
# tune.ssl.default-dh-param 2048
ssl-engine qat
# ssl-async
nbproc 1
>
> Grant
>
R,
Emeric
