From nobody Wed Nov 27 10:01:46 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass(p=none dis=none) header.from=suse.de ARC-Seal: i=1; a=rsa-sha256; t=1699646638; cv=none; d=zohomail.com; s=zohoarc; b=S7b/c7ZuTT7akrI71dUP+2qIA9Uh9qPc2zVvCKxSqYdv+ygAPIPx1obvWi0c4Q6nYrU1BJN1Jz0sQ/1oT1NuzrffRdkNBUt9qZcEBpd4DSyPtYHUybWIzZmeIO/TwiGrR8FwaWN6Ts2ClMIPTl404XlmAy+05r63zEtMUUHybwI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1699646638; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=nZpA8N+9GDsiJN8mA/lqa+vyWaYNZiYwdvx4LS9shsI=; b=WoSWEjVaCH4RzbTCK3Cp9/Rml0ZNJ67HGNCPJIoECnxAW184FlE6+bKvC0ONF8VCrnpQGVCBMIyR2XA8NhuLlYGxgGgeVDqPVvVWMMkLJIs0BJGmo1j+jX9+EWaJn3Cdt7TNg6IdlETF1ZP+J7eQRedcRwazVM5otQ6Lx6Jd/Ek= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1699646638273937.2099638736321; Fri, 10 Nov 2023 12:03:58 -0800 (PST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r1XiS-00022g-Q3; Fri, 10 Nov 2023 15:02:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r1XiR-00021g-GR for qemu-devel@nongnu.org; Fri, 10 Nov 2023 15:02:55 -0500 Received: from smtp-out1.suse.de ([2001:67c:2178:6::1c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r1XiP-0004eF-Q0 for qemu-devel@nongnu.org; Fri, 10 Nov 2023 15:02:55 -0500 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B1B90219B9; Fri, 10 Nov 2023 20:02:52 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 40BFD138FC; Fri, 10 Nov 2023 20:02:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 6D2LA2uMTmWiaQAAMHmgww (envelope-from ); Fri, 10 Nov 2023 20:02:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1699646572; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nZpA8N+9GDsiJN8mA/lqa+vyWaYNZiYwdvx4LS9shsI=; b=DnLRJA7lJeYRAGRCryl/YINUyslowVAtl8W9iS5WV1257n5LHQv3NU2Nieyfo44PjIOC6t 4+aGZTGmKXIUsw54khfOyHqV6a/95SAb6MZDPxX7c5R2dIFHnaRjhTAMgmKQrB2XO1qJM7 59i/E0wAKmwSFyMFHosRDrxWNmz8PqQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1699646572; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nZpA8N+9GDsiJN8mA/lqa+vyWaYNZiYwdvx4LS9shsI=; b=Pg4P5eoWEbOtkBObHmxf8upiOhi3lpE87/ehNkPNXFNBYxRiKjmsu3Av8WpJOQ5RUyHE1B Txbmb2EbOA66XPBA== From: Fabiano Rosas To: qemu-devel@nongnu.org Cc: Juan Quintela , Peter Xu , Leonardo Bras , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [RFC PATCH v2 4/4] migration/multifd: Move semaphore release into main thread Date: Fri, 10 Nov 2023 17:02:41 -0300 Message-Id: <20231110200241.20679-5-farosas@suse.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20231110200241.20679-1-farosas@suse.de> References: <20231110200241.20679-1-farosas@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=2001:67c:2178:6::1c; envelope-from=farosas@suse.de; helo=smtp-out1.suse.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: qemu-devel-bounces+importer=patchew.org@nongnu.org X-ZohoMail-DKIM: pass (identity @suse.de) X-ZM-MESSAGEID: 1699646639340100003 Content-Type: text/plain; charset="utf-8" We cannot operate on the multifd semaphores outside of the multifd channel thread because multifd_save_cleanup() can run in parallel and attempt to destroy the mutexes, which causes an assert. Looking at the places where we use the semaphores aside from the migration thread, there's only the TLS handshake thread and the initial multifd_channel_connect() in the main thread. These are places where creating the multifd channel cannot fail, so releasing the semaphores at these places only serves the purpose of avoiding a deadlock when an error happens before the channel(s) have started, but after the migration thread has already called multifd_send_sync_main(). Instead of attempting to release the semaphores at those places, move the release into multifd_save_cleanup(). This puts the semaphore usage in the same thread that does the cleanup, eliminating the race. Move the call to multifd_save_cleanup() before joining the migration thread so we release the semaphores before and avoid deadlock. Signed-off-by: Fabiano Rosas --- migration/migration.c | 4 +++- migration/multifd.c | 33 +++++++++++++++++---------------- 2 files changed, 20 insertions(+), 17 deletions(-) diff --git a/migration/migration.c b/migration/migration.c index 28a34c9068..5a07f5318d 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -1293,6 +1293,9 @@ static void migrate_fd_cleanup(MigrationState *s) QEMUFile *tmp; =20 trace_migrate_fd_cleanup(); + + multifd_save_cleanup(); + qemu_mutex_unlock_iothread(); if (s->migration_thread_running) { qemu_thread_join(&s->thread); @@ -1300,7 +1303,6 @@ static void migrate_fd_cleanup(MigrationState *s) } qemu_mutex_lock_iothread(); =20 - multifd_save_cleanup(); qemu_mutex_lock(&s->qemu_file_lock); tmp =3D s->to_dst_file; s->to_dst_file =3D NULL; diff --git a/migration/multifd.c b/migration/multifd.c index 639505dd10..a66be2d4e4 100644 --- a/migration/multifd.c +++ b/migration/multifd.c @@ -531,6 +531,15 @@ void multifd_save_cleanup(void) =20 if (p->thread) { qemu_thread_join(p->thread); + } else { + /* + * The migration thread might be waiting on these. It is + * the responsibility of the channel thread to release + * them, unless it has never been created, then do it + * here. + */ + qemu_sem_post(&p->sem_sync); + qemu_sem_post(&multifd_send_state->channels_ready); } } for (i =3D 0; i < migrate_multifd_channels(); i++) { @@ -784,20 +793,15 @@ static void multifd_tls_outgoing_handshake(QIOTask *t= ask, =20 if (!qio_task_propagate_error(task, &err)) { trace_multifd_tls_outgoing_handshake_complete(ioc); - if (multifd_channel_connect(p, ioc, &err)) { - return; - } + multifd_channel_connect(p, ioc, &error_abort); + } else { + /* + * The multifd client could already be waiting to queue data, + * so let it know that we didn't even start. + */ + p->quit =3D true; + trace_multifd_tls_outgoing_handshake_error(ioc, error_get_pretty(e= rr)); } - - trace_multifd_tls_outgoing_handshake_error(ioc, error_get_pretty(err)); - - /* - * Error happen, mark multifd_send_thread status as 'quit' although it - * is not created, and then tell who pay attention to me. - */ - p->quit =3D true; - qemu_sem_post(&multifd_send_state->channels_ready); - qemu_sem_post(&p->sem_sync); } =20 static void *multifd_tls_handshake_thread(void *opaque) @@ -870,9 +874,6 @@ static void multifd_new_send_channel_cleanup(MultiFDSen= dParams *p, QIOChannel *ioc, Error *err) { migrate_set_error(migrate_get_current(), err); - /* Error happen, we need to tell who pay attention to me */ - qemu_sem_post(&multifd_send_state->channels_ready); - qemu_sem_post(&p->sem_sync); /* * Although multifd_send_thread is not created, but main migration * thread need to judge whether it is running, so we need to mark --=20 2.35.3