[PATCH 07/14] vmbus: remove conditional locking of vmbus_write

[Stephen Hemminger]

On Fri, 27 Jan 2017 18:08:35 +0000
KY Srinivasan <kys at microsoft.com> wrote:

> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Monday, January 23, 2017 5:40 PM
> > To: KY Srinivasan <kys at microsoft.com>; Haiyang Zhang
> > <haiyangz at microsoft.com>
> > Cc: devel at linuxdriverproject.org; Stephen Hemminger
> > <sthemmin at microsoft.com>
> > Subject: [PATCH 07/14] vmbus: remove conditional locking of vmbus_write
> > 
> > All current usage of vmbus write uses the acquire_lock flag, therefore
> > having it be optional is unnecessary. This also fixes a sparse warning
> > since sparse doesn't like when a function has conditional locking.  
> 
> In order to avoid cross-tree dependency, I got this functionality into Greg's
> tree first. I plan to submit patches to netvsc that will use this functionality.
> As you know, we hold a higher level lock in the protocol stack when we send on
> a sub-channel. This will avoid an unnecessary spin lock round trip in the data path.
> 
> Regards,
> 
> K. Y

Conditional locking is in general a bad idea because it breaks static analysis tools like
sparse. In order to have a non-locking code path then it is
better to have a locked and unlocked version of the same functions.

Also, in networking receive path is not specially single threaded. With my per-channel
tasklet (and later NAPI), the each channel's receive path would be single threaded
but there are still races possible in the shutdown logic (as written). Longer term
it would be best if all vmbus events were handled per-channel without lock, ie
networking is not a special case.

Probably best to figure out how to make all VMBUS ring access lockless, ie it is
callers responsibilty. Storage and networking are multi-queue already.