linux-kernel - RE: [PATCH 2/5] hv: add helpers to handle hv

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: <BY2PR0301MB1654B6FF1FB43DA79CC849E3A0460@BY2PR0301MB1654.namprd03.prod.outlook.com>
Date:	Mon, 21 Sep 2015 16:34:56 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Olaf Hering <olaf@...fle.de>, Greg KH <gregkh@...uxfoundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"vkuznets@...hat.com" <vkuznets@...hat.com>,
	"jasowang@...hat.com" <jasowang@...hat.com>
Subject: RE: [PATCH 2/5] hv: add helpers to handle hv_util device state



> -----Original Message-----
> From: Olaf Hering [mailto:olaf@...fle.de]
> Sent: Monday, September 21, 2015 3:26 AM
> To: KY Srinivasan <kys@...rosoft.com>; Greg KH
> <gregkh@...uxfoundation.org>
> Cc: linux-kernel@...r.kernel.org; devel@...uxdriverproject.org;
> apw@...onical.com; vkuznets@...hat.com; jasowang@...hat.com
> Subject: Re: [PATCH 2/5] hv: add helpers to handle hv_util device state
> 
> On Sun, Sep 20, Greg KH wrote:
> 
> > Just use a lock, that's what it is there for.
> 
> How would that help? It might help because it enforces ordering. But
> that requires that all three utils get refactored to deal with the
> introduced locking. I will let KY comment on this.
> 
> The issue I see with fcopy is that after or while fcopy_respond_to_host
> runs an interrupt triggers which also calls into
> hv_fcopy_onchannelcallback.  It was most likely caused by a logic change
> in "recent" vmbus updates because this did not happen before. At least,
> the fcopy hang was not seen earler. Maybe the bug did just not trigger
> up to now for other reasons...

All util channels are bound to CPU 0. Just forcing all activity on CPU 0 may be the 
simplest solution here. Besides, these are not performance critical services anyway.

The problem you may have run into could be related to the fact that we could potentially
run the polling function on a CPU other than CPU 0.

Regards,

K. Y
> 
> Olaf