> On May 9, 2017, at 02:38, Emeric Brun <eb...@haproxy.com> 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 <eb...@haproxy.com> 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 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,
Grant
