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]

Message-ID: <20151009112832.GA22038@aepfle.de>
Date:	Fri, 9 Oct 2015 13:28:33 +0200
From:	Olaf Hering <olaf@...fle.de>
To:	Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:	KY Srinivasan <kys@...rosoft.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>
Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in
 interrupt context

On Fri, Oct 09, Vitaly Kuznetsov wrote:

> Olaf Hering <olaf@...fle.de> writes:
> 
> > On Thu, Oct 08, KY Srinivasan wrote:
> >
> >> > yes, but after doing fcopy_respond_to_host(). I'd suggest we leave the
> >> > check in place, better safe than sorry.
> >> 
> >> Agreed; Olaf, if it is ok with you, I can fix it up and send.
> >
> > I will retest with this part reverted. I think without two code paths
> > entering hv_fcopy_callback it should be ok to leave this check in.
> 
> I think hv_fcopy_callback() is not involved here: we call fcopy_on_msg()
> every time userspace daemon writes to the device and it is not anyhow
> synchronized with host-guest communication. 

An earlier variant of this patch used locks around the vmbus_recvpacket
and the result was used to decide which thread of execution notifies the
daemon. I think if the interrupt ran earlier than the daemon did the
write then the state expected in fcopy_on_msg would obviously be wrong.
As a result the daemon will just terminate with EFAULT. With the check
removed it would proceed, and either not chancel the timeout or
vmbus_recvpacket reads nothing.

But now that it is single threaded the state in fcopy_on_msg should be
as expected. As said, will retest. Either later today or on Monday.

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/