From nobody Sun Sep 14 06:21:00 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1756991490303438.9771917069435; Thu, 4 Sep 2025 06:11:30 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1110165.1459477 (Exim 4.92) (envelope-from ) id 1uu9k8-0002ow-8k; Thu, 04 Sep 2025 13:11:12 +0000 Received: by outflank-mailman (output) from mailman id 1110165.1459477; Thu, 04 Sep 2025 13:11:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uu9k8-0002op-5e; Thu, 04 Sep 2025 13:11:12 +0000 Received: by outflank-mailman (input) for mailman id 1110165; Thu, 04 Sep 2025 13:11:11 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uu9k7-0002oh-2v for xen-devel@lists.xenproject.org; Thu, 04 Sep 2025 13:11:11 +0000 Received: from bmailout2.hostsharing.net (bmailout2.hostsharing.net [83.223.78.240]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9f793a94-8990-11f0-9d12-b5c5bf9af7f9; Thu, 04 Sep 2025 15:11:09 +0200 (CEST) Received: from h08.hostsharing.net (h08.hostsharing.net [IPv6:2a01:37:1000::53df:5f1c:0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS RSA CA G1" (verified OK)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id 68FB82009D10; Thu, 4 Sep 2025 15:11:08 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 53B8B3FAE00; Thu, 4 Sep 2025 15:11:08 +0200 (CEST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9f793a94-8990-11f0-9d12-b5c5bf9af7f9 Message-Id: <22453676d1ddcebbe81641bb68ddf587fee7e21e.1756990799.git.lukas@wunner.de> From: Lukas Wunner Date: Thu, 4 Sep 2025 15:11:09 +0200 Subject: [PATCH] xen/manage: Fix suspend error path To: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , "Rafael J. Wysocki" Cc: xen-devel@lists.xenproject.org, linux-pm@vger.kernel.org, Pavel Machek , Len Brown X-ZM-MESSAGEID: 1756991491392116600 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The device power management API has the following asymmetry: * dpm_suspend_start() does not clean up on failure (it requires a call to dpm_resume_end()) * dpm_suspend_end() does clean up on failure (it does not require a call to dpm_resume_start()) The asymmetry was introduced by commit d8f3de0d2412 ("Suspend-related patches for 2.6.27") in June 2008: It removed a call to device_resume() from device_suspend() (which was later renamed to dpm_suspend_start()). When Xen began using the device power management API in May 2008 with commit 0e91398f2a5d ("xen: implement save/restore"), the asymmetry did not yet exist. But since it was introduced, a call to dpm_resume_end() is missing in the error path of dpm_suspend_start(). Fix it. Fixes: d8f3de0d2412 ("Suspend-related patches for 2.6.27") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v2.6.27 Reviewed-by: Rafael J. Wysocki (Intel) --- kexec suffered from the same issue ever since it began using the device power management API in July 2008 with commit 89081d17f7bb ("kexec jump: save/restore device state"). It was fixed this year by commit 996afb6efd1a ("kexec_core: Fix error code path in the KEXEC_JUMP flow"). All other callers seem fine. drivers/xen/manage.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c index 841afa4..1f5a7a4 100644 --- a/drivers/xen/manage.c +++ b/drivers/xen/manage.c @@ -110,7 +110,7 @@ static void do_suspend(void) err =3D dpm_suspend_start(PMSG_FREEZE); if (err) { pr_err("%s: dpm_suspend_start %d\n", __func__, err); - goto out_thaw; + goto out_resume_end; } =20 printk(KERN_DEBUG "suspending xenstore...\n"); @@ -150,6 +150,7 @@ static void do_suspend(void) else xs_suspend_cancel(); =20 +out_resume_end: dpm_resume_end(si.cancelled ? PMSG_THAW : PMSG_RESTORE); =20 out_thaw: --=20 2.50.1