[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 26/34] migration/multifd: Join the TLS thread
From: |
Fabiano Rosas |
Subject: |
Re: [PULL 26/34] migration/multifd: Join the TLS thread |
Date: |
Wed, 14 Feb 2024 10:27:35 -0300 |
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