Hi Marcin, On 5/6/19 3:15 PM, Marcin Deranek wrote: > 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,
Ok, the patch adds a ENGINE_finish() call before the reload. I was supposing that the ENGINE_finish would perform the close of the fd because on the application side there is no different way to interact with the engine. Unfortunately, this is not the case. So I will ask to the intel guys what we supposed to do to close this fd. R, Emeric
