From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757468AbbJHNak (ORCPT ); Thu, 8 Oct 2015 09:30:40 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.161]:61282 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757414AbbJHNaj (ORCPT ); Thu, 8 Oct 2015 09:30:39 -0400 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWi/zfN1cLnDYUEsRQLYl4HhAqZo+sVIcWWcWxVIox2+eyFQr5Y= X-RZG-CLASS-ID: mo00 Date: Thu, 8 Oct 2015 15:30:37 +0200 From: Olaf Hering To: Vitaly Kuznetsov Cc: "K. Y. Srinivasan" , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, apw@canonical.com, jasowang@redhat.com Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in interrupt context Message-ID: <20151008133037.GA31748@aepfle.de> References: <1444269571-25217-1-git-send-email-kys@microsoft.com> <1444269709-25270-1-git-send-email-kys@microsoft.com> <1444269709-25270-2-git-send-email-kys@microsoft.com> <87r3l5ebmj.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87r3l5ebmj.fsf@vitty.brq.redhat.com> User-Agent: Mutt/1.5.24 (6517) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08, Vitaly Kuznetsov wrote: > > @@ -295,9 +288,6 @@ static int fcopy_on_msg(void *msg, int len) > > if (fcopy_transaction.state == HVUTIL_DEVICE_INIT) > > return fcopy_handle_handshake(*val); > > > > - if (fcopy_transaction.state != HVUTIL_USERSPACE_REQ) > > - return -EINVAL; > > - > > This particular change seems unrelated and I'm unsure it's safe to > remove this check. It is meant to protect against daemon screwing the > protocol and writing to the device when it wasn't requested for an > action. It is correct to propagate -EINVAL in this case. Or am I missing > something and the check is redundant now? What can happen if there is an odd write request? If there is a timeout scheduled some return value will be sent to the host. Then the state is set to RESET and eventually vmbus_recvpacket will receive something. That something will be processed and passed to the daemon. If there was no timeout scheduled the write will just return. Olaf