Hi Emeric,
On 5/3/19 5:54 PM, Emeric Brun wrote:
Hi Marcin,
On 5/3/19 4:56 PM, Marcin Deranek wrote:
Hi Emeric,
On 5/3/19 4:50 PM, Emeric Brun wrote:
I've a testing platform here but I don't use the usdm_drv but the
qat_contig_mem and I don't reproduce this issue (I'm using QAT 1.5, as the doc
says to use with my chip) .
I see. I use qat 1.7 and qat-engine 0.5.40.
Anyway, could you re-compile a haproxy's binary if I provide you a testing
patch?
Sure, that should not be a problem.
The patch in attachment.
As I use HAProxy 1.8 I had to adjust the patch (see attachment for end
result). Unfortunately after applying the patch there is no change in
behavior: we still leak /dev/usdm_drv descriptors and have "stuck"
HAProxy instances after reload..
Regards,
Marcin Deranek
--- src/haproxy.c.orig 2019-05-06 13:58:39.814399336 +0200
+++ src/haproxy.c 2019-05-06 14:04:31.992043907 +0200
@@ -732,6 +732,12 @@
ptdf->fct();
if (fdtab)
deinit_pollers();
+#if defined(USE_OPENSSL)
+#ifndef OPENSSL_NO_ENGINE
+ /* Engines may have opened fds and we must close them */
+ ssl_free_engines();
+#endif
+#endif
/* compute length */
while (next_argv[next_argc])
