From: KY Srinivasan <kys@microsoft.com>
To: Michael Gissing <mg@faulpeltz.net>,
        "Alex Ng (LIS)" <alexng@microsoft.com>
CC: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
        "olaf@aepfle.de" <olaf@aepfle.de>,
        "apw@canonical.com" <apw@canonical.com>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: RE: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out
Thread-Topic: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out
Thread-Index: AQHSJZiMSNaE1hOf40Ss39+yWjIXZaC+Q26A
Date: Fri, 28 Oct 2016 18:21:29 +0000
Message-ID: <DM5PR03MB2490DA10B212086187776661A0AD0@DM5PR03MB2490.namprd03.prod.outlook.com>
References: <7a8b552a-d1e0-89e2-5f49-7b4fd2011c70@faulpeltz.net>
In-Reply-To: <7a8b552a-d1e0-89e2-5f49-7b4fd2011c70@faulpeltz.net>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2016 18:21:29.4910
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2731
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u9SKwAkq017853
Content-Length: 2590
Lines: 73


> -----Original Message-----
> From: Michael Gissing [mailto:mg@faulpeltz.net]
> Sent: Thursday, October 13, 2016 2:27 PM
> To: Alex Ng (LIS) <alexng@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> vkuznets@redhat.com; gregkh@linuxfoundation.org
> Subject: [PATCH] Tools: hv: recover after hv_vss_daemon freeze times out
> 
> 
> If a FIFREEZE operation run by the hv_vss_daemon takes longer than the
> VSS_USERSPACE_TIMEOUT set in the hv_snapshot module, instead of exiting
> after a write failure, try to recover by reopening the hv_vss device and
> performing the initial handshake again. Exiting causes all subsequent VSS
> operations sent by the Hyper-V host to fail until the daemon is restarted.
> 
> Signed-off-by: Michael Gissing <mg@faulpeltz.net>
> 
> ---
>   tools/hv/hv_vss_daemon.c | 11 ++++++++++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
> index 5d51d6f..0ecbdab 100644
> --- a/tools/hv/hv_vss_daemon.c
> +++ b/tools/hv/hv_vss_daemon.c
> @@ -176,6 +176,7 @@ int main(int argc, char *argv[])
>       openlog("Hyper-V VSS", 0, LOG_USER);
>       syslog(LOG_INFO, "VSS starting; pid is:%d", getpid());
> 
> +recover:
>       vss_fd = open("/dev/vmbus/hv_vss", O_RDWR);
>       if (vss_fd < 0) {
>           syslog(LOG_ERR, "open /dev/vmbus/hv_vss failed; error: %d %s",
> @@ -196,6 +197,7 @@ int main(int argc, char *argv[])
>       }
> 
>       pfd.fd = vss_fd;
> +    in_handshake = 1;
> 
>       while (1) {
>           pfd.events = POLLIN;
> @@ -258,7 +260,14 @@ int main(int argc, char *argv[])
>           if (len != sizeof(struct hv_vss_msg)) {
>               syslog(LOG_ERR, "write failed; error: %d %s", errno,
>                      strerror(errno));
> -            exit(EXIT_FAILURE);
> +            /*
> +             * try to recover from possible timeout by THAWing
> +             * and restarting the message loop
> +            */
> +            vss_operate(VSS_OP_THAW);
> +            close(vss_fd);
> +            syslog(LOG_INFO, "trying to recover VSS connection");
> +            goto recover;
>           }
>       }

I agree with issuing a THAW command when we timeout in the kernel as this would leave
the file system in a sane state. That said, I am not sure why we need to close the fd and reinitialize
everything in the daemon. What if we just ignored the write error and go back to wait for new commands
from the host.

Regards,

K. Y  
> 
> --
> 2.7.4
>