linux-kernel - Re: [PATCH 1/3] Drivers: hv: vmbus: Disable Suspend-to-Idle for VMBus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240921190923.GA15748@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Sat, 21 Sep 2024 12:09:23 -0700
From: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>
To: Naman Jain <namjain@...ux.microsoft.com>
Cc: kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
	decui@...rosoft.com, jikos@...nel.org, bentiss@...nel.org,
	dmitry.torokhov@...il.com, linux-hyperv@...r.kernel.org,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	ernis@...rosoft.com, Saurabh Sengar <ssengar@...ux.microsoft.com>
Subject: Re: [PATCH 1/3] Drivers: hv: vmbus: Disable Suspend-to-Idle for VMBus

On Fri, Sep 13, 2024 at 12:49:27PM +0530, Naman Jain wrote:
> 
> 
> On 9/13/2024 2:57 AM, Erni Sri Satya Vennela wrote:
> >If the Virtual Machine Connection window is focused,
> >a Hyper-V VM user can unintentionally touch the keyboard/mouse
> >when the VM is hibernating or resuming, and consequently the
> >hibernation or resume operation can be aborted unexpectedly.
> >Fix the issue by no longer registering the keyboard/mouse as
> >wakeup devices (see the other two patches for the
> >changes to drivers/input/serio/hyperv-keyboard.c and
> >drivers/hid/hid-hyperv.c).
> >
> >The keyboard/mouse were registered as wakeup devices because the
> >VM needs to be woken up from the Suspend-to-Idle state after
> >a user runs "echo freeze > /sys/power/state". It seems like
> >the Suspend-to-Idle feature has no real users in practice, so
> >let's no longer support that by returning -EOPNOTSUPP if a
> >user tries to use that.
> >
> 
> Maybe it would be good to capture here the kind of VMs that this is
> going to be not supported - HyperV based VMs. You mentioned it in cover
> letter, but it would be good to add it here as well, as cover letter
> does not go to git log.
> 
Sure, I'll specify this in the next version of the patch.
> Also, the subject suggests that we are disabling suspend-to-idle for
> vmbus specifically, but from commit description, it suggests that
> "suspend to idle" feature itself is no longer supported on these
> particular VMs. Please rephrase it based on what exactly we are trying
> to do here. IIUC, we are now returning an error (EOPNOTSUPP) in vmbus
> driver callback, which insures that we don't support Suspend-to-Idle in
> these VMs.
> 
Yes, that's correct.
> >Signed-off-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
> >Signed-off-by: Erni Sri Satya Vennela <ernis@...ux.microsoft.com>
> >---
> >  drivers/hv/vmbus_drv.c | 15 ++++++++++++++-
> >  1 file changed, 14 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> >index 965d2a4efb7e..4efd8856392f 100644
> >--- a/drivers/hv/vmbus_drv.c
> >+++ b/drivers/hv/vmbus_drv.c
> >@@ -900,6 +900,19 @@ static void vmbus_shutdown(struct device *child_device)
> >  }
> >  #ifdef CONFIG_PM_SLEEP
> >+/*
> >+ * vmbus_freeze - Suspend-to-Idle
> >+ */
> >+static int vmbus_freeze(struct device *child_device)
> >+{
> >+/*
> >+ * Do not support Suspend-to-Idle ("echo freeze > /sys/power/state") as
> >+ * that would require registering the Hyper-V synthetic mouse/keyboard
> >+ * devices as wakeup devices, which can abort hibernation/resume unexpectedly.
> >+ */
> >+	return -EOPNOTSUPP;
> >+}
> >+
> >  /*
> >   * vmbus_suspend - Suspend a vmbus device
> >   */
> >@@ -969,7 +982,7 @@ static void vmbus_device_release(struct device *device)
> >   */
> >  static const struct dev_pm_ops vmbus_pm = {
> >-	.suspend_noirq	= NULL,
> >+	.suspend_noirq  = vmbus_freeze,
> >  	.resume_noirq	= NULL,
> >  	.freeze_noirq	= vmbus_suspend,
> 
> I am not sure if this is OK or how it works, but this naming scheme
> seems a bit confusing to me -
> *suspend* -> vmbus_*freeze*
> *freeze* -> vmbus_*suspend*
> and we are removing support for "freeze" by returning EOPNOTSUPP in
> suspend callback.
AFAIU, suspend_noirq is used for Suspend-to-Idle operation and we use
"freeze > /sys/power/state" for the same. Maybe the naming convention
comes that way. 
The key point to understand here is suspend_noirq prepares the machine 
to low power state and freeze_noirq prepares the machine for hibernation 
(saving state to disk).
> 
> I'll try to understand more on this, but just see if its OK.
> 
> >  	.thaw_noirq	= vmbus_resume,
> 
> Regards,
> Naman
Yes, thaw_noirq is to restore devices from hibernation state.