Re: [PULL 26/34] migration/multifd: Join the TLS thread

[Fabiano Rosas]

Michael Tokarev <mjt@tls.msk.ru> writes:

> 10.02.2024 12:18, Michael Tokarev:
>> 08.02.2024 06:05, peterx@redhat.com :
>>> From: Fabiano Rosas <farosas@suse.de>
>>>
>>> We're currently leaking the resources of the TLS thread by not joining
>>> it and also overwriting the p->thread pointer altogether.
>>>
>>> Fixes: a1af605bd5 ("migration/multifd: fix hangup with TLS-Multifd due to 
>>> blocking handshake")
>>> Cc: qemu-stable <qemu-stable@nongnu.org>
>>> Reviewed-by: Peter Xu <peterx@redhat.com>
>>> Signed-off-by: Fabiano Rosas <farosas@suse.de>
>>> Link: 20240206215118.6171-2-farosas@suse.de">https://lore.kernel.org/r/20240206215118.6171-2-farosas@suse.de
>>> Signed-off-by: Peter Xu <peterx@redhat.com>
>> 
>> This change, which is suggested for -stable, while simple by its own, seems
>> to depend on the previous changes in this series, which are not for -stable.
>> In particular, whole "Finally recycle all the threads" loop in 
>> multifd_send_terminate_threads()
>> (to which the join is being added by this change) is moved from elsewhere by
>> 12808db3b8 "migration/multifd: Cleanup multifd_save_cleanup()" (patch 24 in
>> this same series).
>> 
> We can probably add the missing join right into the previous location of this
> loop (before 12808db3b8).  I did this in the attached variant for 8.2, is
> this correct?

It should work. This was originally developed without the rest of the
changes on this PR.

>
> And this does not pass even the basic tests, so it's not that simple :)

Do you have a log of what failed?

Anyway, I could prepare a backport on top of 8.2 for you.

>
> The following patch (27/34) is more questionable than this one.
>
> Thanks!
>
> /mjt