Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   KY Srinivasan <kys@microsoft.com>
To:     "Michael Kelley (EOSG)" <Michael.H.Kelley@microsoft.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "devel@linuxdriverproject.org" <devel@linuxdriverproject.org>,
        "olaf@aepfle.de" <olaf@aepfle.de>,
        "apw@canonical.com" <apw@canonical.com>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "leann.ogasawara@canonical.com" <leann.ogasawara@canonical.com>,
        "marcelo.cerri@canonical.com" <marcelo.cerri@canonical.com>,
        Stephen Hemminger <sthemmin@microsoft.com>
Subject: RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer
 signaling
Thread-Topic: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer
 signaling
Thread-Index: AQHTorCNaQB4t9RCq0qElSZLQrwNpaOf8abQ
Date:   Mon, 12 Feb 2018 01:14:16 +0000
Message-ID: <DM5PR2101MB0888E82FA2CD667F9E040F6FA0F70@DM5PR2101MB0888.namprd21.prod.outlook.com>
References: <SN6PR1901MB204572CAD3159EB07D6F1043CBF10@SN6PR1901MB2045.namprd19.prod.outlook.com>
In-Reply-To: <SN6PR1901MB204572CAD3159EB07D6F1043CBF10@SN6PR1901MB2045.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e43b9769-5343-43ed-75fb-08d571b5ef94
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 01:14:16.2804
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1045
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----Original Message-----
> From: Michael Kelley [mailto:mhkelley@outlook.com]
> Sent: Saturday, February 10, 2018 12:49 PM
> To: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org; olaf@aepfle.de; apw@canonical.com;
> vkuznets@redhat.com; jasowang@redhat.com;
> leann.ogasawara@canonical.com; marcelo.cerri@canonical.com; Stephen
> Hemminger <sthemmin@microsoft.com>; KY Srinivasan
> <kys@microsoft.com>
> Cc: Michael Kelley (EOSG) <Michael.H.Kelley@microsoft.com>
> Subject: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signal=
ing
>=20
> Fix bugs in signaling the Hyper-V host when freeing space in the
> host->guest ring buffer:
>=20
> 1. The interrupt_mask must not be used to determine whether to signal
>    on the host->guest ring buffer
> 2. The ring buffer write_index must be read (via hv_get_bytes_to_write)
>    *after* pending_send_sz is read in order to avoid a race condition
> 3. Comparisons with pending_send_sz must treat the "equals" case as
>    not-enough-space
> 4. Don't signal if the pending_send_sz feature is not present. Older
>    versions of Hyper-V that don't implement this feature will poll.
>=20
> Fixes: 03bad714a161 ("vmbus: more host signalling avoidance")
> Signed-off-by: Michael Kelley <mhkelley@outlook.com>
> ---
>  drivers/hv/ring_buffer.c | 24 ++++++++++++++++--------
>  1 file changed, 16 insertions(+), 8 deletions(-)
>=20
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 50e0714..b64be18 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -423,7 +423,11 @@ struct vmpacket_descriptor *
>  void hv_pkt_iter_close(struct vmbus_channel *channel)
>  {
>  	struct hv_ring_buffer_info *rbi =3D &channel->inbound;
> -	u32 orig_write_sz =3D hv_get_bytes_to_write(rbi);
> +	u32 curr_write_sz;
> +	u32 delta =3D rbi->ring_buffer->read_index < rbi->priv_read_index ?
> +			(rbi->priv_read_index - rbi->ring_buffer-
> >read_index) :
> +			(rbi->ring_datasize - rbi->ring_buffer->read_index +
> +			rbi->priv_read_index);
>=20
>  	/*
>  	 * Make sure all reads are done before we update the read index
> since
> @@ -446,27 +450,31 @@ void hv_pkt_iter_close(struct vmbus_channel
> *channel)
>  	 */
>  	virt_mb();
>=20
> -	/* If host has disabled notifications then skip */
> -	if (rbi->ring_buffer->interrupt_mask)
> -		return;
> -
>  	if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
>  		u32 pending_sz =3D READ_ONCE(rbi->ring_buffer-
> >pending_send_sz);
>=20
>  		/*
> +		 * Ensure the read of write_index in
> hv_get_bytes_to_write()
> +		 * happens after the read of pending_send_sz.
> +		 */
> +		virt_rmb();
We can avoid the read barrier by making the initialization of curr_write_sz=
 conditional
on pending_send_sz being non-zero. Indeed you can make all the signaling co=
de conditional
on pending_send_sz being non-zero.


> +		curr_write_sz =3D hv_get_bytes_to_write(rbi);
> +
> +		/*
>  		 * If there was space before we began iteration,
>  		 * then host was not blocked. Also handles case where
>  		 * pending_sz is zero then host has nothing pending
>  		 * and does not need to be signaled.
>  		 */
> -		if (orig_write_sz > pending_sz)
> +		if (curr_write_sz - delta > pending_sz)
>  			return;
>=20
>  		/* If pending write will not fit, don't give false hope. */
> -		if (hv_get_bytes_to_write(rbi) < pending_sz)
> +		if (curr_write_sz <=3D pending_sz)
>  			return;
> +
> +		vmbus_setevent(channel);
>  	}
>=20
> -	vmbus_setevent(channel);
>  }
>  EXPORT_SYMBOL_GPL(hv_pkt_iter_close);
> --
> 1.8.3.1