From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758224AbbJIL2j (ORCPT ); Fri, 9 Oct 2015 07:28:39 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.218]:41510 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754915AbbJIL2h (ORCPT ); Fri, 9 Oct 2015 07:28:37 -0400 X-RZG-AUTH: :P2EQZWCpfu+qG7CngxMFH1J+yackYocTD1iAi8x+OWtqWFmrC5F/k8792rHpkQ== X-RZG-CLASS-ID: mo00 Date: Fri, 9 Oct 2015 13:28:33 +0200 From: Olaf Hering To: Vitaly Kuznetsov Cc: KY 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: <20151009112832.GA22038@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> <20151008133037.GA31748@aepfle.de> <87mvvteabq.fsf@vitty.brq.redhat.com> <20151009070757.GA27773@aepfle.de> <87si5kqrhr.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87si5kqrhr.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 Fri, Oct 09, Vitaly Kuznetsov wrote: > Olaf Hering 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