linux-kernel - Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in interrupt context

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]

Date:	Thu, 8 Oct 2015 15:30:37 +0200
From:	Olaf Hering <olaf@...fle.de>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:	"K. Y. Srinivasan" <kys@...rosoft.com>, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
	apw@...onical.com, jasowang@...hat.com
Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in
 interrupt context

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/