All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>,
	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
Date: Thu, 08 Oct 2015 15:52:57 +0200	[thread overview]
Message-ID: <87mvvteabq.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20151008133037.GA31748@aepfle.de> (Olaf Hering's message of "Thu, 8 Oct 2015 15:30:37 +0200")

Olaf Hering <olaf@aepfle.de> writes:

> 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?

I think we don't want to propagate misbehaving daemon's data to the
host -- let's cut it here. E.g. imagine there is no communication going
on and daemon starts writing something to the device. In case we remove
the check we'll be doing fcopy_respond_to_host() for each daemon's write
flooding the host.

> 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.

yes, but after doing fcopy_respond_to_host(). I'd suggest we leave the
check in place, better safe than sorry.

-- 
  Vitaly

  reply	other threads:[~2015-10-08 13:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-08  1:59 [PATCH 00/10] Drivers: hv: Miscellaneous fixes K. Y. Srinivasan
2015-10-08  2:01 ` [PATCH 01/10] Drivers: hv: util: Increase the timeout for util services K. Y. Srinivasan
2015-10-08  2:01   ` [PATCH 02/10] Drivers: hv: utils: run polling callback always in interrupt context K. Y. Srinivasan
2015-10-08 13:24     ` Vitaly Kuznetsov
2015-10-08 13:30       ` Olaf Hering
2015-10-08 13:52         ` Vitaly Kuznetsov [this message]
2015-10-08 14:55           ` KY Srinivasan
2015-10-09  7:07             ` Olaf Hering
2015-10-09 10:13               ` Vitaly Kuznetsov
2015-10-09 11:28                 ` Olaf Hering
2015-10-12  6:05                   ` KY Srinivasan
2015-10-13  9:46               ` Olaf Hering
2015-10-13 21:33                 ` KY Srinivasan
2015-10-08  2:01   ` [PATCH 03/10] tools: hv: report ENOSPC errors in hv_fcopy_daemon K. Y. Srinivasan
2015-10-08  2:01   ` [PATCH 04/10] tools: hv: remove repeated HV_FCOPY string K. Y. Srinivasan
2015-10-08  2:01   ` [PATCH 05/10] Drivers: hv: util: catch allocation errors K. Y. Srinivasan
2015-10-08  2:01   ` [PATCH 06/10] Drivers: hv: utils: use memdup_user in hvt_op_write K. Y. Srinivasan
2015-10-08  2:01   ` [PATCH 07/10] drivers/hv: cleanup synic msrs if vmbus connect failed K. Y. Srinivasan
2015-10-08 17:19     ` Denis V. Lunev
2015-10-08 17:28       ` KY Srinivasan
2015-10-08 17:31         ` Denis V. Lunev
2015-10-08  2:01   ` [PATCH 08/10] drivers:hv: Export a function that maps Linux CPU num onto Hyper-V proc num K. Y. Srinivasan
2015-10-08  2:01   ` [PATCH 09/10] drivers:hv: Export the API to invoke a hypercall on Hyper-V K. Y. Srinivasan
2015-10-08  2:01   ` [PATCH 10/10] drivers:hv: Define the channel type for Hyper-V PCI Express pass-through K. Y. Srinivasan
2015-10-08 10:24     ` Vitaly Kuznetsov
2015-10-08 13:23   ` [PATCH 01/10] Drivers: hv: util: Increase the timeout for util services Olaf Hering
2015-10-08 14:40     ` KY Srinivasan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mvvteabq.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=apw@canonical.com \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jasowang@redhat.com \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olaf@aepfle.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.