linux-kernel - RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer signaling

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] [day] [month] [year] [list]

Message-ID: <DM5PR2101MB10304037A2AE19B48ECFFEB9DCF70@DM5PR2101MB1030.namprd21.prod.outlook.com>
Date:   Mon, 12 Feb 2018 05:13:07 +0000
From:   "Michael Kelley (EOSG)" <Michael.H.Kelley@...rosoft.com>
To:     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>,
        "olaf@...fle.de" <olaf@...fle.de>,
        "apw@...onical.com" <apw@...onical.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "leann.ogasawara@...onical.com" <leann.ogasawara@...onical.com>,
        "marcelo.cerri@...onical.com" <marcelo.cerri@...onical.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>
Subject: RE: [PATCH char-misc 1/1] Drivers: hv: vmbus: Fix ring buffer
 signaling

> -----Original Message-----
> From: KY Srinivasan
> Sent: Sunday, February 11, 2018 5:14 PM

--- snip ---

> >  	if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
> >  		u32 pending_sz = READ_ONCE(rbi->ring_buffer-
> > >pending_send_sz);
> >
> >  		/*
> > +		 * 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 code conditional
> on pending_send_sz being non-zero.
> 
> 

I agree that we can immediately test pending_send_sz for zero, and exit
if zero.  A  zero value will be by far the most common path, and would
save executing the read barrier and hv_get_bytes_to_write().  Can also
move the calculation of "delta" to after the test for zero.

But I believe the read barrier is still needed on the path where
pending_send_sz is non-zero.  Just the testing the value of pending_send_sz
doesn't guarantee that the write_index wouldn't be speculatively read,
and potentially out-of-order.   And we have to consider the out-of-order
behaviors on ARM64 as well.

> 
> > +		curr_write_sz = 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;
> >
> >  		/* If pending write will not fit, don't give false hope. */
> > -		if (hv_get_bytes_to_write(rbi) < pending_sz)
> > +		if (curr_write_sz <= pending_sz)
> >  			return;
> > +
> > +		vmbus_setevent(channel);
> >  	}
> >
> > -	vmbus_setevent(channel);
> >  }
> >  EXPORT_SYMBOL_GPL(hv_pkt_iter_close);
> > --
> > 1.8.3.1